vsgXchange model requirements

[role...@gmail.com]

Hi All,

I'm wondering what the requirements are for models to be loaded via vsgXchange/assimp? I've got some DXF files from different sources that all get imported as a silhouette. Do I need to add anything to the scene graph above the imported asset? Other files came in without problem (teapot.vsgt, DamagedHelmet.glb).

You can repeat using the attached dxf file by:

vsgviewer wuson.dxf.

Thanks,

Roland

[Robert Osfield]

Hi Roland,

I tried the model and get the same result as you.  I tried it with osgviewer and didn't see much improvement. Running

    vsgconv wuson.dxf test.vsgt

Then looking at the resulting test.vsgt shows that the normal array is all 0,0,0, so not surprising it's black.

It could be that the original model just has normals that are 0,0,0, or perhaps Assimp isn't loading them correctly.  As far as I'm aware the vsgXchange assimp code just copies the data that Assimp loads.

Have you tried this model with any other tools?

Robert.

 

[Roland Hill]

Hi Robert,

The model looks fine in g3dviewer from the Ubuntu repos.

The model actually came from the Assimp repo. If you have Assimp cloned then it's in assimp/test/models/DXF/. I tried the PinkEgg dxf file from there as well with the same result. I assumed that all those models would work.

I'm under the impression that dxf doesn't support face normals - I could be wrong. If so, they would need to be generated by the importer I guess. 

Regards,

Roland

--
You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vsg-users/CAFN7Y%2BVsrnEp0Yw8COsaoHQLM_KsCFd70%2B4CnirDBxg8MyU-_g%40mail.gmail.com.

[Robert Osfield]

Hi Roland,

On Fri, 26 Nov 2021 at 08:31, Roland Hill <role...@gmail.com> wrote:

The model actually came from the Assimp repo. If you have Assimp cloned then it's in assimp/test/models/DXF/. I tried the PinkEgg dxf file from there as well with the same result. I assumed that all those models would work.

I'm under the impression that dxf doesn't support face normals - I could be wrong. If so, they would need to be generated by the importer I guess.

It's a long while since I worked with DXF so don't recall the situation w.r.t normals.  It could be that the normals will have to be generated manually.  I don't know if Assimp can do this for us.

Robert.

 

 

[Roland Hill]

... and there we have it!

The flag aiProcess_GenNormals in the code from vsgXchange generates face normals if they don't already exist. Apparently it expands the number of vertices though (understandably). There is another flag to set a crease angle so that some angles are smooth and some sharp. Not sure that it's possible to use this as a generic setting as users will have different expectations. What are your thoughts??

Regards,

Roland

assimp::Implementation::Implementation() :
    _importFlags{aiProcess_Triangulate | aiProcess_FlipUVs | aiProcess_OptimizeMeshes | aiProcess_SortByPType | aiProcess_ImproveCacheLocality | aiProcess_GenUVCoords | aiProcess_GenNormals}
{
    createDefaultPipelineAndState();
}

--

You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vsg-users/CAFN7Y%2BV1sVEpFzyWUXcVGSTO-xsK4YsYYVsC8s-1GqrJhpGgvg%40mail.gmail.com.

[Roland Hill]

Hi Robert,

I'll send you a PR for VSG and another PR for vsgXchange - they work together.

I've added some options to vsg::options to control creating smooth or sharp normal creation if normals aren't already present. You can also set the smoothing crease angle. Sharp normal generation (if required) is default as there doesn't seem to be much point in importing those black shapes.

Smooth Normals - crease angle 80 deg.

Sharp normals

Regards,

Roland

On Fri, 26 Nov 2021 at 19:41, Robert Osfield <robert....@gmail.com> wrote:

--

You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vsg-users/CAFN7Y%2BV1sVEpFzyWUXcVGSTO-xsK4YsYYVsC8s-1GqrJhpGgvg%40mail.gmail.com.

[Robert Osfield]

Hi Roland,

I was about to suggest using vsg::Options to control whether to enable normals generation, crease angles etc. 

We can either add the members directly to vsg::Options, or leverage the VSG's meta value/object support for passing in variables i.e.

   options->setValue("crease angle", 10.0);

   options->setValue("generate_normals", true);

We'd need to document what the supported options are.  This is something that the ReaderWriter::Features could be extended for.

Coming up with a consistent scheme for this is something I'd like to do for other loaders beyond the Assimp one so this could be a good test.

[Roland Hill]

Thanks, Robert. I had in the back of my mind that you could set value/object pairs in vsg::options. I went with that method in the end.

PR has been sent. When I forked the latest version it couldn't find my Assimp any more. I changed find_package from EXACT to QUIET and it worked again. Version 5.0.1 has been working OK for me.

The disadvantage of the value/object method is that you can't set generating sharp normals to default in the options. We could add it to the standard _importFlags instead though.

You can use the new method like this.

auto options = vsg::Options::create();

// add vsgXchange's support for reading and writing 3rd party file formats

options->add(vsgXchange::all::create());

// add option to get Assimp to generate sharp or smooth normals if required

options->setValue("generate_sharp_normals", true);

// or

// options->setValue("generate_smooth_normals", true);

// options->setValue("crease_angle", 80);

Regards,

Roland

--
You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vsg-users/CAFN7Y%2BX1droX8FuQ1w59doGZES1NCVH10WmF2ow16Dm6iEZhXw%40mail.gmail.com.

[Robert Osfield]

Hi Roland,

On Fri, 26 Nov 2021 at 12:19, Roland Hill <role...@gmail.com> wrote:

Thanks, Robert. I had in the back of my mind that you could set value/object pairs in vsg::options. I went with that method in the end.

Thanks, PR now merged.

I've been reflecting on the ReaderWriter::Features reflection and defaults issue and now wonder if we have leverage the meta object scheme itself to help out.

One possibility would be to have assign defaults to the ReaderWriter as meta values, the actual value used would then be take from either the Options object if it's assigned or the ReaderWriter.  You can then query what the variable names, types and default values are just be getting the ReaderWriter's Auxilary object.  Perhaps some convenience methods could help collect this information for us.

  auto assimp_loader = vsgXciange::assump::create(); 

  assimp_loader->setValue("generate_sharp_normals", true); // set the default (likely just call this in the constructor

It's end day here so I'll need to return to this on Monday.

Cheers,

Robert.

 

[Robert Osfield]

HI Roland et. al,

Despite a power cut through most of today I was able to get some coding done on my laptop -"all praise the wonders of lithium ion batteries" :-)

To help with support for using vsg::Options::setValue(..), getValue(..) within the vsg::ReaderWriters I have added a vsg::value<>(...) template convenience function so we can easily get a default or value specified in one or more objects, and a means of specifying the available options and their type via a new vsg::ReaderWriter::Features:: std::map<std::string, std::string> optionNameTypeMap; Changes to the VSG are checked into master:

    https://github.com/vsg-dev/VulkanSceneGraph/commit/bccafcd1434f9957e342d9eb3a0133ef01d13d78

I've update vsgXchange so that assimp ReaderWriter now have the strings used specified in the public interface, and then in the implementation these are used along with the vsg::value<>() function above, and the Features is also filled out. The commit that adds this is:

    https://github.com/vsg-dev/vsgXchange/commit/9a67c5d880e9860cbdcad737a0002bb26b28b7fc

Finally I have added reporting of the ReaderWriter::Features::optionNameTypeMap via vsgconv --features:

    https://github.com/vsg-dev/vsgXchange/commit/4098eb811d008da0f1258cd8f13aeddae06461ca

The vsgxonv -features output now has an addition vsg::Options::Value entry::

....

       zae             read(vsg::Path, ..) read(std::istream, ..) read(uint8_t* ptr, size_t size, ..)  
       zgl             read(vsg::Path, ..) read(std::istream, ..) read(uint8_t* ptr, size_t size, ..)  

       vsg::Options::Value      type
       -------------------      ----
       crease_angle             float
       generate_sharp_normals   bool
       generate_smooth_normals  bool

--

It may make sense to add a description field as well, though as this is all still in dev I'm happy to wait till we get used to using this new scheme.

What I'd like to do is provide a scheme for parsing the command line parameters and automatically setting the vsg::Options::setValue() as per the above Features::optionNameTypeMap  so we could do something like:

   vsgviewer wuson.dxf --generate_sharp_normals true

The ReaderWriter::OSG also use the vsg::Options::setValue(..) that is used in combination with a osg2vsg::BuildOptions structure that is serialized.  I'm thinking that this could be standardized more so that it works a bit more like how vsg::RederWriter::assimp now works.  Adding the CommandLine parsing support would be one way of doing this, at least that's what I'm think should be possible with a bit more work.

Cheers,

Robert.

[Robert Osfield]

I have further refined the command line parsing code in the assimp  ReaderWriter so it uses a vsg::CommandLine method:

        template<typename T>
        bool readAndAssign(const std::string& match, Options* options)

The code to parse the command line arguments now looks like:

bool assimp::readOptions(vsg::Options& options, vsg::CommandLine& arguments) const

{
    bool result = arguments.readAndAssign<void>(assimp::generate_smooth_normals, &options);
    result = arguments.readAndAssign<void>(assimp::generate_sharp_normals, &options) | result;
    result = arguments.readAndAssign<float>(assimp::crease_angle, &options) | result;
    return result;
}

Note the type passed in for the first two readAndAssign() calls above use void type, which tells the readAndAsssign method just to look for a --match without a parameter this means we can now simple write on the command line:

   vsgviewer wuson.dxf --generate_sharp_normals

The readAnAssign method also adds the "--" prefix automatically, so there is no need to add this yourself, instead you just pass in the "string" that you want to match and then assign the vsg::Options.  For the case of a void type match a options->setValue(match, true); is used.

I was originally thinking about automating more of the code for reading and reporting the features, but now feel that would add more complexity and make the code less easy to follow, so while what we now have is a bit verbose it's not a huge amount of code, especially now we have the CommandLine::readAndAssign(..) convenience method,

[Robert Osfield]

I have updated the OSG ReaderWriter to use the new vsg::Options/vsg::CommandLine/vsg::ReaderWriter::Features, so now you can query what the options are, for the OSG it's now:

       vsg::Options::Value  type
       -------------------  ----

       original_converter   bool
       read_build_options   string
       write_build_options  string

Which can be used on the command line in a couple of different ways.  First up straight forward conversion to .vsgt:

     vsgconv dumptruck.osgt output.vsgt

If you want to use the original osg2vsg conversion code written back in 2019 you can add  --original_converter to the commandline, or use options->setValue("original_converter", true) in C++:

     vsgconv dumptruck.osgt output.vsgt --original_converter

The original converter is actually a bit faster than the new conversion code as it restructures the scene graph far more for efficiency but looses closer 1:1 OSG/VSG feature mapping that is required for things like PagedLOD.  Once the VSG is more mature I'd like to revisit the converter

The osg2vsg code also uses a BuildOptions class to control the various conversion options, this is serialized using the standard VSG serialization so you can read/write this to a .vsgt and then edit the options.  To find out what the options are you can run:

 vsgconv dumptruck.osgt output.vsgt --write_build_options build_options.vsgt

The build_options.vsgt file looks like:

$ more build_options.vsgt
#vsga 0.2.0
Root id=1 osg2vsg::BuildOptions
{
 insertCullGroups 1
 insertCullNodes 1
 useBindDescriptorSet 1
 billboardTransform 0
 geometryTarget 1
 supportedGeometryAttributes 4095
 supportedShaderModeMask 1023
 overrideGeomAttributes 0
 overrideShaderModeMask 0
 useDepthSorted 1
 vertexShaderPath ""
 fragmentShaderPath ""
 extension "vsgb"
}

You can edit this and then tell the osg2vsg converter to use:

   vsgconv dumptruck.osgt output.vsgt --read_build_options build_options.vsgt 

Potentially I could add more Options::setValue(..) settings to map the BuildOptions structure, but for now will just leave it as is.

Robert.