Because of the triangle malloc bug in the superpatch, I recently had to use
mesh2 instead of mesh. While the format is quite elegant, I had one major
problem with it: the need to specify the number of elements in the arrays. Since
I was reading in coordinates from a file, I had no way of predicting this
number. This made mesh2 generation rather cumbersome.
So the question: is specifying the number of elements really necessary? I would
imagine it only speeds up initial parsing. Dropping it would, IMO, make using
mesh2 easier.

Margus

Post a reply to this message

Margus Ramst <mar### [at] peakeduee> wrote:
: So the question: is specifying the number of elements really necessary?

  I think that the idea is that when you know the number of triangles, you
can allocate a memory block of that size (ie. just one array). This way
you save quite lot of memory (you don't need to waste memory for extra
information put into the nodes of a binary tree and the memory block the
system has to keep to control the allocations and deallocations). Handling
the triangles is also faster since you can directly index them instead
of having to walk through a tree structure.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Isn't mesh2 converted to mesh internally?
If so, does what you said still apply?

Margus

Nieminen Mika wrote:
> 
> Margus Ramst <mar### [at] peakeduee> wrote:
> : So the question: is specifying the number of elements really necessary?
> 
>   I think that the idea is that when you know the number of triangles, you
> can allocate a memory block of that size (ie. just one array). This way
> you save quite lot of memory (you don't need to waste memory for extra
> information put into the nodes of a binary tree and the memory block the
> system has to keep to control the allocations and deallocations). Handling
> the triangles is also faster since you can directly index them instead
> of having to walk through a tree structure.
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On Wed, 11 Aug 1999 21:50:48 +0300, Margus Ramst wrote:
>Isn't mesh2 converted to mesh internally?
>If so, does what you said still apply?

Yes.  The reason is that mesh2 is converted into the INTERNAL representation
of a mesh.  The internal representation is a pile of arrays.  The difference
is that a mesh is first put into a set of hash tables while the sizes of the
arrays are computed, then the contents of the hash tables are transferred to
the arrays.  Mesh2 is able to skip this intermediate step by adding explicit
counts to the syntax.  Mesh2 is really only intended for a machine-generated
mesh anyway.

Post a reply to this message

So should we make mesh3 for humans?

--
Anthony L. Bennett
http://welcome.to/TonyB

Non nova, sed nove.

Post a reply to this message

> So should we make mesh3 for humans?

	Maybe an external filter would do the
	job.  I have some code to convert
	VRML indexed face sets to POV mesh,
	maybe mesh2 would be useful too...

--
NIGEL STEWART nig### [at] nigelscom
Research Student + Software Developer
"Time is a train, makes the future the past"

Post a reply to this message

Margus Ramst wrote:
> 
> Isn't mesh2 converted to mesh internally?
> If so, does what you said still apply?
> 

Actually, the syntax of mesh2 more closely resembles the internal
representation of the mesh object (in fact, it is almost exactly the same
as the internal representaion).  And as was mentioned, the reason the
number of elements is required is for parsing reasons.  One other option
is for the parser to read the mesh twice, only counting items the first
time.  But, obviously, that would cause parse times to increase.  Another
option would be to allocate space, then re-allocate if the first guess
was too big.  Of course, you'd always have some extra allocated because
you probably wouldn't guess the exact amount.  You could then re-allocate
an array of the exact size and copy the data, but that means having two
copies of the data in memory at parse time, which is not a good idea for
large meshes.

Finally, mesh2 (as indicated by Ron) was designed to be generated by
comptuters.  Humans should probably still write using the original
mesh syntax.

P.S. Sorry I took so long to reply.  I just moved to a new apartment and
the phone company took their time getting the phone working.

-Nathan

Post a reply to this message

I see. Well, reading the number of elements is easy enough in POV script too,
although it's slow. I really wish POV had dynamic arrays. But that's another
story.
So, Ron, how's that update coming along? Or have you posted a version that fixes
the malloc bug?

Margus

Nathan Kopp wrote:
> 
> Actually, the syntax of mesh2 more closely resembles the internal
> representation of the mesh object (in fact, it is almost exactly the same
> as the internal representaion).  And as was mentioned, the reason the
> number of elements is required is for parsing reasons.  One other option
> is for the parser to read the mesh twice, only counting items the first
> time.  But, obviously, that would cause parse times to increase.  Another
> option would be to allocate space, then re-allocate if the first guess
> was too big.  Of course, you'd always have some extra allocated because
> you probably wouldn't guess the exact amount.  You could then re-allocate
> an array of the exact size and copy the data, but that means having two
> copies of the data in memory at parse time, which is not a good idea for
> large meshes.
> 
> Finally, mesh2 (as indicated by Ron) was designed to be generated by
> comptuters.  Humans should probably still write using the original
> mesh syntax.
> 
> P.S. Sorry I took so long to reply.  I just moved to a new apartment and
> the phone company took their time getting the phone working.
> 
> -Nathan

Post a reply to this message

Margus Ramst <mar### [at] peakeduee> wrote in message
> So, Ron, how's that update coming along? Or have you posted a version that
fixes
> the malloc bug?


We're all lined up in a nice orderly queue, with our tongues out and
panting!

Mick

Post a reply to this message

On the "plus" side, the malloc bug prompted me to explore the mesh2 syntax and
now the Poser 4->3DS2pov->mesh2 combination has become a favourite of mine,
particularly because mesh2 meshes are smaller and parse much faster than the
other meshes, which is very convenient when you have several of them in a scene.

Gilles

Mick Hazelgrove wrote:

> Margus Ramst <mar### [at] peakeduee> wrote in message
> > So, Ron, how's that update coming along? Or have you posted a version that
> fixes
> > the malloc bug?
>
> We're all lined up in a nice orderly queue, with our tongues out and
> panting!
>
> Mick

Post a reply to this message