Attempt to implement real-time CSG (GeoMod of Red Faction 1)
Attempt to implement real-time CSG (GeoMod of Red Faction 1)
A very basic demo showing real-time CSG. The algorithm used in the demo is BSP tree merging by Bruce Naylor ( that algo is nearly 20 years old ).
I thought that would be useful to community because i couldn't find it on the Web (when i search for "GeoMod implementation with source code"
nothing shows up on Google). So, i did some research ( played RF, found many GeoMod bugs, read papers ) and i selected, of course, Irrlicht engine for graphics ( easy to use, high speed of development with it, etc. ). And this project had remained untouched for a month when i felt i was not going to finish it. My stupid studies keep me busy.
The demo is not about graphics, it's an attempt to implement something
similar to RF's GeoMod and test Irrlicht.
The download link:
http://www.mediafire.com/?sharekey=4f0f ... f6e8ebb871
Controls:
WASD, Whitespace - movement,
shoot with mouse, select "weapons" with mouse wheel.
Notes:
Remember, the demo is very glitchy ( esp. physics ).
After a few "CSG blasts" ugly holes between polygons may appear due to finite numerical precision. We need to use adjacency data structures to avoid that. (However, we may run into problems with texture coordinates - a real-life cube has 8 vertices, but a properly textured one has >= 12 vertices ... ) i did an earlier demo where i used a greater value for game length unit and such holes were almost unnoticeable.
We can also use an adjacency data structure to calculate vertex normals for correct lightning and detect isolated ( floating in space without any support ) chunks of solid material.
A simple Bullet collision shape based on a nodey BSP tree is implemented. It's very slow, using a dynamic BV tree would be a better choice.
Future improvements ( it's up to you to implement ) :
Use incremental linear programming to achieve a faster and more robust tree merging ( the paper is freely available ).
And I think we can use LP for quickly detecting isolated pieces of solid stuff - we should search for solid cells which don't intersect ( test LP feasibility ). It would be easy since each region is bounded by planes.
Then we can see how solid cells are connected and drop those which are hanging "loosely in the air". We can check if the volume of a solid cell
is infinite ( in LP, that means infinite number of solutions ) or if it exceeds a certain threshold and that cell and all other cells connected to it should remain fixed ( shouldn't fall down ).
Remember which branches of the tree have changed and generate mesh
only from modified parts of the tree ( keep indices in tree nodes ... ).
... Progressive BSP trees for LOD, some pertubations to mesh generation and materials to improve visuals ( because models look so low poly ) ...
Clever dynamic vertex and index buffers management is necessary.
I was a bit upset after looking at the source of Irrlicht... Later i will post some of my ideas which i hope will help you to improve your marvelous engine.
Any good, bad, or ugly feedback will be appreciated.
If you think I have left out something or you have some better ideas or you have problems with download or whatever, please feel free to e-mail me at usercodegen@ymail.com. ( And sorry for my english. )
I thought that would be useful to community because i couldn't find it on the Web (when i search for "GeoMod implementation with source code"
nothing shows up on Google). So, i did some research ( played RF, found many GeoMod bugs, read papers ) and i selected, of course, Irrlicht engine for graphics ( easy to use, high speed of development with it, etc. ). And this project had remained untouched for a month when i felt i was not going to finish it. My stupid studies keep me busy.
The demo is not about graphics, it's an attempt to implement something
similar to RF's GeoMod and test Irrlicht.
The download link:
http://www.mediafire.com/?sharekey=4f0f ... f6e8ebb871
Controls:
WASD, Whitespace - movement,
shoot with mouse, select "weapons" with mouse wheel.
Notes:
Remember, the demo is very glitchy ( esp. physics ).
After a few "CSG blasts" ugly holes between polygons may appear due to finite numerical precision. We need to use adjacency data structures to avoid that. (However, we may run into problems with texture coordinates - a real-life cube has 8 vertices, but a properly textured one has >= 12 vertices ... ) i did an earlier demo where i used a greater value for game length unit and such holes were almost unnoticeable.
We can also use an adjacency data structure to calculate vertex normals for correct lightning and detect isolated ( floating in space without any support ) chunks of solid material.
A simple Bullet collision shape based on a nodey BSP tree is implemented. It's very slow, using a dynamic BV tree would be a better choice.
Future improvements ( it's up to you to implement ) :
Use incremental linear programming to achieve a faster and more robust tree merging ( the paper is freely available ).
And I think we can use LP for quickly detecting isolated pieces of solid stuff - we should search for solid cells which don't intersect ( test LP feasibility ). It would be easy since each region is bounded by planes.
Then we can see how solid cells are connected and drop those which are hanging "loosely in the air". We can check if the volume of a solid cell
is infinite ( in LP, that means infinite number of solutions ) or if it exceeds a certain threshold and that cell and all other cells connected to it should remain fixed ( shouldn't fall down ).
Remember which branches of the tree have changed and generate mesh
only from modified parts of the tree ( keep indices in tree nodes ... ).
... Progressive BSP trees for LOD, some pertubations to mesh generation and materials to improve visuals ( because models look so low poly ) ...
Clever dynamic vertex and index buffers management is necessary.
I was a bit upset after looking at the source of Irrlicht... Later i will post some of my ideas which i hope will help you to improve your marvelous engine.
Any good, bad, or ugly feedback will be appreciated.
If you think I have left out something or you have some better ideas or you have problems with download or whatever, please feel free to e-mail me at usercodegen@ymail.com. ( And sorry for my english. )
Last edited by CodeGen on Sat Jul 11, 2009 5:40 am, edited 1 time in total.
-
- Posts: 758
- Joined: Mon Mar 31, 2008 3:32 pm
- Location: Bulgaria
-
- Posts: 914
- Joined: Fri Aug 03, 2007 12:43 pm
- Location: South Africa
- Contact:
super sweet
aweee yeah, this is exactly what i wanted... Thanks a bajillion.
Also very nice! It's awesome that we have something like this without having to lease the engine that RF uses....
The Open Descent Foundation is always looking for programmers! http://www.odf-online.org
"I'll find out if what I deleted was vital here shortly..." -d3jake
"I'll find out if what I deleted was vital here shortly..." -d3jake
mmm
http://www.xup.in/dl,79082444/GeoModWithIrrlicht.7z i started this linux CB port but am stuck.
And we need to improve surface clipping routines.
Suppose we carve a cube from a slab.
This is how they did in RF ( note the "wrapping" ) :
( These convex polys are then triangulated. Look at http://john.slagel.com/Geomods.html )
And this is what does my stupid implementation ( note how many polys it creates ) :
( i simply filtered surface polys through a tree ( RemoveFacesInsideNode(), RemoveFacesOusideNode() ). )
But i think that would be better :
Suppose we carve a cube from a slab.
This is how they did in RF ( note the "wrapping" ) :
( These convex polys are then triangulated. Look at http://john.slagel.com/Geomods.html )
And this is what does my stupid implementation ( note how many polys it creates ) :
( i simply filtered surface polys through a tree ( RemoveFacesInsideNode(), RemoveFacesOusideNode() ). )
But i think that would be better :
The demo was compiled under Windows, uses DirectX render API, doesn't use any shaders, but is very CPU-intensive ( it doesn't use hardware buffers for rendering, just raw mesh buffers placed in system memory ). And it crashes if it fails to create a sound device.
System requirements are pretty low but the faster CPU the better.
Bitplane, this technique works only with solid & non-solid materials, it doesn't take into account the material of the inside of the mesh.
I think that using pointerless structures ( half-edges and BSP nodes ) is the way to go. Knowing mesh adjacency would enable us to apply large decals to the mesh's surface, reduce polygon count ( merging coplanar adjacent faces), morph the mesh and so on.
After repeated operations trees may grow large ( in RF1, shoot many times at the same spot with a rocket and quite noticeable delays will occur ) -> we should use several BSP trees with their own dynamic mesh buffers and organize them in an octree or something like that.
And in a real world application we should precompile ( precache ) trees from geomod meshes ( it would be easy to store them, fast to operate on them, fast to transform them, as they would be pointerless, can be stored in linear arrays ) for better run-time performance.
Combining voxels with this method seems to be promising...
I'd like to see how people improve it to a point where it can become usable and how they use it in games. ( I currently have no time to do that. ) Or we can make a tutorial for beginners with a GeoModdableSceneNode...
System requirements are pretty low but the faster CPU the better.
Bitplane, this technique works only with solid & non-solid materials, it doesn't take into account the material of the inside of the mesh.
I think that using pointerless structures ( half-edges and BSP nodes ) is the way to go. Knowing mesh adjacency would enable us to apply large decals to the mesh's surface, reduce polygon count ( merging coplanar adjacent faces), morph the mesh and so on.
After repeated operations trees may grow large ( in RF1, shoot many times at the same spot with a rocket and quite noticeable delays will occur ) -> we should use several BSP trees with their own dynamic mesh buffers and organize them in an octree or something like that.
And in a real world application we should precompile ( precache ) trees from geomod meshes ( it would be easy to store them, fast to operate on them, fast to transform them, as they would be pointerless, can be stored in linear arrays ) for better run-time performance.
Combining voxels with this method seems to be promising...
I'd like to see how people improve it to a point where it can become usable and how they use it in games. ( I currently have no time to do that. ) Or we can make a tutorial for beginners with a GeoModdableSceneNode...
-
- Posts: 26
- Joined: Mon Jan 04, 2010 8:02 pm
Re: Attempt to implement real-time CSG (GeoMod of Red Factio
ah here yar my port attempt -- http://www.xup.in/dl,52841989/GeoModWithIrrlicht.7z/
http://www.xup.in/dl,97032263/GeoModWit ... t-orig.7z/
http://www.xup.in/dl,97032263/GeoModWit ... t-orig.7z/
Live long and phosphor!
-- https://github.com/netpipe/Luna Game Engine Status 95%
-- https://github.com/netpipe/Luna Game Engine Status 95%
Re: Attempt to implement real-time CSG (GeoMod of Red Factio
few screenshots? nice anyway
Junior Irrlicht Developer.
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
Re: Attempt to implement real-time CSG (GeoMod of Red Factio
Hi!
Stan Melax has recently opened the source of his impressive demo:
http://www.melax.com/csg.html
more details and link to the source code are here:
http://altdevblogaday.com/2011/09/02/destruction/
so we can expect to see real-time booleans in video games soon.
it will probably work on low res meshes and hardware tessellation will be used to add visual detail.
i have to say, this source code that i wrote is crap, and i feel ashamed for it.
in my current version each internal tree node now occupies 8 bytes instead of 64, nodes, planes and polygons are stored in a separate arrays,
but the code is still too branchy, and i'm not totally satisfied with it.
Stan Melax has recently opened the source of his impressive demo:
http://www.melax.com/csg.html
more details and link to the source code are here:
http://altdevblogaday.com/2011/09/02/destruction/
so we can expect to see real-time booleans in video games soon.
it will probably work on low res meshes and hardware tessellation will be used to add visual detail.
i have to say, this source code that i wrote is crap, and i feel ashamed for it.
in my current version each internal tree node now occupies 8 bytes instead of 64, nodes, planes and polygons are stored in a separate arrays,
but the code is still too branchy, and i'm not totally satisfied with it.