LionSnake Modeler

Ideas, enhancements, feature requests and development related discussion.

Re: LionSnake Modeler

Postby John VanSickle » Sat Jun 21, 2008 10:44 pm

dcuny wrote:Has the game mania passed, or are you ramping up for the next IRTC?

I don't really ramp up before the topic is announced. If the IRTC topic inspires an animation that I can do in three months, I try to drop other pursuits and get back to scripting.
John VanSickle
 
Posts: 189
Joined: Sat Feb 16, 2008 2:17 am

Re: LionSnake Modeler

Postby John VanSickle » Tue Jun 24, 2008 1:28 am

Well, I replaced all of the typedefed float arrays with a struct containing three floats. A couple of bugs popped up, but once the program compiled and linked it ran without crashing.

Since vector arguments are no longer passed by pointers (but by reference instead), I no longer have to check for NULL pointers. Yes, I know, Java doesn't have that problem...
John VanSickle
 
Posts: 189
Joined: Sat Feb 16, 2008 2:17 am

Re: LionSnake Modeler

Postby dcuny » Fri Jul 04, 2008 6:58 am

I was testing out my LionSnake importer program, so after getting the example file to load, I tried importing an .obj file into LionSnake. It loaded up half the file correctly, but the other half went wrong:
lionsnake.png
lionsnake.png (20.79 KiB) Viewed 6376 times
I saved the file and tried to read it anyway, but ran into trouble with the vertex information:
Code: Select all
v -0.021617 0.416315 0.416315 -1 0
v 0.000338 0.000338 0.488945 -1 0
v -2e-06 0.490522 0.490522 -1 0
v 0.005294 0.005294 0.492648 -1 0
v 0.010214 0.010214 0.49268 -1 0
You can see that one of the values is in scientific notation. I adjust the parser to handle it, but is this a proper sort of value for LionSnake to be writing out? :?

Here's the file I was trying to import. It's a free model from 3DUniverse:
3duLoResGirl.zip
(120.23 KiB) Downloaded 240 times
After you unzip the file, The .obj file can be found in the directory:
Code: Select all
3duLoResGirl\Runtime\Geometries\3DUniverse\Toons
I haven't spent too much time looking to see what the problem is, because I've got a better version of the model that I created with Blender, and hand edited the colors into. Still, it might be useful for debugging.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: LionSnake Modeler

Postby John VanSickle » Sun Jul 06, 2008 5:50 am

dcuny wrote:I adjust the parser to handle it, but is this a proper sort of value for LionSnake to be writing out?

I'm worried about both the file written that can't be read (which is clearly not kosher), and the fact that the model didn't load properly in the first place (which means that a field in the original .OBJ was probably not parsed correctly).

Still, it might be useful for debugging.

It probably is. I have another downloaded OBJ that I use for debugging, but a second one never hurts.
John VanSickle
 
Posts: 189
Joined: Sat Feb 16, 2008 2:17 am

Re: LionSnake Modeler

Postby John VanSickle » Mon Jul 14, 2008 12:46 pm

The bug that caused the girl .OBJ to load improperly was because the function that parses floating point values from the file stream was skipping only the first character of white space prior to the float. The original .OBJ aligned all of the decimal points for the vertex data, which meant that non-negative values have two spaces before them, instead of one. This caused a positive x value to be read as both the x and y value for that vertex. If the x value was negative, then a positive y value was read for both the y and z values; and since nearly all of the y values are positive, this is what happened. Only those vertices having negative x and y values were read correctly.

This particular bug is squashed, but now the subdivision preview is shading everything with ambient values (no diffuse). I was working on something with the bone rotation tool as well, and so the upload with the bug fix won't be for a while.
John VanSickle
 
Posts: 189
Joined: Sat Feb 16, 2008 2:17 am

Re: LionSnake Modeler

Postby John VanSickle » Mon Jul 14, 2008 7:28 pm

John VanSickle wrote:This particular bug is squashed, but now the subdivision preview is shading everything with ambient values (no diffuse).

...which was fixed by normalizing the normal vectors. For some reason I'd taken that code out when putting in the new vector object code.

I also got the bone rotation tool working pretty much like I want. The rotation gadget allows the end knob to be dragged around, and also allows the rotation axes to be individually adjusted. The new version has been uploaded. Nothing like someone else finding a bug to make me stop playing RuneScape...
John VanSickle
 
Posts: 189
Joined: Sat Feb 16, 2008 2:17 am

Re: LionSnake Modeler

Postby dcuny » Mon Jul 14, 2008 9:52 pm

Thanks, I'll have a look at it! The bone rotation tool sounds like fun.

Any chance you might consider making this Wine friendly? I doubt there's a large demand from your users for this "feature", though. :|
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: LionSnake Modeler

Postby dcuny » Mon Jul 14, 2008 11:28 pm

I've played a bit with the bones. As usual, I'll complain about them not working like everyone else's bones. ;)

When adding a bone, I expect it to be aligned with the current axis. That is, no matter what view I'm in, the bone will lie in the plane I'm looking straight at. By default, LionSnake seems to automatically align bones to the z axis, no matter what angle I'm viewing at.

To move a bone, you grab it by the root. To rotate, grab it by the terminator. That makes sense. The root highlights with a box when you move the mouse over it (good) but the terminator does not (bad).

Bones seem to be of a fixed length. I'd expect bones to be longer or shorter, showing the area they cover.

Similarly, I'd expect child bone root to be connected to the parent's terminator. This gives a visual indication of how the bones are connected. As they currently are, you can't see the hierarchy unless you move the cursor to a particular bone. It also makes it difficult to align the elbow of the arm.

I think the way it's handled in Blender is that bones are attached to their parents (parent terminator to child root) by default. If you change this default, you still see a connection between the parent and the child, only with a dotted line.

I really want to like the bones in LionSnake, but they require too much work. :( Why don't they work the same way you can add a new edge in Add mesh mode? There, the vertex that you add is automatically connected to the prior vertex. If you want to add another edge to an existing vertex, just click and drag. Bones should work the same way.

The rotation tool is a bit picky - if you're looking at the xy plane, you can't click and rotate the control lying on the z plane.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: LionSnake Modeler

Postby John VanSickle » Tue Jul 15, 2008 1:15 pm

dcuny wrote:When adding a bone, I expect it to be aligned with the current axis. That is, no matter what view I'm in, the bone will lie in the plane I'm looking straight at. By default, LionSnake seems to automatically align bones to the z axis, no matter what angle I'm viewing at.

This grievance has been taken into consideration.

To move a bone, you grab it by the root. To rotate, grab it by the terminator. That makes sense. The root highlights with a box when you move the mouse over it (good) but the terminator does not (bad).

Hmm, it should be highlighting...

Bones seem to be of a fixed length. I'd expect bones to be longer or shorter, showing the area they cover.

This feature is planned, once I get around to it.

I think the way it's handled in Blender is that bones are attached to their parents (parent terminator to child root) by default. If you change this default, you still see a connection between the parent and the child, only with a dotted line.

I will probably bring back the dotted line, but I kinda like the current behavior now; although I think that a Bone that is created as a child will enter life pointing in the same direction as its parent.

The rotation tool is a bit picky - if you're looking at the xy plane, you can't click and rotate the control lying on the z plane.

This is on purpose, because the code which determines the starting point of the operation does a ray intersection test with the plane containing the tool; when viewed edge-on, the intersection yields invalid results. I may have to write code to use either a ray-plane test or a ray-cylinder test, depending on the orientation of the screen and the tool in question.
John VanSickle
 
Posts: 189
Joined: Sat Feb 16, 2008 2:17 am

Re: LionSnake Modeler

Postby John VanSickle » Fri Dec 26, 2008 5:31 pm

Recent updates, due to the fact that I now only get the Internet when I go to the local library, so I play a lot less Diablo 2 and nothing else at all:

There are now gadgets for scaling, rotating, and translating Bones. These stay up until the user right-clicks them away, so that the user can scale, rotate, or translate the view to get a better look at the Bone and its stuff.

The user can now insert a stock object. The cube is the only stock object supported, but I'll add others. I intend to allow any model to be inserted from file, and to allow the menu to have a set of stock objects that the user can add to by putting model files into a certain directory.

The user can now inset and extrude faces from the face context menu. After a face is inset, a gadget appears that allows the new face to be scaled. After a face is extruded, a gadget appears which allows the new face to be translated along a vector normal to the face.

Lines are now drawn with anti-aliasing, which makes things look a lot less C64-ish.

I have been writing XML handling code, because I plan to make the files XML-based for the 1.8 release.

I have also been coding a full subdivision preview (and not just the first level, as is seen now).

And finally, none of these improvements are uploaded yet, because I forgot to put it on the data stick I brought to the library with me today. Maybe next time.
John VanSickle
 
Posts: 189
Joined: Sat Feb 16, 2008 2:17 am

Re: LionSnake Modeler

Postby dcuny » Fri Dec 26, 2008 7:18 pm

Good to hear! I'm glad you're continuing to work on LionSnake! :D
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: LionSnake Modeler

Postby John VanSickle » Tue Jan 06, 2009 4:18 pm

I wrote some code the for the subdivision preview, this time bumping up the subdivision level to 2 (I intend to use an algorithm gleaned from Loop to display the limit surface).

I test it on a simple cube. Works fine, lasts a long time.

Tried it on the LoRes3dGirl model that I downloaded from somewhere. It took about a dozen seconds to build the data structures for the preview. I had written it so that every time a vector was added to a weighted sum, the object for the weighted sum has to extend two dynamic arrays, which means two alloc and free calls. For a cube, with six faces, this wasn't much, but evidently with a few thousand faces things are different. I am now rewriting that piece of code.

I am now also thinking that the subdivision preview should display the limit edges and vertices, and allow the user to make edits by dragging the limit vertices around. This won't be hard, methinks.

Also, at some point the program quit being able to tell which part of the mesh is under the mouse pointer, so I have some debugging to do. It might have something to do with the anti-aliasing I just implemented...
John VanSickle
 
Posts: 189
Joined: Sat Feb 16, 2008 2:17 am

Re: LionSnake Modeler

Postby sascha » Wed Jan 07, 2009 11:28 am

It took about a dozen seconds to build the data structures for the preview

Same here, that's not surprising. Subdividing the cartoon-rabbit to level 2 takes some seconds - I think it's the memory allocation that takes most of the time.
If you don't intend to allow editing on higher levels, on the fly adaptive subdivision might be a better solution. I've had it implemented in JPatch before I decided that it was too complex to combine with hierarchical modeling, so I dropped it eventually. But it worked quite well - a bit slower than a pre-subdivided mesh of course, but on the other hand the adaptive nature came in quite handy: it would display the mesh at level 0 when viewed from a distance, and subdivide (only the visible) faces up to level 6 as needed when zooming in.
and allow the user to make edits by dragging the limit vertices around. This won't be hard, methinks.

It is trivial as long as the user can only move a single vertex (when in limit-surface mode), as implemented in JPatch right now. Since the limit-position is a weighted sum of the parent vertex and its surroundings, all you have to do is to scale the translation vector before applying it to the control-vertex. This would simply move the control vertex (but to the user it would seem as if the surrounding points move too, since their limit position also depends on that vertex). If you've got an idea of how this could work with multiple vertices, I'd be curious!
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: LionSnake Modeler

Postby John VanSickle » Thu Jan 15, 2009 4:56 pm

sascha wrote:
It took about a dozen seconds to build the data structures for the preview

Same here, that's not surprising. Subdividing the cartoon-rabbit to level 2 takes some seconds - I think it's the memory allocation that takes most of the time.

There were a lot of allocations with the build; basically, every time a point was added to the weighted sum for another point, the weighted sum class reallocated the array of pointers to the contributing vectors and the array for the weight values. However, most of this was not needed, because the necessary length of the arrays is a fixed number that depends only on the kind of point and the topology around it. The build now takes about four to five seconds for the 3duLoResGirl. I shaved some more time by skipping the build step for some of the points.

Right now it goes to level two, and then builds a biquadratic Bezier patch from the resulting points, n patches for each face, with n being the number of sides for that face. It's even slower for the lo res girl, and biquadratics show a slight pinching at the borders between two patches, but I'm going to try something to see if I can make things go faster.

and allow the user to make edits by dragging the limit vertices around. This won't be hard, methinks.

It is trivial as long as the user can only move a single vertex (when in limit-surface mode), as implemented in JPatch right now. Since the limit-position is a weighted sum of the parent vertex and its surroundings, all you have to do is to scale the translation vector before applying it to the control-vertex. This would simply move the control vertex (but to the user it would seem as if the surrounding points move too, since their limit position also depends on that vertex). If you've got an idea of how this could work with multiple vertices, I'd be curious!

Kramer's Rule to the rescue. You'll need to warm up your matrix math library. The matrix is nxn, where n is the number of points being dragged. Element A_i_j is the amount that hull vertex i contributes to final point j (i is the column, j is the row). Take the determinant of this matrix and save that value. To find the amount to scale the drag for point m, replace each value of column m with 1.0, take the determinant of this modified matrix, and divide it by the determinant of the original matrix. The result of this division is the amount by which the drag value for hull vertex m should be scaled in order to move the corresponding limit surface point by the same amount. Note that these scale values can be calculated once at the start of the drag operation and only need to be recalculated if and when the set of dragged points is changed. If you're taking the smart-data-stupid-code approach, you can store each drag scale value as a float member belonging to the hull vertex object, so the total memory usage is quite small.
John VanSickle
 
Posts: 189
Joined: Sat Feb 16, 2008 2:17 am

Re: LionSnake Modeler

Postby sascha » Thu Jan 15, 2009 5:27 pm

The build now takes about four to five seconds for the 3duLoResGirl

That sounds reasonable.
Kramer's Rule to the rescue. You'll need to warm up your matrix math library...

Have you actually tried that? Because I seriously doubt that this will work - to be more precisely: it will work, but you won't like the result.

I did something very similar when trying to convert my old "patch" models to SDS models. The problem was that the control-points of the patch model are on the surface, but the control-points of the SDS model float somewhere above the surface, so doing nothing would result in loss of volume and smoothing out fine details - thus I tried to move the SDS control-points so that the limits lie on the patch control-points - this is similar to the problem of moving multiple limit-positions to desired positions.

I've used (as you suggested) some matrix library and it was able to solve the linear system for about 1000 points in about a second (it used sparse matrices since there are only a few non-zero values per row - this it is quite fast and has a low memory footprint). However, the results were disappointing. While the limit-points were exactly where they should be, the process introduced a lot of unwanted undulation. Here is an example:
Image
This is the Moai model imported without any correction applied (top left), so it looks a bit too smooth.
As you can see on the control-polyhedron, the mouth should be closed, but due to the unwanted smoothing effect, it appears to be open.

Image
This is the moai after the "correction" - although the limit-points are now all exactly where they should be (left), it looks just ugly. Just look at what it did with the control-points (right)

The problem is that matching the limit-position is not enough, you'd also want to match the tangent-plane at each control-point. This is not possible without inserting new control-points into the SDS. One approach I've tried is to solve for limit-position and u- and v-tangents using a least-squares algorithm, but the math package I've used didn't support least-squares, and for several thousand variables this can't be done in a "naive" way (the matrices alone could easily take several 100 megabytes, not to mention the time needed to solve it).

Even if this would work, it would only be an approximation, and perhaps confusing for the user. It would still be good enough for importing models, but not to perform interactive modifications.

Please let me know if you think that I'm wrong (my math isn't that good after all), I'd still be interested in a solution!
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

PreviousNext

Return to Development

Who is online

Users browsing this forum: No registered users and 1 guest

cron