Robert Grzeszczuk (rg@hoek.engr.sgi.com)
Mon, 28 Jun 1999 14:14:45 -0700 (PDT)
As much as it pains me to admit it, this is another bug. There is a
workaround though.
The dynamic allocation routine simply doubles the size of the index buffer
if adding a FaceSet were to cause an overflow. This heuristic assumes that
additions are "smallish" and that the initial value is "reasonable." Setting
an initial value to less than half of the first append, will thus fail.
The workaround is to make sure that the initial allocation is large enough
to satisfy the above requiement. If the tetras do not need to be clipped to
brick boundaries (e.g., only one brick or you are using
voGeometryActions::optimize() to clip the tetras to each brick), the
largest polygon that will ever be added in a single operation is a
quadrangle (5 indices). Thus, using 3, instead of 1, in the code below
will fix the core dump problem. In the general case, the
appended polygon can be a 10-gon (11 indices), so use 6 to initialize. :-(
-rg
On Jun 28, 1:09pm, Manfred Weiler wrote:
> Subject: Dynamically allocating transient geometry
> Some days ago someone proposed to dynamically allocate
> (parts of) the transient geometry, this should work because
> the voIndexedFaceSets will reallocate in case of overflow.
>
> I tried to do so by initializing each voIndexedFaceSet with
>
> my_Data.aPolygonSetArray[j1][j2] = new
> voIndexedFaceSet(my_Data.allVertexData,
> 1); // boundFaceCount(tetraCount));
>
> expecting that each faceset being reallocated to the needed
> size during polygonalization. But this didn't work.
> Nearly allways the programm exited with core dump.
> I inspected some of the voIndexedFaceSets an found out that
> in some cases the "count" member was bigger than "max_count".
>
> Does the reallocation really work correctly?
>
> Manfred.
>-- End of excerpt from Manfred Weiler
------------------------------------------------------------------------
This archive was generated by hypermail 2.0b2 on Mon Nov 01 1999 - 14:02:51 PST