Add preliminary support for loose edges and points

[nasser]

This patch implements the enhancement discussed in #376.

• It adds a "Loose Vertices" and a "Loose Edges" checkbox to the Geometry drop down of exporter UI
• When "Loose Vertices" is checked, the exporter now extracts vertices that are not associated with any edge into a glTF POINTS primitive
• When "Loose Edges" is checked, the exporter now extracts edges that are not associated with any polygon into a glTF LINES primitive
• The exporter is patched to support various primitive modes (as opposed to being hard-coded for triangles)

This is a preliminary patch and some more work can be done in the future. Some things that come to mind:

• No splitting occurs, which might be an issue with large LINES primitives as they are indexed
• POINTS primitives are still indexed, which is likely wasteful. Addressing this would require a bigger patch to the exporter that I wanted to avoid without further guidance on the issue
• Materials, colors, and UV coordinates are not exported. I am not sure how much of this information Blender even allows you to associate with loose geometry, but it could be nice to have if possible.

I am open to feedback and guidance on these and any other issues.

I've attached a test scene and three files exported by this patch:

• lines.glb is exported with "Loose Edges" checked
• points.glb is exported with "Loose Vertices" checked
• points-and-lines.glb is exported with both checked
• scene.blend is the source scene

[CLAassistant]

All committers have signed the CLA.

[janEntikan]

It would be nice if this was resolved and merged.

[nasser]

it was ready to go when i submitted it, but it didn't get merged at the time, not sure why. it will take some doing to resolve the conflicts as i am not actively working on blender stuff at the moment, but i will try and make time for it.

[donmccurdy]

I'd be glad to have this feature included as well, thanks for the PR. The file has changed a bit since this PR was opened, and #1023 will change it yet more. I'm not sure whether #1023 affects this PR or not.

[nasser]

Something I struggled with when I was writing this was how to develop one of the included addons while using stock blender and avoid getting conflicts. I think I ended up erasing the io_scene_gltf2 folder that came with my blender installation and symbolically linked it to my clone instead... feels clunky. is there a better development workflow you use?

[donmccurdy]

I'm using the steps in DEBUGGING.md. It seems like you do need to delete the original io_scene_gltf2 folder, but then I configure Blender's Scripts settings to point to the versioned glTF-Blender-IO/ directory in a more convenient location. This works well for me, but I'm also updating the addon folder much more frequently than I update Blender itself.

[mkvvltra]

Hey, tried using this branch with 'Compression' option enabled - was met with following error:

Traceback (most recent call last):
  File "/Users/___/Library/Application Support/Blender/2.82/scripts/addons/io_scene_gltf2/__init__.py", line 434, in execute
    return gltf2_blender_export.save(context, export_settings)
  File "/Users/___/Library/Application Support/Blender/2.82/scripts/addons/io_scene_gltf2/blender/exp/gltf2_blender_export.py", line 40, in save
    json, buffer = __export(export_settings)
  File "/Users/___/Library/Application Support/Blender/2.82/scripts/addons/io_scene_gltf2/blender/exp/gltf2_blender_export.py", line 54, in __export
    __gather_gltf(exporter, export_settings)
  File "/Users/___/Library/Application Support/Blender/2.82/scripts/addons/io_scene_gltf2/blender/exp/gltf2_blender_export.py", line 72, in __gather_gltf
    gltf2_io_draco_compression_extension.compress_scene_primitives(scenes, export_settings)
  File "/Users/___/Library/Application Support/Blender/2.82/scripts/addons/io_scene_gltf2/io/exp/gltf2_io_draco_compression_extension.py", line 65, in compress_scene_primitives
    dll.createCompressor.restype = c_void_p
  File "/Applications/Blender.app/Contents/Resources/2.82/python/lib/python3.7/ctypes/__init__.py", line 377, in __getattr__
    func = self.__getitem__(name)
  File "/Applications/Blender.app/Contents/Resources/2.82/python/lib/python3.7/ctypes/__init__.py", line 382, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: dlsym(0x6000002c1e00, createCompressor): symbol not found

location: <unknown location>:-1

It seems to occur even if 'Loose Vertices' and 'Loose Edges' are disabled.

[donmccurdy]

Note that the compression methods implemented in this addon do only support triangle meshes. But we should make sure that it safely ignores loose vertices and edges whether compression is enabled or not, yes.

[donmccurdy]

We'd be glad to support this feature, but for clarity (since it currently needs updates) I'll mark the PR as a draft. Please feel free to mark it as ready for review, or open another PR, whenever you like. :)

[nasser]

Will do. Sorry, life situation changed since I made the original PR and I'm trying to make time to update it!

[donmccurdy]

Completely understand, no worries! When you have the time let us know, or any other users interested in this feature are welcome to build on your work and open a new PR too. Thanks for getting this started. 🙂

[Snouf-ID]

Exporting points and lines would be very useful. I had to do an obj-wavefront to gltf converter in my code, which is annoying if you want to have anything other than simple primitives with no great material.
This great work is highly anticipated !

[dohkoxiaozu]

I'm looking forward to exporting lines, because if I can't export lines, I'll have to manually find the right place in the world to calculate the right dot matrix to draw a line (which is a disaster).

[scurest]

Here is an up-to-date branch with loose geometry support in case it helps anyone. Look for the "Loose Geometry" options under "Geometry" on the export screen. I have not tested it extensively.

[nasser]

Updated the patch to the changes that have happened in the meantime. I tracked my original implementation fairly closely, so I expect its not as idiomatic as it should be, specifically w.r.t #1023 which I haven't looked at. It works locally, and the CI tests pass, so that's something. Still a few things to do though:

• Look at Export: rewrite extract_primitives for simplicity/speed #1023 and make sure my implementation is in line with it
• Make sure the patch is safely ignored by compression as brought up by @mkvvltra

Once I get those taken care of I will start a review. Happy for any guidance/feedback as always.

@scurest I ended up updating my original code as that was the path of least resistance -- thanks though!

[scurest]

Think you should consider using my branch as a base instead. In addition to being in line with #1120 (which succeeded #1023), it fixes several bugs, uses the FBX-compatible option names discussed above, doesn't export indices for POINT primitives, and adds a test.

Pointing out some issues anyway. I'll only comment on edges, but some of this applies to points too.

[nasser]

@scurest thank you for the detailed review. I think you're right, I will take a look at your branch as the base instead next!

[scurest]

About Draco: I think it's only for mode=4? So this?

diff --git a/addons/io_scene_gltf2/io/exp/gltf2_io_draco_compression_extension.py b/addons/io_scene_gltf2/io/exp/gltf2_io_draco_compression_extension.py
index 2bb79aa0..6a661334 100644
--- a/addons/io_scene_gltf2/io/exp/gltf2_io_draco_compression_extension.py
+++ b/addons/io_scene_gltf2/io/exp/gltf2_io_draco_compression_extension.py
@@ -200,6 +200,10 @@ def __compress_primitive(primitive, dll, export_settings):
         'UnsignedInt': 4,
     }
 
+    # Only compress triangle mode
+    if primitive.mode not in [None, 4]:
+        return
+
     # Positions are the only attribute type required to be present.
     if 'POSITION' not in attributes:
         print_console('WARNING', 'Draco exporter: Primitive without positions encountered. Skipping.')

Maybe @UX3D-eckerlein could confirm? (This PR will add primitives with mode=0 and mode=1.)

[donmccurdy]

That's correct, the KHR_draco_mesh_compression extension only supports triangles.

[nasser]

backed up and used @scurest's changes. they work great and meet all my own use cases. all i did was tweak a few internal naming conventions. this is more or less ready to go but a few things come to mind. let me know if these are out of scope/make more sense in a separate PR.

1. this is a UI quibble, but currently the "Loose Geometry" label is clipped by default.

alternatives that come to mind are

Loose [ ] Edges
      [ ] Points

or

[ ] Loose Edges
[ ] Loose Points

any preferences? other ideas? not an issue?

2. currently all loose geometry is exported without a material meaning, in threejs at least, they get a solid white material. it would be great if there was some way to affect this from the blender side, though if i understand correctly materials can only be assigned to faces, not edges or points. i am not sure what the best way to "pick" a material for these primitives is. simply using the material at index zero of the associated mesh covers a lot of the use cases i have in mind, though.

it means loose geometry gets a reasonable default, and if it's not what the user wanted they can break the loose geometry out into its own mesh and assign a different material. admittedly, the only thing that gets communicated is color, but it makes a difference in some cases. the image above is from a mock-up i have not pushed out, rendered in three.js (intentionally downsampled to highlight the effect).

does this make sense? maybe behind another export option? is there a better way to deal with materials on loose geometry?

[scurest]

1. Up to the maintainers but I'd do the second one

   [ ] Loose Edges
   [ ] Loose Points
   

   because of consistency with the FBX exporter.

   

2. Using the 0th material slot seems like a good idea, +1 from me. It matches how Blender uses the 0th slot when it needs a default (eg for the faces of a Surface, or a newly created Mesh). And like you said, otherwise there's no way to set a material at all.

edit: maybe we could put (Loose geometry uses the material from the first material slot.) or something in the tooltip.

[donmccurdy]

^Agreed on @scurest's suggested solutions to (1) and (2) above.

[expenses]

Looking forwards to this! ❤️

[scurest]

I've updated my branch with everything discussed so far.

[nasser]

@scurest this looks great to me, thanks for taking care of this!

[donmccurdy]

This is an awesome PR, thanks for the updates @nasser and @scurest.

[donmccurdy]

Excited to have this functionality, and glad the implementation ended up being pretty concise.

@emackey any concerns with the material handling?

Has someone tested this with skinned points or lines? I don't think three.js even supports that, I'm not sure about Babylon.js or other engines...

If there are no concerns or other issues, I'll merge this in a few days.

[scurest]

Has someone tested this with skinned points or lines?

Yes, it works reimporting back into Blender and in Babylon, but not in Three.

[emackey]

Some minor wording suggestions for the export options. Are these OK?

[emackey]

@emackey any concerns with the material handling?

We actually had a concern about how materials are [barely] specified for points & lines crop up in the Khronos PBR TSG just this week. But that didn't have an easy answer, so it shouldn't hold up this PR.

I have no concerns about the mechanics of using the first material slot, so this should be good to go.

[scurest]

So what happened?

[donmccurdy]

@scurest I think @emackey is saying that the material handling here is fine and we should proceed.

We are down to just unresolved comments at this point.

[donmccurdy]

Thanks @nasser and @scurest for implementing and testing this, a really helpful addition. 🎊

[nasser]

it was all @scurest in the end 🙏 very happy to see this merged and i look forward to using this feature in blender!