Progress Report?

Discussion about the next release of JPatch, with support for subdivision surfaces (SDS).

Re: Progress Report?

Postby dcuny » Wed Jul 30, 2008 11:43 pm

sascha wrote:This also means that for rendering JPatch doesn't have to keep the entire e.g. level-4 mesh in memory just because there are a few edited vertices at that level.

Cool. 8)

And yes, being able to save models is a good thing.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Progress Report?

Postby sascha » Fri Aug 01, 2008 11:57 am

Now that I can store the displacement information is separate objects, I've refactored the SDS classes once more.
For each displaced vertex I needed five Tuple3d objects and two 3x3 matrices - I've removed these objects from the Vertex class and added them to the separate Displacement class - thus saving 348 bytes per vertex. Taking into account that there can be many many vertices (on higher subdivision levels), this saves a lot of memory.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Progress Report?

Postby sascha » Fri Aug 01, 2008 10:06 pm

Today I ran into a pretty weird problem:
To speed up rendering, I'm using a preallocated vertex-array per face. That way, to draw a face, only a single OpenGL call is necessary, and if the face wasn't changes, the array hasn't to be changed either, so it's pretty fast (more than twice as fast as everything else I've tried).
Since native code must not access Java arrays for deferred processing (since the JVM is allowed to rearrange the array in memory - now whose idea was that?), you'll have to pass a FloatBuffer instead of a float array to JOGL. The docs says it needs to be a direct buffer - i.e. one allocaed directly in system memory, not a buffer wrapped around a Java array - so I've used a direct buffer.
The strange things was that the cartoon rabbit at level 3 ate up all 2Gig of main memory, plus a considerable amount of swap-space on disk, effectively freezing the application. Java reported total heap usage of about 200MB, and Linux reported something like 2.5 GB virtual memory for the process by the time it froze (long before subdivision was finished), so at first I thought it was a bug in the VM - until I recognized that buffers are not allocated from the JVM heap, but from system memory. I checked my code and found out that I made the buffers 4 times as large as necessary (I thought the capacity was in bytes, not elements, so I multiplied it by 4). I've fixed it, but still, the cartoon rabbit at level 3 ate up the entire memory.

And now the best thing: Running out of options, I've changed the direct-buffer to a standard buffer, and lo and behold, it still works, is faster than the direct buffer, and uses a sane amount of memory - the rabbit at level 3 is still terribly slow (about 2 to 3 fps - for drawing about 600,000 triangles though), but that's not the point - at least it easily fits into memory now.
I think this is important - JPatch can hold the level-3 mesh of a quite complex model (more than 2000 faces on level 2) in memory, even on modest machines with say 512MB (assuming that it's not running on Vista ;-)). Editing at level 3 would still be feasibly by clipping away unwanted parts, e.g. showing only the face at level 3 should still give you a decent frame rate.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Progress Report?

Postby dcuny » Sat Aug 02, 2008 12:36 am

sascha wrote:And now the best thing: Running out of options, I've changed the direct-buffer to a standard buffer, and lo and behold, it still works, is faster than the direct buffer, and uses a sane amount of memory...

Heh. :)
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Progress Report?

Postby sascha » Thu Aug 21, 2008 9:02 am

I've got morphs almost working. What I have implemented now is are the "nondestructive editing" layers, which are technically similar to morphs (they're even using the same morphTarget objects), but used differently.
Here's a screenshot of the NDE-layer manager (per model):
nde.png
nde.png (10.63 KiB) Viewed 5796 times

The left button column is for selecting the current layer (where edits are stored), the right column shows which layer is active - not very pretty yet, but at least it works.
Real morphs are next...
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Progress Report?

Postby dcuny » Thu Aug 21, 2008 4:23 pm

Sounds good.

What needs to happen before you feel comfortable with releasing a preview version?
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Progress Report?

Postby sascha » Thu Aug 21, 2008 4:45 pm

Basically 3 things have to work:

* Undo/redo
* All existing modeling tools
* Load/save models

But let me finish the morphs first, it's quite an important proof of concept thing.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Progress Report?

Postby dcuny » Thu Aug 21, 2008 5:43 pm

No problem, I'm just trying to get a feel for where JPatch development is. :)
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Progress Report?

Postby sascha » Thu Aug 21, 2008 7:50 pm

I was surprised how easy it was to add that component to my custom panel - you know, the one with the expandable tabs like "Subdivision", "Transform", etc. It's still completely XML driven, so it's incredibly easy to add new custom components as well.

Real morphs will have a differet GUI. To setup the morph, the best thing might be a "wizard" - a popup window that asks for basic settings like number of control dimensions, etc. Then each morph would have its own panel, with a table containing the morph targets and the position of the morph targets. It would be used to add/remove new morph targets as well.
To control the morph I'd use a HUD style semi-transparent overlay, rendered atop the viewport - this way you could easily setup things like the "stop staring" interface, but don't have to sacrifice a viewport for it. You could even add multiple pose-control overlays to each viewport. Of course the overlay would swallow all mouse-events, so you can't actually model with the overlay in place, but at least you can see the scene "through" the HUD. Together with a hotkey to toggle HUD overlay display this should be a pretty fast interface for posing.

What do you think?
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Progress Report?

Postby dcuny » Thu Aug 21, 2008 11:03 pm

sascha wrote:To setup the morph, the best thing might be a "wizard" - a popup window that asks for basic settings like number of control dimensions, etc. Then each morph would have its own panel, with a table containing the morph targets and the position of the morph targets. It would be used to add/remove new morph targets as well.

Sounds good, especially considering the target audience: people like me who don't like to read manuals.

To control the morph I'd use a HUD style semi-transparent overlay, rendered atop the viewport

Sounds cool. Something like this?
Image
Or this?
Image
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Progress Report?

Postby sascha » Thu Aug 21, 2008 11:36 pm

Yes, more like the second one. And you could have multiple such controls visible on each viewport.
When they are visible, all mouse input goes to them, so you can't e.g. select objects, move or rotate them. Therefor I'd like to add a hotkey, say SPACE, to toggle display of all overlays. This way you can quickly switch the overlay off, grab, position, rotate objects, turn it on again and pose the model, turn it off, move an IK target, turn it on, pose some more, you get the picture.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Progress Report?

Postby sascha » Mon Aug 25, 2008 7:16 pm

Here's the most stupid bug I've ever found (by now):

Something didn't work, I've checked all the possible sources for the bug, yet didn't find anything. Rechecked everything again, still couldn't find anything.
Then I tracked it down to a single method - although I've checked that method before and found nothing that could possibly go wrong, it had to be this one. It looked like some statements simply weren't executed at all. I've read it about ten times, but couldn't find anything - why doesn't it execute the statements that definitely stood there? Then it dawned on me - it had to be a bug in the JVM. I mean, seriously, what else could it possibly be?
So I fired up the debugger and went through the method line by line, and indeed, before reaching the code in question, it exited the method. But not because of a JVM bug, but because of a return statement that glared there on the screen, black on white.
I've never felt more stupid before :-)

I like using break, continue and occasionally even early return statements because they help keeping the { } nesting at a reasonable level - but could someone please write an Eclipse plugin that displays every return statement that is no the last statement of a method in large, blinking, red letters?
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Progress Report?

Postby John VanSickle » Tue Aug 26, 2008 2:31 pm

It occurs to me (from a memory of a strategy game in which one is in control of a colony of ants) that it is possible to provide a single control that combines the base mesh with two morph targets, with the only limitation being that the weightings of the three targets sum to a constant value (preferably one). The control would appear as a triangle (equilateral is best for this) with a small knob that can be dragged around within the confines of the control.

Granted this does not have the full range of flexibility that might be desired for some applications, but for some applications it might be the simplest tool for the job.
John VanSickle
 
Posts: 189
Joined: Sat Feb 16, 2008 2:17 am

Re: Progress Report?

Postby sascha » Wed Aug 27, 2008 6:12 am

Well, the polyharmonic splines I've talked about seem to do the job quite well, and I've already implemented the algorithm. All I need to do is write a GUI for the morphs and try it out. Of course, if it doesn't work as expected, I might have to resort to something simpler.

with the only limitation being that the weightings of the three targets sum to a constant value (preferably one)
That's true for most of these spatial interpolation schemes - you've basically got a set of values, and you need to compute their relative weights (that should sum up to one). Inverse distance does this, and natural neighbor too. But these schemes only have knowledge of the positions of the centers, not of the values there - this results in ugly artifacts in the interpolated shape, which (I think) usually have to be smoothed out in a second step.

Try to imagine a "hight field" with sparse data - you've got 50 coordinates with their according height values (anywhere, not on a regular grid), and you want to compute an interpolated value somewhere in between.
All other schemes I know of only use the coordinates for to compute the relative weights, no the height values there.
A polyharmonic spline on the other hand is a spline that passes through all these points (i.e. coordinate/height combinations) - depending on the basis function it could e.g. represent a thin sheet of metal, bended to touch each of the centers. See http://en.wikipedia.org/wiki/Thin_plate_spline
So the interpolation algorithm also "knows" about each height value, if you like. And both the coordinates as well as the height values can have any dimension.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Progress Report?

Postby dcuny » Wed Aug 27, 2008 4:39 pm

John VanSickle wrote:The control would appear as a triangle (equilateral is best for this) with a small knob that can be dragged around within the confines of the control.

Sounds like barycentric coordinates.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

PreviousNext

Return to JPatch SDS Minimal Development

Who is online

Users browsing this forum: No registered users and 1 guest

cron