dxf file some problem

[Dylan-H]

I'm preparing to migrate from osg to vsg. I use osgviewer.exe and vsgviewer.exe to load the same dxf file.
But the lines displayed by vsg do not have the original color。
vsgviewer.exe use assimp to load dxf

vsgviewer.exe use osg2vsg to load dxf,can not display anything

System environment： Win10 +VS2019
vsg，vsgXchange，osg2vsg , all are the latest master branch codes
osg:3.6.5

[robertosfield]

I have seen issues with the Assimp's dxf loader but haven't had a chance to investigate. It may be that we need to write a dedicated loader for some formats that aren't well support by Assump, or for us to improve the Assimp loader itself.

Would it be possible to provide example dxf models that illustrate the particular issue you are seeing?

[Dylan-H]

Collaborator
Thank you reply.This is my DXF file
Yard March 5.zip

[robertosfield]

Your links is just empty link, you'll need to put the URL into the () section of the link markdown.

[Dylan-H]

Your links is just empty link, you'll need to put the URL into the () section of the link markdown.
sorry，Already resubmitted

[robertosfield]

Thanks, I've successfully downloaded and tested the DXF model on my system and confirm the results you are seeing when loading with osgviewer & vsgviewer.

There are two issues that are apparent from a simple first look at the two viewers:

1. The colours are missing from the vsgviewer version,
2. The is jitter on the vsgviewer version.

I busy completing other work right now so I can't dive deeper at what is going wrong in the vsgXchange::assimp loader on this model. In general vsgXchange::assimp does a good job of converting Assimp loader models but if Assimp itself isn't handling the model well then the vsgXchange::assimp code that converts to VSG won't be able to fix these issues.

It may also simply be the way the colours/state are encoded by Assimp for this model differs from what we've been testing previous and we'll add to add an catch for this usage case and handle the mapping to VSG differently.

The jitter might partly caused by Assimp if it's converting double vertex data to float vertex data and loosing precision there. We will need to add some debug code into the vsgXchange::assimp to figure out what Assimp is returning in this instance.

The OSG's XDF ReaderWriter can cope with the precision issue as it will be converting double vertex data to float vertex data stored in osg::Geometry but moving the vertex data to a local origin first before conversion then decorating the created scene graph with a MatrixTransform that moves the local original back into original world coordinates. The OSG support for double Camera and Transform matrices and accumulation of them then allows rendering without jitter.

The VSG uses a similar double Camera and Transform matrices scheme to the one the OSG has -I wrote both, so the best features of the OSG I've carried across the VSG. However, this scheme does need the models to be loaded with knowledge that this scheme needs to be used when handling datasets with very large coordinates.

Resolution of this buggy loading of DXF files will require an investigation into Assimp and whether it can correctly handle these files, and if it can handle both the colours and coordinate issues correctly then for the vsgXchange::assimp loader to be refined to handle the colours and coordinates in better way, but failing that a DXF loader would have to be written.

If we have to resort to writing a vsgXchange::DXF then this would be more work, but as we have both Assimp and the OSG's DXF loaders as examples I would expect it would be quicker to write than it originally took to write the OSG's DXF loader. FYI, the OSG's DXF loader was a community contribution so I wasn't the original author, but I did help refine it over the years.

[Dylan-H]

Oh,this seems a bit troublesome.
It seems that VSG's development strategy is to prioritize the use of third-party libraries to load 3D models.
I feel regretful about giving up so much code for osgplugins(The osg2vsg repository also seems to have some issues,also depends on a lot of osg code，not very elegant).
Is there any plan to use a solution similar to the osg plug-in to transplant the original code?

////////////
I'm sorry if my English is not good enough and caused any confusion. I'm still learning and trying my best.

[robertosfield]

Both the OpenSceneGraph and VulkanSceneGraph projects evolved over time. When we developed the OSG there was no 3rd party like Assimp to help enable loading of a wide range of formats so the community had to pitch in and develop dedicated loaders for the most widely used formats - most of the OSG code base is loaders. Essentially if users had a need for loading/saving to a file format they rolled their sleeves up and got coding and contributed their work.

When I started work on the VSG Assimp project was already pretty mature so it made sense to leverage it to load a wide range of file formats in a standard way, and actually enabled us to load formats that are poorly supported by the OSG. Assimp isn't perfect though, finding out what those areas are lacking takes end users testing with a wide range of real-world data.

You've come across a deficiency in vsgXchange::assimp combination w.r.t DXF so it's a case of coming up with a strategy to resolve them, be that changes to vsgXchange::assimp and/or Assimp, or writing a dedicated DXF loader.

The VSG is an open source project, just like the OSG, myself and @AnyOldName3 are now working full-time on VSG related client projects, and the income from that enables some time to be kept aside for open source development and support. End users can help out by contributing fixes/developing code/providing support to others, or by commission us to tackle work that is a priority for companies that use the VSG.

The osg2vsg project needs a major rewrite, it was written very early in the life of the VSG project to enable us to get data into the new scene graph so we could test various features of the rapidly evolving scene graph. Since that early development focus has moved to vsgXchange and the VSG itself with osg2vsg not receiving further development and it's fallen behind vsgXchange/VSG capabilties.

My intention is to rewrite osg2vsg using modern VSG capabilities, though I've been so busy with other VSG work (that pays bills) I haven't had the chance to tackle it. If clients need osg2vsg and are willing to help fund it's development then we will be able to raise the priority on this development. I already dedicate half my hours to unpaid open source work so you'll understand that there isn't capacity to just go chasing more unpaid work because some users would like feature X or Y for free, yesterday.

As there is finite development resources we just have to pick priorities and tackle what we can, when we can, and if members of the community need features quicker than is happening this way then they will still need to roll their sleeves up like happened for the OSG project (most of the loaders in the OSG are written by the community.)

[Dylan-H]

😊，Got it, thank you very much for your contribution to open source。I also like open source.
If I or others have time to transplant the dxf loading code of osg to vsg, should I directly add a dxf folder in the src directory of the vsgXchange repository like the ktx format?

[robertosfield]

Yes the natural place for a dedicated DXF loader would be vsgXchange/src/dxf.

The OSG DXF plugin is under the OSGPL with a relaxation of the LGPL, but it's not compatible with MIT so you can't just copy and adapt code and have vsgXchange remain MIT as I am aiming to do.

In terms of code software engineering has moved on since when the OSG DXF plugin was written so if I were to write a vsgXchange::DXF loader I'd review the OSG's DXF plugin to learn from it then write a clean room implementation specifically for the VSG and C++17's capabilities.

However, I would also first investigate Assimp to see if vsgXchange::assimp is handling the models it loads from DXF correctly or whether Assimp itself could be tweaked/improved to resolve the DXF issues. If this didn't look promising then I'd look to see if there are any license compatible 3rd party libraries that just load DXF in a really easy to use with all the features required.

Essentially I'd look for the easiest way to achieve the functionality required in a way that can easily be maintained in the coming decades (the OSG is more than 2 decades old :-)