clipka <ano### [at] anonymousorg> wrote:
> Am 14.09.2016 um 10:08 schrieb Mr:
> > clipka <ano### [at] anonymousorg> wrote:
> >> Fun fact:
> >> Trying to read obj files directly turns out to be only marginally faster
> >> than parsing mesh2 data (about 3% as it seems).
> > Interesting! Too bad it's not alembic files which, as a caching format, will
> > probably benefit from a simpler/faster export flow...
> Uh, I'd rather not. With Alembic being a quite modern format, users may
> expect support for a few more features than just polygon meshes, such as
> NURBS and things, and supporting those would be a _lot_ of work. OBJ, on
> the other hand, is old enough that people know better than to expect
> such bells and whistles to work with all software.
> Also, I haven't yet found /any/ documentation whatsoever about the file
> format itself, only a ready-made library; so implementing even a tiny
> bit of it would require more than the mere ~500 lines of code I added
> for OBJ import; it may also suffer in speed from additional code
> required to convert the data structures provided by the library to those
> used by POV-Ray internally.
> > Still OBJ is interesting! do you think it would be worth exporting Blender mesh
> > geometry to OBJ instead of Mesh2 or rather let you investigate and optimize the
> > mesh2, so that it will then be even faster ! :-) ?
> When it comes to import speed, I would suspect OBJ to maintain a slight
> advantage over mesh2, because the formats are reasonably similar in
> structure, with OBJ being just that little bit less verbose(*). Mesh2
> parsing /per se/ cannot be reasonably sped up any further as it uses
> POV-Ray's general parser infrastructure (by contrast, OBJ import
> accesses the file directly; which also means that you can't generate OBJ
> data "on the fly" procedurally, like you can with mesh2 data, except by
> the tedious process of writing a temporary file). Any potential for
> speedup of mesh2 parsing is in pieces of code that OBJ import would also
> benefit from.
> (* Or at least it has the potential to be, if exporters group the
> triangles by material before writing them. If material changes
> frequently between consecutive triangles in the OBJ file, the format can
> get /very/ verbose.)
So there is not a single feature in mesh2 that we'd lose when switching to OBJ?
could we still use smoothing groups? no limit in the number of points/faces...?
Why did you choose it over some binary format like 3DS ? wouldn't this be even
faster? maybe the partial update that could one day be implemented for
Post a reply to this message