> > Is any info available on your tesselators?
>
> It's nothing really special, just a huge pain to code. I added a
> tessellation method to each object. Most primitives will have at least
> one specialized method as well as access to a general method such as
> marching tetrahedrons. Infinite shapes will have to have boundaries
> defined. I hope to eventually have CSG use the specialized method for
> the component shapes and process the meshes together, but need to
> research mesh processing algorithms some more.


(Sorry I didn't respond sooner; I somehow totally
forgot this thread.)

I'll have to look at that, since I'm now adding solid
rendering to the OpenGL patch. My approach to CSG would be
along the lines of:

primitive::render()
{
  tesselate primitive
  for each tesselated polygon
      if it is not totally clipped away by the CSG then
          if it is totally inside the visible CSG volume then
              render the polygon
          else
              make a tesselatable triangle primitive out of the polygon
              triangle.render(); // recurse
          endif
      endif
  next polygon
}

So, similar to REYES, "troublesome" polygons simply
get broken up into smaller and smaller pieces until
the CSG test becomes as easy as raytracing. The user
can also tune the dicing recursion level to trade
quality vs. speed. The only real hard part is making
good inside/outside determiner routines for a triangle checked
against each of the possible primitives. A lazy routine would
treat more polygons as needing dicing, slowing things down.
An obvious general determiner is:

state triangle::intersectsVolume(volume)
{
  if all of the triangle's points are outside volume then
     return tri_outside
  else if all of them are inside the volume then
     return tri_inside
  else return tri_intersects_volume
}

This would fail in special cases, like a triangle
whose plane is tangeant to a sphere and not quite
as far from the sphere's center as its radius.
The tri's points could all be outside, but the
center of the tri would not. What's interesting is
that again, a little recursion would resolve this
too in a general-purpose way. As long as you have
a point-within-primitive determiner and some patience,
recursion will suffice. I imagine complex isosurfaces
in CSG would be very compute intensive this way,
but then again, isosurfaces are better suited to
a raytracing paradigm.


> How does your preview currently function? An OpenGL preview was one of
> the ultimate goals of my patch, but I never got started on it.

The details are in the patch's readme.txt, but what I did
yesterday was to add a Render_Style INI parameter to treat
scanlining and raytracing as selectable render methods.
The options are

  PARSE     0
  WIREFRAME 1
  SCANLINE  2
  RAYTRACE  4

They can be or'd together except for wireframe and scanline,
since 'scanline' means 'solid'. So if you say 'Render_Style=5'
in the command line, the render window will display a wireframe
version of the scene, following by a raytraced version.

Option zero (the absence of all render styles) is useful just
to see how long parsing alone takes, or to test a bunch of
.pov files to see that they don't have syntax errors.

Now I can do 'Render_Style=1' in an .ini file, and emit
wireframe animation clips. As one would guess, they
emit pretty fast.

Ray

Post a reply to this message