CSG Modelling

(I need a Logo)

Space for this project was donated by the good people at Source Forge

CSG modelling is one of the main branches of solid modelling. It consists of combining predefined primitives using boolean operations. It is mostly used in CAD programs. How does that relate to RPG? When you think about it, when you are creating models for your game, you're doing very similar task to the CAD engineer: computer representation of real life objects.

CSG is indeed a great modelling technique but it isn't a one-fit-all solution. Since one is restricted to a predefined shapes, it is mostly useful for modelling man-made objects. Living things such as animals and plants are nearly impossible to create with CSG.

The language used to represent the models is taken directly from POV-Ray. Not only is it a great language which is easy to use, but also all the modellers that have been made for povray will also work with this modeller. But (you guessed it) there are some problems. POV-Ray files are incredibly difficult to parse. Fortunately, Christian Vogelgsang has created a library which does just that. A sligtly adjusted version of this library is included with this program. I'm still working on making is support povray 3.1

Download

The first version (0.0.1) of the modeller is available for download. It definitely isn't finished yet, but should be useable. The included version of ParPov should be able to parse any POV-Ray 3.0 scene files, I'm still working on support for 3.1

Compilation/Installation

The modeller uses GNU automake/autoconf so it should be fairly easy to build. You will need a recent compiler however. I don't believe in "being nice" to your compiler. If the language standards specify that it should be able to do something, then I better be able to use that feature. Therefore I suggest you get the latest gcc. The program itself doesn't require any other libraries or tools to build, but if you plan to make changes to the parser you will need ANTLR 2.7.0. The distribuition includes all the generated files, therefore you don't need it if you don't change the parser.

There is a very simple OpenGL previewer implemented. It is optional, and autoconf should correctly figure out whether it should be built. If you want to use the previewer, I suggest you use Mesa. You might even be lucky and you video card might be supported by Utah GLX

There is one problem with the compilation however. Since ANTLR creates quite big files which heavily use STL (which g++ will try to inline) you will need quite a bit of memory to compile the program with optimizations. There is one file in particular (ParPovLexer.cpp) that requires ~320 Meg of memory compile. Passing "-fno-default-inline" to g++ brings the memory usage to the more reasonable 100M range. Since not everybody has this much memory and yet I'm certain that everybody likes optimizations, I have made a binary available (Comming soon). I've made it using a whole bunch of flags and a few of them try to convince g++ that I have pII, therefore I'm not sure how they'll perform/run on any other member of the x86 family.

If you are planning to build the version straight from CVS, you will need a couple extra things. Since CVS is intended for developers, it doesn't include any of the generated files, so you will need autoconf, automake, libtool, a couple of autoconf macros, in particular, you will need the Java and OpenGL ones (I was thinking about including those on the cvs server but then I figured that it would be difficult to keep them up to date) and ANTLR 2.7.0. Of course you will need something to run antlr with, kaffe works just fine.

Info

How complete is it? It should work with the simple primitives such as Sphere, Cone, Cylinder, Box and Torus. I'm planning to add support for nearly every povray primitive (yes, even the plane). The 'inverse' keyword isn't supported yet, but will be in the future. There are still a couple of bugs I'm aware of. The two most important ones are caused by round-off errors and can cause some polygons missing or not rejoined properly. I have an idea how to fix those, and it will be done in the next release.

How fast is it? Well it isn't as fast as I'd like, but it is fast enough. This is not my first attempt to write a CSG modeller and let me tell you that compared to other approaches it is definitely quite fast. If you have PII/III you might try using --enable-speed-freak with configure. It will turn on some additional flags and it gives some speed boost. I still have some ideas on how to speed up the algorithm (especially the rejoining polygon part).

Screenshots

Everybody loves screenshots. (These are from an older version though, you will notice the black dots, those are caused by to many non-rejoined polygons and the helmet isn't quite correct because bounding boxes weren't working quite right. All this is fixed now, I will make some new shots soon)

These were made using the LEGO brick definitions by Anton Raves.