LionSnake Modeler

Ideas, enhancements, feature requests and development related discussion.

LionSnake Modeler

Postby dcuny » Fri Jan 26, 2007 12:57 am

It's been a while since I've looked at John VanSickle's LionSnake modeler. At the time, it wouldn't run under Win98, so testing it out was difficult.

John recently announced that he'd be adding in animation support to the program, so I had another look. It's a bit buggy (you can't maximize a window, but you can't resize it) and not entirely user friendly (no undo), but there are a lot of nice features in it that would be nice to have in JPatch.

(It "sort of" runs under Wine, but the toolbar doesn't display properly, so you can't really use it there to test it out).

The first thing I noticed is that, like Wings3D, the selection mode is "smart" - when you hover over a point, it highlights the point. When you hover over a line, it highlights the line. Really nice!

Right click brings up a context menu, but when you are in Pan/Rotate/Zoom mode, it toggles out of the mode and back to Select mode. It works well, but it probably wouldn't work in JPatch, since you can't rotate the view and select vertices like that. It's slick, but not very obvious, so I've got mixed feelings about it.

In add mesh mode, if you drag one vertex on top of another, they are automagically welded together - pretty much the same way JPatch's "auto-weld" used to. There's no "weld" option - it just does it. There's a visual cue where the point you're dragging it onto changes color, so there's some control. In other modes, if you drag a vertex on top of another, you get a dialog asking if you want to merge the points. Initially, I thought JPatch's method was superior, but I'm having my doubts about it. (Yes, I still remember the problem with "auto-weld").

I could figure out how to create a mesh just looking at the interface, but I was completely baffled about how to actually create a face. The method depends on LionSnake's automatically welding points - you have to make a complete circuit, re-selecting points of the mesh that will be part of the face. Once you arrive back at the starting point, LionSnake decides that it's a face:
You can select this from the main window menu, from the context menu, or by clicking on the Add mesh button. In mesh add mode, left-clicking starts a circuit of edges. Everywhere you click, the current edge will be finished and a new one started. All of the vertices created will be placed in the plane that passes through the centerpoint of the view. If you click on an existing point, it will be added to the circuit without moving it. Points which can be added in this way are highlighted as the mouse cursor passes over them.

If you form a loop in the circuit, and the loop has three or four edges in it, a face will be built from those edges. The edges which will be affected by this are highlighted in purple. Upon completion of a face, a new circuit will be started at the last vertex clicked. If a circuit has more than four edges in it, the edges will be selected out of the circuit, but will remain in place, and no face will be created.

A right-click while a circuit is in progress will finish the current circuit of edges. The vertex being dragged and the edge that follows it will be destroyed.

A right-click while no circuit is in progress will take you back to select mode.
Once I got the hang of it, I found it really easy to do. Occasionally, I'd miss a point I intended to weld to. Initially, I'd go back and rebuild the loop (cursing the lack of undo, but eventually I discovered you could just drop the errant vertex on the intended target, and it would be welded together without all that hassle. Sweet!

One major disappointment that LionSnake is currently limited to polys with 3 or 4 faces. John had said that he was using a Loop subdivision scheme (which caused this limitation), but would be switching over to Catmull-Clark. Having had my share of problems with 5-sided patches, I was looking forward to playing with this a bit.

I found that building a web of points using the LionSnake was a lot easier than using mesh. The main weakness is that it's pretty stupid about splitting lines and faces, if you want to go back and edit the mesh. It currently introduces a number of extra faces, because of the limitations imposed by using the Loop subdivision. I suspect that when it moves to Catmull-Clark, it'll be a lot better.

One thing that's frustrating about the program is the lack of polish. I again suspect these things will get much better as time goes on. For example, the bones were really clunky to use. The less said about them, the better. The lack of undo was also frustrating, especially after lathing something along the wrong axis. :?

I was surprised to find LionSnake had uv mapping. The documentation notes:
You can apply uv-mapping to any face by right-clicking on it and selecting Add uv-mapping from the context menu. A default set of UV-mapping points will be added to the face.

Default uv-mapping is derived from the neighboring uv-mapped faces using the same texture, when the edges between are not sharp. If no neighboring face can be used this way, then the face's uv-maps will be set to default values based on the orientation of the face in the editing screen.

If uv-mapping is derived from a neighboring face, the two faces will share their uv-mapping points.

You can edit uv-mapping for a face by right-clicking the face and selecting Edit uv-mapping from the context menu. You will then be taken to uv-mapping view.

When you are in uv-mapping view, the uv-mapping for all of the faces that use the same texture are available for editing.

You can leave uv-mapping mode by selecting the menu option from the windows menu, or by selecting Mesh mode from the context menu.
It's not terribly sophisticated, but I imagine it shouldn't be difficult to implement, either. The UI is pretty clunky to use. I'd expect a "map faces to uv" mode, where you could then click on faces to add them to the uv map, instead of having to do it this way, which is pretty painful. LionSnake doesn't support multiple views - I could imagine this working nicely in JPatch, where in one view you could select faces, and the other edit the uv map.

It also supported face extrusion, but (like AoI used to) required the user enter the amount to extrude and size along the axis, rather than allow extrusion along the normal, like Wings3D. Bleah!

After playing with LionSnake, I can understand why JPatch is moving away from patches and to SDS. It's a whole lot simpler to build models using SDS, especially without the limitations that patch modeling imposes.

I'd played with SDS modeling in Wings3D and really liked it, but it was limited to closed models. I'd also used the modeler in Blender, but always found the interface difficult.

I've always found modeling in JPatch to be pretty intuitive, much like sketching in 3D. But I've always been frustrated by situations where I'd need a 5-point patch (or worse) and there seemed to be no legal way to create one.

Modeling in LionSnake has the same kind of feel as JPatch, which I really like. What it currently lacks is the ability to split mesh nicely, and to handle n point polys. Both of these limitations are based on using Loop subdivision. At the point where Catmull-Clark is supported, modeling in LionSnake will be pretty sweet... Except that it lacks all the polish and cool features of JPatch. ;)

Bottom line: I'm really looking forward to seeing SDS implemented in JPatch. :D
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Thu Feb 08, 2007 10:21 am

Just bumping the topic, now that you're back.

Is the new JPatch modeler going to use the LionSnake method, or something else? I'm curious... :P
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Fri Feb 09, 2007 12:49 pm

Yes, I've been very busy the last few weeks (home remodeling, a business trip, two children, you know...), so I've had virtually no time to work on JPatch. The good thing is that I tracked down and fixed a bug in the SDS code that annoyed me for a long time now.
SDS works perfectly for closed polyhedrons with all smooth surfaces. I've changed the code to support peak vertices and crease edges, which should work, but I have't been able to try it (I need to modify the modeler to allow the user to change the sharpness of vertices/edges).

Adaptive subdivision and stitching of patches that have been subdivided to different levels works perfectly.

Hierarchical subdivision should be possible, but again I first have to add such a feature to the modeler before I can test the subdivision code.

The recent changes slowed down the SDS code a bit, but it's still quite fast. All in all, with hierarchical SDS you can save many faces, to eventually the hierarchical SDS should still render faster than plain vanilla meshes. I think of adding a second, faster path for faces with no attached hierarchy data, but this hasn't got high priority.
Moving the entire SDS code into an OpenGL shader is a project on its own, I'll start working on that once the software version is finished, but this too hasn't got high priority (although I might be the first to implement hierarchical SDS in hardware :wink:)


As for the modeler look-and-feel I don't know yet. I think it will have many features from Wings, and I like its different modes (vertices, edges, faces, polyhedra). I'll have a look at LionSnake too. I think it will have a lot of features Wings lacks too: Interactive realtime adaptive subdivision, corners and creases, hierarchical modeling. And it will support open polyhedra too (treating the edges as boundaries like RenderMans interpolate boundary tag does).
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby pndragon » Fri Feb 09, 2007 8:27 pm

sascha wrote:Yes, I've been very busy the last few weeks (home remodeling, a business trip, two children, you know...), so I've had virtually no time to work on JPatch. The good thing is that I tracked down and fixed a bug in the SDS code that annoyed me for a long time now.
SDS works perfectly for closed polyhedrons with all smooth surfaces. I've changed the code to support peak vertices and crease edges, which should work, but I have't been able to try it (I need to modify the modeler to allow the user to change the sharpness of vertices/edges).

Adaptive subdivision and stitching of patches that have been subdivided to different levels works perfectly.

Hierarchical subdivision should be possible, but again I first have to add such a feature to the modeler before I can test the subdivision code.

The recent changes slowed down the SDS code a bit, but it's still quite fast. All in all, with hierarchical SDS you can save many faces, to eventually the hierarchical SDS should still render faster than plain vanilla meshes. I think of adding a second, faster path for faces with no attached hierarchy data, but this hasn't got high priority.
Moving the entire SDS code into an OpenGL shader is a project on its own, I'll start working on that once the software version is finished, but this too hasn't got high priority (although I might be the first to implement hierarchical SDS in hardware :wink:)


As for the modeler look-and-feel I don't know yet. I think it will have many features from Wings, and I like its different modes (vertices, edges, faces, polyhedra). I'll have a look at LionSnake too. I think it will have a lot of features Wings lacks too: Interactive realtime adaptive subdivision, corners and creases, hierarchical modeling. And it will support open polyhedra too (treating the edges as boundaries like RenderMans interpolate boundary tag does).

When do we get a demo to play with... I don't need a completely functional program, just enough to get a feel for it. Since you announced that you were dropping the patch modeler, I've been using Wings3d more to try to get a better handle box modeling.

--- Jim
"We're so sorry, Uncle Albert,
But we haven't done a bloody thing all day."
--- Paul McCartney
pndragon
 
Posts: 591
Joined: Sun Dec 05, 2004 1:27 am
Location: North Carolina

Postby dcuny » Fri Feb 09, 2007 11:21 pm

I created a Flash demo (230K) using Wink to show off some of the features I liked in LionSnake.

Notice that I didn't show any of the features like the Bones mode. ;)
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Sun Feb 11, 2007 8:46 pm

When do we get a demo to play with... I don't need a completely functional program, just enough to get a feel for it

Well, right now there are virtually no (SDS) modeling features, just those I need to test my SDS renderer. Once the SDS renderer is 100% finished I'll post a demo (should be really soon now).

I created a Flash demo (230K) using Wink to show off some of the features I liked in LionSnake

Thanks David, that's quite interesting. My thoughts about it are:
* I don't like those kind of programs that let you drag something (like the endpoint of a line) without need to drag with the mouse. These kind of UIs always confused me, and (worse), you never know how to exit this dragging mode (some programs use a right-click, others want you to press the ESCAPE key, and there are some programes where I actually never found out how to exit this mode). IMHO there's nothing wrong with click-and-drag to add a line segment.
* I've thought a lot about performing and (auto)weld operation when the mouse is released over an existing point, but found out that it is rather annoying. It works well for simple examples, but once there is a more complex onbject on screen, you keep accidentially welding to some points in the background. Since I got used to the behavior of all the patch modelers (left button still down + right click to weld) I really like it. But it only works fine with a cheap mose, something like the $40 Apple Mighty-Mouse has two buttons than can't be pressed simultanuously (but two button's one too much for the average mac user anyway :P) Does anybody know how the Mac version of A:M overcomes this problem?
My latest version uses JPatch's default behavior, but you can (additionally) use the SPACE bar instead of the right mousebutton.
* I think that seperate modes for point/edge/face/body operations would make sense. What should happen after a lasso-select (is it supported by LionSnake?), should it select the points, the edges, the faces or the objects inside the lasso?

These are just some thoughts, you know that months of arguing can convince me to change my mind ;-)
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Mon Feb 12, 2007 4:15 am

sascha wrote:I don't like those kind of programs that let you drag something (like the endpoint of a line) without need to drag with the mouse.
I agree, it's like getting something sticky attached to your fingers, and there's no way you can get it off.

I've thought a lot about performing and (auto)weld operation when the mouse is released over an existing point, but found out that it is rather annoying.
I've got mixed feelings about this. The key with any system working well is that you've got to be in control. I remember the old "auto weld" system, and the problems that it had. Still, it might be worth experimenting with.

I think that seperate modes for point/edge/face/body operations would make sense.
It works like Wings and JPatch does - you've got a button assigned to each mode. So if you toggle off the "Point Select" mode, it doesn't select points anymore. I found it works out well in practice.

What should happen after a lasso-select (is it supported by LionSnake?)
I didn't see any lasso select. There are a lot of features that aren't in LionSnake yet, which makes me appreciate how nice the JPatch interface is.

...should it select the points, the edges, the faces or the objects inside the lasso?
I haven't played with enough programs to have an opinion.

These are just some thoughts, you know that months of arguing can convince me to change my mind
That's 'cause I'm always right. ;)

Mostly what I liked about the program was how easy it was to build a mesh, in comparison to how JPatch does it (and doesn't always guess correctly). By making the user specify exactly which edges to use, it takes the guesswork away. It lacks the ease of JPatch, but I can see a lot of promise using it.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: LionSnake Modeler

Postby John VanSickle » Sat Feb 16, 2008 3:14 am

Saw my name mentioned and thought I'd drop in and say some things. I realize that this is an old thread, and I didn't go back and read to see if the newer threads have made some of what I'm saying less interesting, but here goes...

The n point polygons, which I've prophesied to be in version 1.7, will definitely be there, and is the reason for the change in the version number. Polygons can have up to 32,767 sides. There is no error-checking if you decide to take several hours to create a polygon with more than that many sides.

The real hold-up to v1.7 (aside from my ongoing addiction to Diablo II, and having to hold down a day job) has been developing the SDS macros for POV-Ray (which is the destination renderer). I got those working to my satisfaction yesterday (look in the povray.binaries.animations group on the news.povray.org server), using the Catmull-Clark scheme that you can find at graphics.pixar.com, kinda near the bottom of the page. It supports non-integral sharpness for edges, although not precisely in the C-C spec (although I intend to fix that).

All I have to do now is to write the file stuff (including exporting POV-Ray .inc files), and then v1.7 will be fit to be seen in public.

True, the UI lacks polish, but right now I am focused on increasing the features. One thing I did was to make the selection of objects more flexible; clicking on a vertex, face, or edge will select or deselect that item, whereas before selection was based on selecting vertices. Also, you can right click on a face and select not only that face but the entire contiguous section that the face is part of. I have tried to implement a "when in doubt, right-click" philosophy to the UI, and put everything related to an object in the context menu for that object.

One issue with v1.6.x is that there is a O(n^2) situation in some of the operations; one user reported a mesh with only a couple thousand faces that took over a minute to load. I managed to eliminate this, so performance should improve for large meshes.

On the other hand, subdivision preview took a back step (only one level of subdivision is displayed); the implementation has to change a bit.

I added the ability to import .OBJ format objects, so you could use this just to do OBJ files and not worry about POV-Ray at all.

The undo/redo feature, which some have said was absent, has in fact been a part of the application since December 2004, and although for a time it went buggy, it was rewritten and appears to be working. I even have a couple of pages on implementing an undo/redo feature in an application; the download page for LionSnake has a link to my home page, from which you can look at the stuff on undo/redo. The second page presents a far superior solution to this problem.

I presently plan to add two significant features to the modeler.

The first is a scene-building function, which is intended for exporting scenes and animations of the models, in POV-Ray script code. This is going to take a while; some things I've seen in Pixar behind-the-scenes videos have given me ideas.

At some point I will have the ability to add stock objects (the five regular polyhedrons, and other stuff) to the modeler. I may have that working for some later release of v1.7. It is the most requested feature, so far.

Regards,
John VanSickle
John VanSickle
 
Posts: 189
Joined: Sat Feb 16, 2008 2:17 am

Re: LionSnake Modeler

Postby dcuny » Sat Feb 16, 2008 7:49 am

John VanSickle wrote:The n point polygons, which I've prophesied to be in version 1.7, will definitely be there, and is the reason for the change in the version number.

I'm looking forward to playing with it. 8)

Hear that Sascha? You can stop working on the modeler features for JPatch and start working on the animation stuff! ;)

I got those working to my satisfaction yesterday (look in the povray.binaries.animations group on the news.povray.org server), using the Catmull-Clark scheme that you can find at graphics.pixar.com, kinda near the bottom of the page. It supports non-integral sharpness for edges, although not precisely in the C-C spec (although I intend to fix that).

That's one freaky looking video.

I added the ability to import .OBJ format objects, so you could use this just to do OBJ files and not worry about POV-Ray at all.

Stupid question - I assume that you'll have the option of exporting only the limit surface (i.e. the model without any subdivisions) for when you want to ultimately work with a program (like Blender or JPatch) which also support SDS?

The first is a scene-building function, which is intended for exporting scenes and animations of the models, in POV-Ray script code. This is going to take a while; some things I've seen in Pixar behind-the-scenes videos have given me ideas.

Well, that's certainly piqued my curiosity. :?

Thanks for the reply. I'm curious what sort of plans (if any) you've got for the modeler. In the past, most of your models have been rigged to run via macros, not unlike the use of Pixar's use of avars. On the other hand, I figure that anyone writing a modeling program is a scant few step away from writing an animation tool.

Also off topic, I'm still pissed the POV-Ray folk decided to let the IRTC die. It's been over a year, and as far as I can tell, there's been no effort made to revive the IRTC. It's certainly left a bad taste in my mouth. I'd post a complaint (as you did), but it doesn't seem to do any good. The IRTC deadline was one of the motivations for me to get Sascha to add animation features to JPatch. The new contest just isn't the same. :(
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: LionSnake Modeler

Postby John VanSickle » Sat Feb 16, 2008 4:35 pm

dcuny wrote:
John VanSickle wrote:The n point polygons, which I've prophesied to be in version 1.7, will definitely be there, and is the reason for the change in the version number.

I'm looking forward to playing with it.

The macros that support this in POV-Ray are now available at h**p://www.geocities.com/evilsnack/c2s3.htm.

I added the ability to import .OBJ format objects, so you could use this just to do OBJ files and not worry about POV-Ray at all.

Stupid question - I assume that you'll have the option of exporting only the limit surface (i.e. the model without any subdivisions) for when you want to ultimately work with a program (like Blender or JPatch) which also support SDS?

You have the terms backwards. The limit surface is what the mesh approaches as the number of subdivision levels approaches infinity. The hull is the base mesh, prior to any subdivisions. LionSnake works with the hull, with a limited preview of the subdivided mesh. (You can subdivide part or all of the hull within the modeler, but that alters the hull.) For a full subdivision, the user should export the mesh to the renderer.

The first is a scene-building function, which is intended for exporting scenes and animations of the models, in POV-Ray script code. This is going to take a while; some things I've seen in Pixar behind-the-scenes videos have given me ideas.

Well, that's certainly piqued my curiosity. :?

I want to have both a click-and-drag interface and a spreadsheet with the settings over time. I tawt I taw both in a Pixar video, so my ambition level is up there.

Thanks for the reply. I'm curious what sort of plans (if any) you've got for the modeler. In the past, most of your models have been rigged to run via macros, not unlike the use of Pixar's use of avars. On the other hand, I figure that anyone writing a modeling program is a scant few step away from writing an animation tool.

It shouldn't be that hard, although it did prompt me to covert the app from C to C++ (mainly to keep the code organized so that I don't go nuts I implement scene building, posing, and so on).

My other big ambition is to add some sort of scripting functionality, mainly so that users can extend the modeler's capabilities (procedural modeling and modeling physical characteristics) without need for a compiler. If I can bring that off, then I can move a lot of the functionality that is presently in C++ into scripts, and make the app much tighter (more portable for when I make it open source, less potential for crashing bugs, less potential for malicious add-ons). Once that works, the only real changes to the code base will involve C++ implementation of common, slow algorithms, and polishing the UI.
John VanSickle
 
Posts: 189
Joined: Sat Feb 16, 2008 2:17 am

Re: LionSnake Modeler

Postby dcuny » Sat Feb 16, 2008 11:47 pm

John VanSickle wrote:You have the terms backwards.

:oops: Thanks for the correction.

I want to have both a click-and-drag interface and a spreadsheet with the settings over time. I tawt I taw both in a Pixar video, so my ambition level is up there.

Yeah, I've spent an inordinate amount of time looking for clues at how Marionette (a.k.a. "menv"). Have you checked out Chant? It's spreadsheet mode has a strong similarity with Pixar's.

Of course, the key to Pixar's animation is the animators, but the fact that they haven't dropped menv makes me think they must be doing something right.

It shouldn't be that hard, although it did prompt me to covert the app from C to C++ (mainly to keep the code organized so that I don't go nuts I implement scene building, posing, and so on).

So it's only a small step to move to Java! ;)

My other big ambition is to add some sort of scripting functionality, mainly so that users can extend the modeler's capabilities (procedural modeling and modeling physical characteristics) without need for a compiler.

What scripting language did you have in mind? Lua is very popular, and probably well suited for the task.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: LionSnake Modeler

Postby sascha » Sun Feb 17, 2008 12:48 am

Hello John, thanks for your update and for joining our discussion over here.

dcuny wrote:Hear that Sascha? You can stop working on the modeler features for JPatch and start working on the animation stuff!

Nice try ;-)
But seriously, since JPatch is now based on Catmull Clark SDS, a way to import Lionsnake models would be a nice feature.
Direct import of SDS models would overcome some problems - of course you could load any polygon mesh as e.g. .OBJ file, but then you wouldn't be able to specify things like creases and corners, not to mention hierarchical edits.

I aim to be as RenderMan compatible as possible, so JPatch does support crease and corner tags as described in the Ri-Spec. It also supports non-integer sharpness values (and varying sharpness over a crease, it's described in some Pixar paper, I think it was Subdivision Surfaces in Character Animation from the graphics.pixar.com page).

Do you plan to support hierarchical modeling (i.e. editing the mesh at a higher subdivision level)?

The limit surface is what the mesh approaches as the number of subdivision levels approaches infinity.

That's right. I think I caused the confusion by sometimes referring to the "limit surface", so I'd like to clarify that:
Vertices can be "projected" to the limit surface (a slight modification of the standard Catmull-Clark SDS weights will project a vertex onto the limit surface instead of creating a new vertex-point at the next subdivision level).
This comes in handy when exporting to renderers that only accept polygons: You usually do some levels of subdivision, and after that apply the "limit projection" step. It's absolutely necessary when you don't subdivide all faces at the same level. In a similar step you can also compute u- and v-tangents (and thus precise normals).
When exporting to a renderer that can deal with SDS, you usually export the base mesh (since the subdivision is performed by the renderer). One exception might be when hierarchical edits were used, but the renderer can't deal with a hierarchical mesh - in this case you'd subdivide up to the level where edits have been made, and export the mesh at that level (as subdivision-surface, and without the "limit projection" step performed).
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: LionSnake Modeler

Postby John VanSickle » Sun Feb 17, 2008 2:05 am

sascha wrote:Hello John, thanks for your update and for joining our discussion over here.

dcuny wrote:Hear that Sascha? You can stop working on the modeler features for JPatch and start working on the animation stuff!

Nice try ;-)
But seriously, since JPatch is now based on Catmull Clark SDS, a way to import Lionsnake models would be a nice feature.

LionSnake .LSM files are now text-based instead of binary, and they are fairly straightforward; except that everything is zero-indexed instead of one-indexed, they're a lot like OBJ file.

Direct import of SDS models would overcome some problems - of course you could load any polygon mesh as e.g. .OBJ file, but then you wouldn't be able to specify things like creases and corners, not to mention hierarchical edits.

I had the notion of extending the OBJ format by including the edge and vertex tagging as comment lines. I was also thinking of developing a text file format for the skeleton data, so that the OBJ, MTL, and the skeleton file could describe everything; that way I could ditch my own format and just use already-existing formats. Unfortunately there was something about OBJ files that made me decide to stay with my own custom format. I'm toying with the idea of working with Collada files or .RIB files, but that's a decision for the future.

Do you plan to support hierarchical modeling (i.e. editing the mesh at a higher subdivision level)?

If I can think of a very simple data structure to handle it, I might; when it comes to adding features I like to pick the low-hanging fruit.

Vertices can be "projected" to the limit surface (a slight modification of the standard Catmull-Clark SDS weights will project a vertex onto the limit surface instead of creating a new vertex-point at the next subdivision level).

The part where this becomes complicated is that the C-C spec has been expanded to allow for so many different combinations of sharp edges, border edges, and vertex valences, the special cases can result in very baroque code to handle it all. The simplest solution may involve subdividing to where all of the involved edges are either smooth or infinitely sharp; then the number of cases drops down to a handful.

Each subdivision level reduces the distance between a vertex and its limit point by 75% (for regular and border vertices; extraordinary ones may be closer or farther, but I doubt by much). A point that starts one unit from its limit point is 1/4 a unit away after one subdivision, 1/16 after two, 1/64 after three, and so forth. In my tests, the difference between the third and fourth subdivision levels is very slight, and with normal interpolation are noticeable only to CGI geeks like us. Without normal interpolation, faceting is painfully obvious even after five subdivision levels (when each hull face is replaced by a thousand descendants).

One thing I noticed is that except at extraordinary points, and places where there are sharp or border edges, the limit surface for a quadrilateral is a bicubic spline patch that can be quickly calculated from the quad's corners and the surrounding 12 vertices, with C^0, C^1, and C^2 continuity guaranteed at the edges of the patch. Dunno if the guys at Pixar have discovered this yet... I can probably figure out the Bezier control points that correspond to this control set, which would make OpenGL rendering very easy.
John VanSickle
 
Posts: 189
Joined: Sat Feb 16, 2008 2:17 am

Re: LionSnake Modeler

Postby sascha » Sun Feb 17, 2008 11:02 am

The part where this becomes complicated is that the C-C spec has been expanded to allow for so many different combinations of sharp edges, border edges, and vertex valences, the special cases can result in very baroque code to handle it all. The simplest solution may involve subdividing to where all of the involved edges are either smooth or infinitely sharp; then the number of cases drops down to a handful.

My code initially used adaptive subdivision (for the realtime display), so the subdivision level for each face was determined by a heuristic which took the normal cone, the approximate size (on screen in pixels) and whether the face belonged to the silhouette or not into account. Therefor I had to use the projection to the limit surface after the subdivision - otherwise adjacent faces, subdivided at different levels would have gaps between them.
I had no real solution for the problem with computing the "right" limit position of points with crease or corner tags. If a point's crease or corner sharpness was higher than the current subdiv-level, I simply treated it as infinitely sharp. This worked well for realtime display, but could cause artifacts in high-quality renderings (that's why I'm glad that RenderMan has native support for SDS, so it's a problem the developers of the renderer have to solve :-))
One thing I noticed is that except at extraordinary points, and places where there are sharp or border edges, the limit surface for a quadrilateral is a bicubic spline patch that can be quickly calculated from the quad's corners and the surrounding 12 vertices, with C^0, C^1, and C^2 continuity guaranteed at the edges of the patch. Dunno if the guys at Pixar have discovered this yet...

They did notice it ;-)
If fact (as far as I know), PrMan treats regular faces (4-sided, each vertex of valence 4, no corners/creases, surrounded by regular faces) as b-spline patches, thus they can quickly "dice" these faces into micropolygons. Once thing to note is that after one step of subdivision, all faces are four-sided, and after two or more steps, almost every face is a regular face (by above definition), so this approach certainly pays off for the high levels of subdivision needed for high-quality rendering.
I doubt that it's very helpful for the relatively low subdiv levels (1 or 2, perhaps 3) normally used for realtime display in GL. Initially I took a similar, but different approach. I wrote a "dicer" that can handle all 4-sided faces, regardless of the vertex valences or crease/orner tags, and quickly subdivide them up to level 6. It simply loaded the data of the vertices surrounding the face into an array, and then quickly looped over the array to compute the next subdiv level - an other array holds the stencil types (wheter the next-level vertex is a vertex-, edge- or face-point), and the stencil-weights were stored in constants. In theory it should be possible to implement this algorithm as a GLSL fragment shader, thus it should be possible to run in entirely on the GPU. It would then require just one level of "software" subdivision, and do the rest in hardware.
I've only implemented a software version of the algorithm though, but it was quite fast.
The current version of JPatch doesn't use it though, because the datastructures required to quickly load the face+surrounding-vertices data into the dicer's arrays were too difficult to maintain in the modeler (everytime the topology changed I had to recreate almost the entire data of the whole mesh) - so I currently simply hold the entire mesh up to a given subdivision level in memory and use lazy evaluation. This is a bit memory hungry, but uses just the plain old half-wing datastructure and is very fast too.

LionSnake .LSM files are now text-based instead of binary

If you can point me to a description of the file format, I'll happily write an importer for JPatch.
JPatch's "native" format is XML, but I haven't yet defined a schema for the SDS version. Since I plan to add an exporter to .OBJ, I could also add a .LSM exporter.

As for hierarchical edits:
Pixar uses a "path" to specify edges, vertices or faces at any level. "4 0 2 3 1 2" could eg mean the vertex index 2 (at subdiv level 5) of face index 1 of face index 3... They use different indexes for regular and non-regular faces, so this is clear evidence that they treat 4-sided faces specially.
Search for "RiHierarchicalSubdivisionMesh", although the information available on the Internet is quite poor (the most valuable one is in a Google cache, with images missing :( ) - but if you can get access to a recent PrMan or Renderman for Maya documentation (it used to be available online, but isn't anymore), you'll find it there.
I think I'll use a similar approach (with a path) to store hierarchical edits to file. If many vertices have been edited at high subdivision levels, it might become cheapter to simply store the entire mesh at this level - so it might make sense to support both types, and use the one that produces smaller files.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: LionSnake Modeler

Postby John VanSickle » Sun Feb 17, 2008 9:06 pm

sascha wrote:
The part where this becomes complicated is that the C-C spec has been expanded to allow for so many different combinations of sharp edges, border edges, and vertex valences, the special cases can result in very baroque code to handle it all. The simplest solution may involve subdividing to where all of the involved edges are either smooth or infinitely sharp; then the number of cases drops down to a handful.

My code initially used adaptive subdivision (for the realtime display), so the subdivision level for each face was determined by a heuristic which took the normal cone, the approximate size (on screen in pixels) and whether the face belonged to the silhouette or not into account. Therefor I had to use the projection to the limit surface after the subdivision - otherwise adjacent faces, subdivided at different levels would have gaps between them.
I had no real solution for the problem with computing the "right" limit position of points with crease or corner tags. If a point's crease or corner sharpness was higher than the current subdiv-level, I simply treated it as infinitely sharp. This worked well for realtime display, but could cause artifacts in high-quality renderings (that's why I'm glad that RenderMan has native support for SDS, so it's a problem the developers of the renderer have to solve :-))

I may maintain the first two levels of subdivision internally, since that guarantees that all extraordinary vertices are surrounded by regular ones, and will make limit vertices simple to calculate; then I can use a biquadratic spline patch to render each of the quads at this level. V1.6.x already maintains two subdivision levels when the preview is turned on (and recalculates it every time a vertex is moved). Then there's a matrix multiplication for each patch to turn 25 vertices into 25 biquartic Bezier control points, and another matrix to turn the 15 vertices of a triangular patch into the 25 control points for a biquartic Bezier patch. I wrote this when I was between jobs, so it only took me a few days. I might just chase the second-level points to their final points and then use them as control points for biquadratic patches.

LionSnake .LSM files are now text-based instead of binary

If you can point me to a description of the file format, I'll happily write an importer for JPatch.

The current versions have an HTML in the download that describes the file format.

As for hierarchical edits:
Pixar uses a "path" to specify edges, vertices or faces at any level. "4 0 2 3 1 2" could eg mean the vertex index 2 (at subdiv level 5) of face index 1 of face index 3... They use different indexes for regular and non-regular faces, so this is clear evidence that they treat 4-sided faces specially.

The path for the 4-sided edit could simply be the index of the hull face, the subdivision level, and the row and column of the specific vertex, relative to the original hull. Works for any subdivision level.

I think I'll use a similar approach (with a path) to store hierarchical edits to file. If many vertices have been edited at high subdivision levels, it might become cheapter to simply store the entire mesh at this level - so it might make sense to support both types, and use the one that produces smaller files.

I expect that you'd have to edit a lot of vertices at the higher subdivision levels before storing the whole subdivided mesh becomes cheaper.

I'm also guessing that if the models are posable, then the subdivided points that are the product of points anchored to different bones will require a special transform for that point (a fractional transform of each bone in question), which is going to be a pain to keep track of.
Last edited by dcuny on Sun Feb 17, 2008 9:33 pm, edited 1 time in total.
Reason: Fixed missing quote tag.
John VanSickle
 
Posts: 189
Joined: Sat Feb 16, 2008 2:17 am

Next

Return to Development

Who is online

Users browsing this forum: No registered users and 2 guests

cron