There are some very useful triangle mesh generators in shapes.inc for making
mesh2 versions of a sphere, cylinder, torus etc., which can have real surface
displacement via functions. Not quite as useful or capable as true isosurfaces,
but they generally render faster (and you can choose the triangle resolution.)

To successfully use any of the HF macros in CSG, an inside_vector <.....> has to
be added...not in your SDL scene code, as it will not work there in this case.
Instead, it has to go inside shapes.inc. *Where* to put it may not be obvious.
The docs say it has to be placed "following all other mesh data, but before the
object modifiers." I found a place for it, down around line 998 in
the HF_Create () macro--the "Internal macro not intended to be called by user"--
which is used by all the mesh2 generators. The original code there is written:

.....
   #fclose _HFMACRO_OUTPUT_FILE
      #else
         }
         }
      #end
......

The appended code is this:
.......
   #fclose _HFMACRO_OUTPUT_FILE
      #else
         }
inside_vector <.......>
         }
      #end
.......

Although it works very well, and can be left in permanently with no problems,
I'm not so sure it should be permanent. There may be times when you want to use
a CSG difference to simply punch a clean hole into the triangle mesh (kind of
like the behavior of water_level when used in a regular height_field, simply
clipping away triangles.)  In such cases, inside_vector should not be used. The
docs also say, "This will only work for well-behaved meshes, which are
completely closed volumes. If meshes have any holes in them, this might work,
but the results are not guaranteed."  The HF_Cylinder macro produces a cylinder
with open ends--just a tube--but inside_vector still works OK for it. A happy
surprise.

IMO, the documentation concerning inside_vector is not perfectly clear about how
to apply it. The docs seems to imply that you can just stick the keyword in and
it works; but in fact it *must* be followed by a vector <......> with three
values--all of which can be random, in my experience. I've never yet run into a
situation where a *specific* direction vector had to be used.

Ken W.

Post a reply to this message