|
|
Here is a GeoMod demo.
Interactively blow away your 3D environment (constructive solid geometry boolean operations) via
bsp tree merging.
Download: MelaxCSG.zip
Unzip the downloaded file. Important note: After running the demo program and you've had your fun,
you may not be able to exit the program. The ESC key is supposed to do that but sometimes doesn't work.
The program grabs the mouse so, clicking on the close box is difficult.
Anyways, If you have this problem then just hit CTRL-ALT-DEL to get the task manager, arrow down to
the select the exe, hit tab to move over to the end process button and hit
space to press it. that will just kill the process.
You may also have to confirm that you want to kill the program in the "end now" dialog popup.
Again use TAB to select the "OK" button.
BTW this didn't happen when I wrote the demo sometime before XP service pack 2.
I haven't had a chance to fix this demo.
When unpacking the zip file be sure to tell your unzipping program to maintain
the directory structure used in the zip file. i.e. .jpg files should all be
extracted to the textures subdir, and .wav files to the sounds subdir.
That should be the default behavior of your unzip program anyways.
Note that the program grabs the mouse focus and keeps it centered to provide the
typical mouselook interface. The version here is a
couple years old now and my new game demo/engine isn't quite ready yet.
-
Standard mouselook interface.
-
Arrow keys or w,a,s,d
to move.
-
Use keys v,b, and n
to generate a small,med,large boolean at whatever point on the
wall/floor/whatever you are currently looking at.
-
Use keys 1, 2 and 3
to load/reload levels 1, 2 and 3.
-
Keys i,o
turn on,off alpha blended transparent walls.
-
Hit r
if you want to run faster and jump higher.
-
Hit l to toggle shadows. This requires stencil - so be in truecolor 32
bit mode eh.
See the attached
README.TXT
file for more information.
This is just a demo. Some notes
about this version:
-
Uhm, speed - its not bad but still a bit slower than it has to be. Although I'm
tired of rewriting everything from scratch, I've been reimplementing (yet
again) the convex polytope class and that all-important slice operation, in a
quest for faster merges.
-
got a couple of memory leaks - your swap disk space will be returned to you at
termination of the program :-)
-
Just doing something similar to a simple garbage collection lets me determine
when I have solid floating matter. In this case we can easily turn the static
geometry into dynamic objects. So if you carve out some matter by blowing holes
all around it, try and grab it with the mouse. I dont do it automatically. The
physics is really really flakey though. It can cause crashes. I have to
reimplement it again too and do it right this time. Also, performance suffers
as you add more and more dynamic objects. So be careful with this new feature.
-
The old pre-beveled dynamic plane shifting bsp algorithm breaks down with
booleaning. I now bevel on-the-fly during a collision query.
-
Get some better geometry to boolean the world with, the current convex boxish
thing is kinda lame. Currently I generate these by creating a cube and randomly
slicing it a couple of times. Then I have to compile a leafy bsp tree for this
object so i have something to merge into the tree. Obviously, it would be much
better to pre-cache a bunch of these and then just dup, translate, and merge
when needed.
-
Obviously the rendering engine in this demo is lame, but that's not the point
of this demo.
Enjoy.
Please note, that this is just a little demo. The ideas presented here are not
"new". Like most things in 3d graphics and video game programming, its a pretty
simple technique. To give credit where credit is due - Bruce Naylor published
the idea of bsp merging over 10 years ago in SIGGRAPH and GI graphics
conferences. It may be difficult to understand some of the finer details of the
bsp merging algorithm as described in the papers. That was my experience - hey,
at least i'm honest. I had to sit down and just derive and implement it all
myself. After that, everything made more sense. Its like when you were back in
school. Just reading the math textbook or listening to the teacher doesn't
enable you to pass the final - you have to work through some of the homework
problems. I guess I should now go back and look at Bruce's papers to see if I
did things the same way as he did.
I had also implemented
CSG
boolean operations a long time ago. Look at the boolean-op screen shots in my
polygon reduction article. That old implementation used a mesh-based
approach and contained hundreds of lines of needlessly complicated code. To
make it all work there was code for detecting which faces intersected with
which faces, cutting polys, retriangulating non-convex (possibly holey)
polygons, flipping edges to try and improve the triangulation, bla bla bla...
(Just by looking at the wire frame screenshot its quite evident that it isn't a
bsp based boolean operation.) Unfortunately it got very slow very quickly as
you did more boolean operations and added polygons. There was no spatial
hierarchy to the algorithm. Collision detection had not been addressed. It was
one of the many experimental technologies from when I was
prototyping/researching for MDK2. (Shameless plug: Even though we didnt end up
doing any geomod in MDK2 the game was really fun so feel free to go check it
out :-) Back then, I didn't know how to do boolean operations when I was
experimenting. Without any books or resources I just made-up (derived,
reinvented, whatever) a mesh based csg algorithm back then. At the time I
thought I had done something cool and revolutionary. I know better now.
I also had tinkered around with a voxel based method for
providing a modifyable environment. Again I though I was doing something new,
until I learned more about this marching cubes algorithm and realized my
approach was like a limit or binary version (voxel values 1.0 or 0.0 and
generate surface at 1.0) but then let the generated mesh's vertices "float
around". Hey, I didn't start out trying to construct isosurfaces to visualize
some scientific 3D voxel grid of data. I was was just thinking of ways to blow
holes in stuff, which hopefully would be fun in a video game. Trying to come up
with something based on voxel approach seemed like a good idea. As I tinkered
it became obvious that there were 256 cases (groupable by symmetries) I had to
deal with. It wasn't my intention to (almost) reinvent the wheel - oh well. I
haven't had time to work on any of this recently.
Using geomod (csg) in a real game will surely bring up many technical challenges
that are simply ignored in this little demo. Hats off to the cool guys at
Volition for doing such a kick ass job with Red Faction. Those guys must be
millionaires. If i'm lucky, maybe I'll get dozens of dollars if I am able to
publish my implementation in some book or a mag. Hmmm, I'm not sure if anyone
would actually be interested.
|
