Robert Grzeszczuk (rg)
Wed, 7 Jul 1999 10:06:35 -0700 (PDT)
After giving it some thought, I am ready to reverse myself on the issue
of providing an alternative to sparsly populated voFaceSets to hold
transient geometry as you've suggested. Such new paradigm comes at
some expense, though, and probaly will not be immediately available.
The discussion follows.
The most attractive characteristic of explicit transient geometry is
the implicit sorting that it provides. That is, the application does not
have to explicitly sort all the teras, because polygonize() action will
essentailly bin all the sampling polygons into a suitable voFaceSet.
Eliminating the transient geometry structure will require that all
drawing be done in "immediate mode." That is, all sampling polygons
need to be generated in visibility sorted order.
One approach that eliminates the need for any transient geometry storage
is to sort the tetra mesh in visibility order, and draw each of the
individual tetras separately. If a tetrahedron spans multiple bricks it
first needs to be clipped to brick boundaries and the resultgin clipped
polyhedron needs to be tesselated into tetras. The new pipeline would
look as follows:
for each brick in visibility sorted order {
voIndexedTetraSet *clippedTetraSet = clip(originalTetraSet,aBrick);
voIndexedTetraSet *simplifiedTetraSet = simplify(clippedTetraSet);
for each tetrahedron in simplifiedTetraSet in depth sorted order {
rasterize(aTetraSet); // i.e., Polygonize()+Draw()
}
}
For static scenes slip() and simplify() can be factored out of the loop.
Applications can manage their own display lists by enclosing the
rasterize() call will suitable OGL code. Alternatively, rasterize
action could take an extra argument (EXECUTE, COMPILE, COMPILE_EXECUTE)
and return an opaque handle. This last approach is less atractive as
different software platforms (e.g., OpenGL, Perfomer, FSG) may use
different "display list" implementations making platform independent
implementation more difficult.
Therefore, this new paradigm requires three new stages in the pipeline:
clipping of tetras, simplification, and visibility sorting of tetra meshes.
While clip() is a fairly straightforward procedure, it does produce
a large number of tetras which have to be simplified for the prcedure
to be feasible. However, tetrhedral mesh simplification is a much more
challenging task and may take some time to implement. Finally, visibility
sorting of tetrahedral meshes is often non-trivial. A simple topological
sort can be applied if the input mesh is simply connected, convex and
sortable, otherwise more complex methods may be required (see IEEE Vis98
for a couple of papers that deal with this issue).
Another benefit from using an explicit transient geometry structure is
the added flexibility in handing more complex volume rendering tasks.
For example, multiple volumes can be rendered easily by polygonizing
each of them separately and merging the resulting polygons. The sampling
polygons are then drawn using a suitable blending mode to achieve
a desired composition (e.g., additive to merge clouds, multiplicative
to apply color wash, etc.). Currently this is the only way to provide
this type of functionality. However, with the advent of multi-texture
extensions it may be possible to adopt the new paradigm at least in
VEWPORT aligned sampling mode (in AXIS aligned one has to create
an explicit BSP tree, or some other structure that will clip individual
sampling polygons suitably for drawing in visibility sorted order).
While immediate mode rasterization introduces additional technical
challenges and it is not general enough to completely replace the
original retained mode paradigm, it appears that there are substantial
performance and system utilization benefits from its use. I will put
in a RFP for this new feature. Implementation will follow depending on
resources available.
-rg
On Jun 23, 6:30pm, Manfred Weiler wrote:
> Subject: Questions concerning Volumizer design.
>
...
>
> On the other hand for most cases I see no need to create a (sometimes huge
and
> only parsely populated) transient data structure. Especially on low-end
> workstations without 3D texture interpolation this structure consumes much of
> the rare main memory due to the great number of "bricks". In addition to that
> I guess that working with this structure reduces performance because of quite
> a number of system calls (memory (de-)allocation, creating/deleting object on
> the stack).
> I admit that using this structure is more flexible but I think that
> display lists could do the same job and the vertices and polygons that should
> be drawn are stored where they will be needed.
> Maybe you will object that the transient geometry can be cached between the
> frames. But this leads to errors in the resulting image when the view
> parameters change, so for correct images slicing has to be performed in every
> frame.
> So why not add a draw method to Volumizer which works totaly without
transient
> geometry?
>
>
> Manfred.
>-- End of excerpt from Manfred Weiler
This archive was generated by hypermail 2.0b2 on Mon Nov 01 1999 - 14:11:13 PST