Parametric deformation modelling

Watch poemtoahorse, zoom 3.

Pretty cool stuff, zoom3 is a 64KB intro containing about 80,000 vertices and 150,000 faces - or about 4MB of uncompressed 3-D data - in 10KB. (That is according to the end-scroller, and I believe it is true.) poemtoahorse is pretty much the same kind of thing, except that they use more organic shapes.

The idea is pretty cool - instead of storing thousands of vertices and faces, you start with primitives and then store only the instructions necessary to shape the primitive into its final form. It's the same idea as storing a picture as a series of vectors, rather than pixel-by-pixel. I am referring to it here as parametric deformation modelling for lack of a better name. It can be used to create pretty much any shape you can imagine.

I realize there are probably two main objections to this.

First: The models compress extremely well (obviously) but they still have to be unpacked, rendered into their many-vertices final forms, and then finally sent to our video cards. This could slow things down considerably. I am aware of that. This is a suggestion for something LL might like to do at some point in the future, when it won't be such a burden on the average hardware. (Then of course you have ActiveWorlds, where people already have models with thousands of vertices, and it seems to work fine, so maybe it isn't that much of a burden after all.) As far as the physics engine is concerned, we don't have to have it collide every last face, we can use bounding boxes to approximate it.

Second: Won't work with 3DS etc. Well, I don't think LL wants to encourage people to build outside the game, so I don't know that they would care. We'll be lucky if we see an external avatar skinner, and that's probably driven more by people being tired of wasting hundreds of L$ trying to get a shirt to look right. I suppose this idea could be compatible with external parametric modellers if they use this particular method, but probably not 3DS and others that like to store vertices and faces instead.

Now on to advantages. This could be made to work with the current modelling system, sitting right on top of the primitive types we already have. It would also fit with the in-world building aspect that LL seems interested in. And, of course, the #1 advantage is that it would allow us to build better-looking objects.

How does the current SL model system work? Or is it a Linden secret?

They're parametric models, like the ones used in the demos mentioned above, but not as complex. A few variables are passed to the client and it draws one of the half-dozen prim types available to us with the specified scale, rotation, cut, hollow, etc.

I would like to have a mode in the build tool that allows us to click and drag individual vertices and maybe control click to add a new vertex. That would be so nice.

The .Product people actually are very clever with their demos

They don't just do the prims

They do prims (like SL) plus allow the CSG combination of prims, and vertex editing - but they store it as a sequence of steps to generate the model instead of the model itself.

Example:
Create torus (radius, etc) (doable in SL)
Slice Torus 1/3 to 2/3 (doable in SL)
Scale 2x along X (doable in SL)

Create Cube (dimensions) (doable in SL)
Combine Cube and Torus (doable, sorta, in SL, except .Produkt allows CSG operations)
- Union Combine (Kinda available, not really tho, since unions eliminate inner vertices and faces)
- Difference Combine (really powerful, not available in SL)
- Intersection Combine (Ditto)

Then the thing that makes them really over the top is the fact that after all of these ops, the user can then apply scale/move operations to regions of the models (This would not translate well to SL since models have varying # of vertices and faces depending on detail level).

If SL had CSG though, it would be awesome. I'm sure its possible, but I dunno how the physics engine would like it...

For those who need a visual rep of CSG:
http://www.student.math.uwaterloo.ca/~s29wong/Objective2.htm

First image shows shapes achieved by two spheres unioned, underneath that, intersected, underneath that, subtracted.

Same thing for next image, on torii and stuff.

Basically, saying 'cut this shape out of the other shape'.

now... for the really crazy stuff...

The .PRODUCT demo does the SAME THING for all their textures! Instead of being saved as a bitmap, they start with a blank image, and save the STEPS the artist took to get to the final image. Basically, art primitives!

They do the same with music and sound.

Then they compress it.

Thats how it gets down to only 64k

Linden Lab's main requirement is small data sizes so transmission bandwidth is kept as low as possible. Their second requirement is keeping it easy for the residents to make content. Procedural textures aren't going to happen until there are easy-to-use graphics editors out there that can make such things easily.

But they COULD do CSG as far as I can tell, and it would vastly expand the building potential of Second Life.

Adding something like X and Y-axis hollow functions would add more data to the description of prim, but allowing you to join or subtract two prims would add nothing, and would in fact REDUCE the amount of information necessary to make many shapes.

All they'd have to do is expand the linking system too support nested links, and add three new link types: Union Link, Difference Link, and Intersection Link.

Example:
Make a cube and a cylinder.
Position the cylinder diagonally through the cube.
Select the cylinder, then the cube.
Choose Difference Link from the menus.
(The cube gets a round hole diagonally through it.)
Make another cube.
Select it and the holled cube.
Choose Link (the regular one).

Unlinking this second link separates the two cubes, but leaves the cylinder difference-linked to the one cube. Select it and unlink to return them to normal, and perhaps re-position the cylinder.

Hah! Zoom3 is just like SL! The ATI drivers didn't work with it, so they had to code a workaround! Stupid ATI people.

LL's main issue with this is that arbitrary concave objects are "hard" to handle the physics for. I think that a combination of mixed linking (phantom and solid) and bounding boxes would pretty much take care of that.

Aye I was thinking not just that. Since the prim is stored as just a series of commands to maulpilate the original prim, the physics engine would have to recalculate the size/shape/volume of every physics object everytime (in realtime too!) just to determine whether a collision has happened.

I think that would be too processor/memory intensive for the current hardware.