Am 14.09.2016 um 09:46 schrieb Le_Forgeron:

>> I thought obj files had an ascii and binary version, but I was wrong.
>> That seems to be stl files. Maybe the binary stl format is faster to
>> read?
>>
>> https://en.wikipedia.org/wiki/STL_(file_format)
>>
> You can give it a try in hgpovray (there is a stl_load and stl_save )
> 
> https://github.com/LeForgeron/povray/wiki/Tesselation
> 
> The main issue with povray mesh import is the unique indexing of
> vectors: when the data structure is not like mesh2, each new component
> need to perform a search in previous values.

Ah, yes, and then there's that -- I totally forgot about that in
conjunction with STL. So OBJ will be faster anyway.

But I would put it the other way round: That's the main issue of naive
file formats which store triangles as a list of vertex coordinates,
rather than having a list of vertices and only storing vertex indices
per triangle.

That's absolutely not unique to POV-Ray; every sane piece of software
handling meshes does that internally. So exporting to a naive format and
re-importing is just a plain waste of time.

> Even the parsing of a mesh get slowed down as the number of triangles
> increased. Fast for 100, Normal when reaching 10 000, crawling after 1
> 000 000.

I guess some improvements could be made there. AFAIK the mesh code uses
a homebrew hash map for this purpose; large meshes may easily outgrow
the hash table, and a search tree would be more performant there.

But if speed is really of paramount importance, and memory not so much,
there's always the possibility of just storing duplicate vertices.

> Mesh2 avoid the search because the uniqueness is done before (by the
> generator of mesh2).

Not even by the generator of mesh2; the uniqueness is inherent in every
mesh editor that deserves the name (otherwise it would be a disconnected
triangle editor).

Post a reply to this message