You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, mesh_from_array() relies on two external command-line tools (fq-mesh-simplify and draco_encoder), both of which use filepaths for input and output (not streams). A naïve implementation would incur the cost of disk I/O several times:
mesh_from_array() writes the raw .obj to disk
fq-mesh-simplify reads the raw .obj from disk
fq-mesh-simplify writes the simplified .objto disk
draco_encode reads the simplified .obj from disk
draco_encode writes the compressed .drc to disk
mesh_from_array() reads the compressed .drc from disk
Fortunately, most of those I/O costs are avoided in mesh_from_array() by using unix "named pipes" to write and read the data. Unfortunately, steps 3. and 4. could not be avoided: draco_encode requires a seekable stream (for no good reason, IMHO), which means we're forced to use the hard disk.
The only way to eliminate that last I/O penalty is to implement our own version of draco_encode, or to implement python bindings for the draco::Encoder C++ class.
The text was updated successfully, but these errors were encountered:
Currently,
mesh_from_array()
relies on two external command-line tools (fq-mesh-simplify
anddraco_encoder
), both of which use filepaths for input and output (not streams). A naïve implementation would incur the cost of disk I/O several times:mesh_from_array()
writes the raw.obj
to diskfq-mesh-simplify
reads the raw.obj
from diskfq-mesh-simplify
writes the simplified.obj
to diskdraco_encode
reads the simplified.obj
from diskdraco_encode
writes the compressed.drc
to diskmesh_from_array()
reads the compressed.drc
from diskFortunately, most of those I/O costs are avoided in
mesh_from_array()
by using unix "named pipes" to write and read the data. Unfortunately, steps 3. and 4. could not be avoided:draco_encode
requires a seekable stream (for no good reason, IMHO), which means we're forced to use the hard disk.The only way to eliminate that last I/O penalty is to implement our own version of
draco_encode
, or to implement python bindings for thedraco::Encoder
C++ class.The text was updated successfully, but these errors were encountered: