Nieminen Juha <war### [at] cctutfi> wrote in message
news:37f860be@news.povray.org...
>   Is it true that you can't mix triangles and smooth triangles in the same
> mesh2? Currently the program outputs two mesh2's if there were both types
> of triangles in the input.

This is true.  That's something I didn't think of.  For now, you can mix
them by using the same normal index for each corner of any triangles that
should be flat.  Unfortunately, that doesn't do much for decreasing file
size.  :-(  Any suggestions?  Possibly you can specify "-1" for that
triangle in the normal_indices section.  The -1 would be parsed as a vector
<-1,-1,-1> which would flag the system to use a flat triangle.  But that's
kind of confusing.  Maybe a keyword?  But it should be short to maintain
small file size.

>   Have the vertex vectors and normal vectors to be separated? In the PCM
> format the same vector can be used for a vertex and for a normal (when
> optimizing). If I output to a mesh2 I apparently have to separate vertices
> from normals. This of course means that the optimizing of normal vectors
> is useless when outputting to mesh2 (well, not completely useless since
> you may have two normal vectors pointing at the same direction but with
> different lengths and the optimizing process can unify them, but usually
> normal vectors are already of equal length, so it's more rare that this
> would happen).

Actually, I would think having two normals pointing the same direction in
two different triangles would be much more likely than having a normal that
is exactly the same as a vertex.  Maybe in a sphere you could do some very
interesting compression that way, but I doubt too many circumstances would
act that way.  Anyways, because of the way that mesh2 works, it would
increase parsing times to do it that way.  The mesh parser uses some
interesting hashing techniques to optimize normals and vertices (and it
keeps them separate).  If I put them together, I'd have to optimize them
again in the mesh2 parser.  As it is right now, mesh2 should parse much
faster than mesh because it just reads the info directly into the mesh data
structure without any re-allocation or hashing.

Anyway, if you show me some numbers of how it would save tons of space to
put normals and vertices together, I'll look at it more closely.

Another change I want to eventually make is to allow different orders for
the sections.  Being designed for conversion program output, the mesh2
syntax requires a specific order for the various vertex/normal/index
sections.  This requirement could easily be removed, once I get some time
(motivation, really) to do it.

-Nathan

Post a reply to this message