Procedural building

The technology used in the upcomming game "Spore" looks to be the next technology in simple integrated user content creation. The basis for this technology is coding an algorithm that generates objects and textures rather than using 3d files or in SL's current case prim and object settings/data. The result is a resource that is well compressed and requires small bandwidth. I think this technology can yeild visually seamless objects and better overhead.

There are problems with any system that means to replace an already existing system, but SL's graphics and development engine will need to mature soon.

For reference: http://www.gamespy.com/articles/595/595975p1.html

if i'm not mistaken, Prims are basically on that path already. unlike most games which use mesh geometries consisting of large data files (and then vector lighting tricks like normal mapping to simulate even higher levels of detail), Prims - and correct me if i'm wrong - are defined by simple equations. they're tiny by comparison. sent to our client and tesselated locally. reminds me of my CAD data (parametric files) more than my 3D model data (meshes and surface patches).

and LL has already indicated their intent to go with a "materials" editor (as used in apps like Maya). i take that to mean a procedural material system because that's what i use in Maya. whether that's what was meant, i'm unsure.

I am under the impression prims are defined by simple equations, it seems just like CAD. All I'm thinking of are more complex equations and client side libraries that can make things more seamless and easier to modify on the fly. Sorta like, If I put a ball on a cone I should have the option of making a seemless Weeble cone rather than an ice cream cone, if that makes sense. I certainly can't code procedural 3D applications in the time it will probably take a team to create a new Second Life engine, so maybe I'll just stick to dreaming.

Normally this could be hard to handle. but if SL's focus is getting bits over to the client as quick as possible, procedural is a very compact way of moving data.

My own concern would be how CPU intensive it would be to caculate those and keep them in sync for all users. Produdures are tiny, but can make massivly CPU intensive instructions.

Prims are pretty much where it's at right now.

While the idea behind Spore is interesting, not everything can be defined easily with an equation... which leads to making the data so large you might as well store it anyway.

Furthermore, anything you chop up in this manner results in less stuff you can do with it. Prims, for example, pale to the power of mesh and NURBs dynamics... but they're a concession along these lines.

I feel that, over time, things are moving more toward larger files that offer more options than smaller files and equations that are more limiting. But we'll see. This form of efficiency is great for some applications.