Why is a 3mf file shown flat while a stl file is shown shaded?

[dov]

Hello. I'm in the process of learning VulkanSceneGraph and in the process I realized that if I open a STL file with myfirstvsgapplication (or with vsgviewer) it is shown shaded, whereas if I open a 3mf file (a file format often used for 3D printing) it is shown flat.

Here is shading of an stl file:

and here is the shading of a 3mf file:

To do the comparison better, I created a cube (in FreeCAD) and exported the cube both as an stl file and as a 3mf file and then converted both files to the vsgt file format by the command:

vsgconv box.stl box-stl.vsgt
vsgconv box.3mf box-3mf.vsgt                     

I'm attaching the resulting vsgt files to this post.

Here are are my questions:

1. Why are the vsgt files so different? Both topologically and in the contents of the shaders? Is this a bug (or a feature?) of assimp?
2. What nodes are causing the different shading?
3. How would I modify myfirstvsgapplication to override the shaders and the light (and possibly materials) sources from a loaded scene in order to "only display geometry"? Is there any example doing such overwriting?

Thanks in advance!

(vsgt files are renamed since the forum does not allow uploading vsgt files.)

box-stl.vsgt.txt
box-3mf.vsgt.txt

[robertosfield]

It would have been more useful to post the original stl and 3mf files as then we'd be able to test them out directly. My guess is that the vsgXchange::assimp loader has assimp loading the models, the stl by default loading with normals while the 3mf is loaded without normals.

Assimp/vsgXchange has support for computing normals for you, the list of options available can be list by running:

vsgconv --features vsgXchange::assimp

After all the formats support are listed you'll see the list of options which looks like:

    vsg::Options::Value      type
    -------------------      ----
    crease_angle             float
    culling                  bool
    discard_empty_nodes      bool
    external_texture_format  vsgXchange::TextureFormat
    external_textures        bool
    generate_sharp_normals   bool
    generate_smooth_normals  bool
    print_assimp             int
    sRGBTextures             bool
    two_sided                bool

On the command line examples like vsgconv and vsgviewer allow you to see the options via the form --name , so for normals something like:

vsgviewer --generate_sharp_normals box.3mf
vsgconv --generate_sharp_normals box.3mf box.vsgt

You can also assign these options progamatically via the vsg::Optiions i.e.

auto options = vsg::Options::create();
options.... // normal Options set up as per vsgviewer and other examples
options->setValue("generate_sharp_normals", true);

auto model = vsg::read_cast<vsg::Node>("box.3mf", options);

I am not familiar with 3mf but perhaps this has the option for export with or without vertex normals.

[dov]

Thanks @robertosfield ! I'll investigate your answer in more depth. Meanwhile for completeness, I am attaching the two input files:

(Compressed with gzip as stl and 3mf are not valid formats on this forum)

box.stl.gz
box.3mf.gz

[dov]

Ok, I tested it, and the normals option does not seem to be the problem.

Here is the result of vsgviewer --generate_sharp_normals box.3mf:

Obviously for a format like 3mf that is used primarily for physical production, there is no need for normal, and are not recorded in the file. So a viewer need to determine these on its own either by flat (is this the same as sharp?) normals, or interpolated normals.

[vsg-dev]

That's a weird results for sure. I have just run the box.stl and box.3mf model on my system and get the same odd result with the 3mf model as you do when I used --generate_smooth_normals and --generate_sharp_normals.

We use assimp functions to compute the normals for us so it looks to me that it could be a assimp bug. I have use normal computation before with success, this is the first model I've seen fail in this way and don't have any ideal what might be the problem. I have enough work on my plate to not go chasing bugs in assimp so will defer to others if they want to dive in there.