But the layers are not always children of the "model root" node : there can be a matrix transform between "model root" and "layers parent", so I've added the name "Layers" on the node which contains all layers to easily retrieve the layers groups from application code."
- correction to writeFace : the fourth point was defined with an incorrect code (http://www.autodesk.com/techpubs/autocad/acad2000/dxf/3dface_dxf_06.htm)
- if no layer name was found, an empty string was used, with is incorrect according to dxf specifications and was rejected by Autodesk DWG TrueView
- the plugin was writting polygons and triangles as LINE, as if PolygonMode GL_LINE was active, and didn't use 3DFACE primitive.
I changed this behaviour to write 3DFACE as default, and LINE when PolygonMode GL_LINE is active.
when reading back the file with osg, the result is now consistent with the source
Tested with osg plugin, FME (Safe software), Autodesk DWG TrueView
"
crash with some files.
Actually, itr was incremented into the loop and after the test with
nlist.end().
Then, the unreferencing of itr when nlist is equals to nlist.end() caused
the crash."
Most notable the __hpux define stuff. The __hpux__ variant seems to be not
defined which resulted in a compile error at this time. Consequently I have
replaced all occurances of __hpux__ with __hpux. And huge surprise: now osg
plugins are found and loaded correctly ...
The next notable one is the MSVC_IDE fix which makes the nmake Makefiles cmake
generator target behave like the ide one. Showed up because I started to do
scripted builds with nmake instead of devenv...
The rest is the usual bunch of stuff that just happens during normal
coding ..."
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?
