I just sent meshcomp v2.0 to Colefax. It has, among others, mesh2 output
feature.
  Although it should output working mesh2 files, some questions arised when
doing it:
  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.
  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).


-- 
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

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

See? We DO need "mesh3"! ;)

Post a reply to this message

Nathan Kopp <Nat### [at] koppcom> wrote:
: 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?

  Perhaps separated blocks for triangles and smooth triangles? Something
like:

mesh2
{ vertex_vectors { ... }
  normal_vectors { ... }
  uv_vectors { ... }
  texture_list { ... }
  triangle_indices { ... }
  triangle_uv_indices { ... }
  smooth_triangle_indices { ... }
  normal_indices { ... }
  smooth_triangle_uv_indices { ... }
}

: 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.

  Perhaps you are right.
  Anyways you can use the mesh compressor to see how many normals really can
be put in the vertex vectors group.

-- 
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

Nieminen Juha <war### [at] cctutfi> wrote:
:   Anyways you can use the mesh compressor to see how many normals really can
: be put in the vertex vectors group.

  (Btw, wait for the version 2.0; it should work better)

-- 
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

How about this:

A current limitation (which I plan to keep) is that the face_indices section
must be specified before normal_indices or uv_indices.  Now, what you could
do is specify all of the smooth triangles first in the face_indices section,
and then all of the flat triangles.  Then, in the normal_indices section,
you just only specify enough sets of normal indices to put normals on the
smooth triangles.  Any faces remaining that don't have normals just get
turned into smooth triangles.  It would be easy to code, fast to parse, and
would keep file sizes small.

So, if you had a mesh with, say, 100 smooth triangles and 50 flat triangles,
you would specify all of the vertex, normal, and uv vectors.  Then have the
face_indices section where you specify all 150 triangles, with the 100
smooth triangles first, followed by the 50 flat triangles.  Then, in the
normal_indices section, you put only 100 entries - one for each smooth
triangles.  The remaining 50 triangles are then assumed to be flat.
Finally, you specify uv indices for each of the 150 triangles.

> : 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.
>
>   Perhaps you are right.
>   Anyways you can use the mesh compressor to see how many normals really
can
> be put in the vertex vectors group.

I'll check it out.  (in version 2.0, of course).   :-)

-Nathan

Post a reply to this message

That's a possibility, and not a bad one. The good thing is that it would
preserve backwards compatibility with the current implementation.

  I can send you the mesh compressor by mail if you want. It seems that
Colefax is not reachable right now (he hasn't responded to my mails in
a couple of days) so the "official" release may be late...
  You could check if the mesh2 output is ok or if it could be optimized.

-- 
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 Tue, 5 Oct 1999 23:28:11 -0400, "Nathan Kopp" <Nat### [at] Koppcom>
wrote:

>How about this:
>
>A current limitation (which I plan to keep) is that the face_indices section
>must be specified before normal_indices or uv_indices.  Now, what you could
>do is specify all of the smooth triangles first in the face_indices section,
>and then all of the flat triangles.  Then, in the normal_indices section,
>you just only specify enough sets of normal indices to put normals on the
>smooth triangles.  Any faces remaining that don't have normals just get
>turned into smooth triangles.  It would be easy to code, fast to parse, and
>would keep file sizes small.
>
Works for me (and it's be REAL handy not to have to create seperate
meshes for smooth and flat triangles).


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at http://www.who3d.cwc.net/

Post a reply to this message