At the moment it outputs DXF for whatever geometry is contained in the node it would be nice to draw the model as it is rendered (points/lines/surface)
If people could also test against other apps that need to read DXF, the format is a bit of a black art and not all importers support all features so it might need some options to tweak the output.
It has some rather clever colour lookup stuff to match real colours against the limited DXF palette. I cracked the code of the Autocad indexed colours!"
It adds two options:
Accuracy(x) - ensures the polyline will be within x units from the ideal arc/curve
ImproveAccuracyOnly - do not use the given accuracy 'x', if it would result in a worse curve than with the previous (2.8.0) implementation for a particular arc/curve.
As an added bonus there was a small bug in the existing implementation whereby the primitives were line strips but the vertices generated were actually suitable for GL_LINES, so the improved accuracy doesn't even have to come at a performance cost :-)"
It's really just a cut-paste job from the existing LINE support.
The current dxf plugin architecture isn't very efficient, especially if you
are loading large point clouds (LIDAR)
eg. it makes multiple lookups of the layer name for each vertex.
I don't know if I can improve this for the general case or if I have to add a
special large point cloud dxf reader."
completed the new registration of the plugin-readerwriters
("REGISTER_OSGPLUGIN") according to your osgstaticviewer-example (see
attachment, based on today's svn)."
dxfSection classes, so their members data are correctly deleted.
- changed some methods signatures to pass arguments by reference instead of
by value. The performance and memory usage are enhanced (the reader was
clogging the heap when reading some large DXF files)
The updated files have been compiled and tested with a variety of DXF files
on XP with VS2003, but the changes should not disturb any other compiler."
following improvements:
- When all unsupported entities (SOLIDS, TEXT, ...) have been filtered out
from a block, dxfInsert::drawScene() was crashing because it assumed that
the block was not empty. It now returns silently so the other blocks can
still be imported.
- The DXF reader assumed all vertices were read first, then the face
indices. But, from the DXF "documentation" (www.autodesk.com/dxf) :
"Polyface meshes created with the PFACE command are always generated with
all the vertex coordinate entities first, followed by the face definition
entities. The code within AutoCAD that processes polyface meshes requires
this ordering. Programs that generate polyface meshes in DXF should generate
all the vertices then all the faces. However, programs that read polyface
meshes from DXF should be tolerant of odd vertex and face ordering."
So now the importer ignores the posted number of vertices and face indices,
and uses the size of the lists instead."
There are some group codes (i.e. "62") which are interpreted as
dxfDataType::SHORT. That's right because the dxf-specification defines
"16 bit integer" as the type for the corresponding value.
But readerBase::readGroup() calls readValue(std::ifstream&, unsigned
short). I changed readValue(std::ifstream&, unsigned short) to
readValue(std::ifstream&, short). I found no group code at the dxf-specs
which needs a "16 bit unsigned integer" value. So the
readValue(std::ifstream&, unsigned short) function is obsolete - right?
