Robert Grzeszczuk (rg)
Thu, 24 Jun 1999 13:02:57 -0700 (PDT)
You don't have to allocate the vertex data separately as a shared resouce for
all the FaceSets. For example, you can use the following overloaded version of
the constructor:
voIndexedFaceSet(int _countMaxV, int _valuesPerVertex, int _countMaxI);
which will create a suitable vertex data area for each individual FaceSet. The
problem with this apporach is that it may result in increased data
framgmentation: each of the FaceSets now has to have enough space to hold the
largest possible number of vertices that can be created in the process. In the
shared vertex data approach used by the demos, a single VertexData buffer is
shared among all the FaceSets, so the space requierement is mush less
restrictive. Namely, the buffer has to be able to hold all the vertices for
all the FaceSets. Using an arbitrary number in the inital allocation is
actually safe: the buffers will re-allocate themselves on overflow conditions.
The number of vertex records could, in principle, be computed exactly. In the
general case (a tetrahedron spanning multiple bricks), a sampling plane needs
to be clipped to the boundary of the tetrahedron and then to the clip box of
each brick. The intersection of a plane and a tetrahdron will be a triangle or
a quadrangle. Clipping the result to a box produces a polygon that is at most
a 10-gon (4-gon clipped by 6 planes). Given the oerientation, you could
determine exactly how many of what type of polygons are produced. Computing
the bounds is much easier: you will need at most 10 vertex records and at most
11 indices (1 for vertex count and 10 to point to VertexData records); the
lower bounds are 3 for vertices and 4 for indices. This is what you need to
represent a single FaceSet resulting from the polygonization process with a
single sampling plane applied to a single tetrahedron.
The number of FaceSets depends on the number sampling planes, number of
tetrahedra, and relative positions/orientations. For some geometries, any
given plane will intersect only a small fraction of all the tetras, in others
it may intersect them all (e.g., all the tetras forma long, straight strip).
As you can see, things get complicated.
Allocating the FaceSets during polygonization process, while optimizing storge,
has significant performance drawbacks: you don't want to make system calls on
per-frame basis. Therefore, polygonize() would have to include some form of
internal memory management functionality that designates new FaceSets from
pre-allocated pools. An alternative would be to create a "proxy" polygonize()
call that would not do any polygonization, but only determine what size buffers
are need for the given view. Preferences? Suggestions?
-rg
On Jun 24, 11:23am, Michael Buehlmann wrote:
> Subject: Transient Geometry
>
> In the process of allocating storage for transient geometry you first
> need to invoke the "voVertexData" method. In the demo programs this
> looks like this:
>
>
> ...
>
> // Holds all intermediate PER_VERTEX information.
> my_Data.allVertexData = new voVertexData(100000, valuesPerVtx);
>
> my_Data.aPolygonSetArray = new
> voIndexedFaceSet**[my_Data.maxBrickCount];
> ...
>
>
> How do you determine the (exact) number of vertices? Is it safe to use a
> static number like 100000 as in the demos or wouldn't it be better to
> calculate the countMax of vertices according to number of bricks (or/and
> other variables)? This problem relates also to Manfred's question about
> the volumizer design and transient geometry. Isnt't there a way to make
> the allocating of vertex information dynamically?
>
> With best regards
>
> Michael Buehlmann
>
> [ Attachment (text/x-vcard): "michael.buehlmann.vcf" 332 bytes
> Character set: us-ascii
> Card for Michael Buehlmann ]
>-- End of excerpt from Michael Buehlmann
This archive was generated by hypermail 2.0b2 on Mon Nov 01 1999 - 14:02:51 PST