Best way to generate procedural models?

Anything and everything that's related to OGRE or the wider graphics field that doesn't fit into the other forums.
Post Reply
Lithidd
Gnoblar
Posts: 18
Joined: Sun Apr 17, 2005 9:12 am

Best way to generate procedural models?

Post by Lithidd »

I'm working on a little demo project that uses some (highly abstracted) genetic methods to create 3d models.

I'm still in the design phase, and I'm thinking about the best way to go about it.

My current plan is to generate a mesh with a fixed number of vertices; the model will be defined by the distance between various vertices and pairs of vertices, etc.

Is this the best way to go about procedurally generating models in this way? Is there another technique which might be better?

Lithidd
Gnoblar
Posts: 18
Joined: Sun Apr 17, 2005 9:12 am

Post by Lithidd »

Hrm. Some further investigation and Googling, and it looks like metaballs might be the way to go. Seems a much more flexible way of doing things, and for what I want to do, potentially much more appropriate.

User avatar
SuprChikn
Bugbear
Posts: 863
Joined: Tue Apr 19, 2005 6:10 am
Location: Melbourne, Aus
Contact:

Post by SuprChikn »

Well in that case, take a look at this thread.
And apparently you might get more joy searching for "isosurface(s)" (that's according to DWORD in this thread).

Lithidd
Gnoblar
Posts: 18
Joined: Sun Apr 17, 2005 9:12 am

Post by Lithidd »

Yeah, I saw that one, and I've downloaded the source and will be fiddling with it over the next few days. Very cool stuff.

Plenty of stuff about 'marching cubes', too ... it's a bit sad that GE has a patent on this algorithm. Looking into the meat of the patent though, I found this interesting little paragraph:

In the prior-art method, densities and gradients for all subcubes within a large cube were calculated at one time. In a typical situation, if all the values for an entire subdivided row were calculated at one time in the array processor method, up to 128K memory locations or more would be needed to store four values (one density and three gradient components) for each of up to 64 subcubes per marching cube in each row, with up to 512 cubes or more per row.

I'm not a lawyer, but it looks like this patent is on a specific implementation of the marching cubes algorithm ... so presumably, to get around the patent, we just need to make sure all the values for an entire subdivided row are calculated at one time. =D

User avatar
Harlequin
Kobold
Posts: 35
Joined: Thu Oct 16, 2003 9:29 pm
Location: Germany
Contact:

Post by Harlequin »

There are other algorithms for isosurfaces, which are not patented, search for "marching tetrahedrons" or stuff like that. Those are even offering better results.
team-pantheon programmer
creators of Rastullahs Lockenpracht

User avatar
DWORD
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 1365
Joined: Tue Sep 07, 2004 12:43 pm
Location: Aalborg, Denmark
Contact:

Post by DWORD »

The .zip I posted supports both marching cubes and marching tetrahedrons. (Just noticed the docs in the .zip are not up to date; they only mention the tetrahedron version.) In fact I found that the marching cubes version looks better, and performs better because it generates much less faces. The look is strongly influenced by the way normals are calculated, though, and didin't really find a solution that satisfied me.

Lithidd
Gnoblar
Posts: 18
Joined: Sun Apr 17, 2005 9:12 am

Post by Lithidd »

Yeah, I saw the comments to that effect. =P

Once I've understood it properly, I'll fiddle around with it. If I come up with anything worthy, I'll post an updated version. It's cool stuff - did you end up using it for anything?

Post Reply