Invisible and intangible collision geometry handling

[fireclawthefox]

Description

Add and enhance support for invisible and intangible collision geometry in the blend2bam exporter. As there already is support for intangible objects, the workflow for invisible but solid geometry should be usable in addition to the existing way to keep a consistent and easy to understand usage. The resulting workflow should be scalable and easily adaptable for existing models to work from only a few to hundreds or more objects in a scene.

Use Case

Easily add invisible solid collision objects like walls for level borders and enhanced usability for adding lots of intangible objects for things like trigger fields.

Possible implementation solution

Add collision geometry to dedicated collections in the tree. Each object if applicable in those collections should be converted to a invisible or intangible collision object.

Optional

Make collection names containing the objects configurable either by passing the dedicated names for invisible and intangible collections (e.g. collisions, triggers), a list of collections (e.g. collisions_a, collisions_b and triggers_a, triggersb) or just a prefix (e.g. col and trig_) to find the correct objects.

Checklist

• [ ] Support invisible geometry
• [ ] Add support for intangible objects in addition to existing solution
• [ ] Easy scalability
• [ ] Don't break base features (linking, instancing, etc)
• [ ] Ensure this feature works for linked/instanced objects too
• [ ] Provide a test model containing both types of collision objects and possibly linked and instanced objects
• [ ] Update documentation

[Clockwork-Muse]

.... I mean, blender has a specific render flag for all objects... probably not noticeably exported into gltf, though.

[Clockwork-Muse]

Hm. Currently passive physics objects are exported as intangible, which is surprising coming from the blender side of things (where passive objects are very much tangible, but otherwise unaffected by physics calculations).

[Moguri]

@Clockwork-Muse Do you have a recommendation for which settings should be used instead to determine intangible objects? Unfortunately, Blender's rigid body properties do not really have such a concept.

[Clockwork-Muse]

Hrm. Custom property on the object, maybe:

Property name isn't completely important.

[fireclawthefox]

Using custom properties may be a way to go but if it's supported by blend2bam and the bam format (can't remember if that was something only supported by the egg format), I'd recommend changing the intangible to collide and pass the various flags that a collision object could have as defined here: https://docs.panda3d.org/1.10/python/tools/model-export/egg-syntax?highlight=intangible#collide

The only thing that I don't like about using custom properties is, that there is no easy way to copy them to other objects or even multiple objects at once as other properties can from the context menu, which would come in handy if you're working with hundreds of objects of for example a legacy blend scene that needs to be updated or if you forgot to add that parameter and already copied the objects multiple times.

[fireclawthefox]

Just thought about it some more and, if we go with the custom property, would it work if the custom property was set on an empty node which has a lot of objects parented to it? Would it propagate down or would it simply be ignored for the parented objects?

[Moguri]

It looks like this Godot exporter makes use of the object's Draw Type: https://docs.godotengine.org/en/stable/getting_started/workflow/assets/escn_exporter/physics.html

I wonder if we do something like if any of the following is met, the object will be collision shape only:

• Draw Type set to Wire
• Some sort of custom property
• Presence in a special collection

Thoughts on this?

As for propagation, I am unsure on this, but it sounds useful. We also might need to do something like that to handle compound collision shapes.

[rdb]

• Draw Type set to Wire

In principle I like doing what others do, but what if we want to add wireframe mode support? It seems like a massive hack.

[Moguri]

Ah, fair enough on maybe wanting to support wireframe some day. Anyone happen to know of other examples we can look at? Most engines seems to require setting up collision shapes in-engine instead of exporting them from something like Blender.

[Clockwork-Muse]

Unreal Engine can use specially named meshes, although support for all imports is spotty, and I think Source did/does as well.

[fireclawthefox]

• Draw Type set to Wire

I'm with what @rdb said and don't think this is the best we could do.

• Some sort of custom property

This has been stated before and I'm still fine with that but only if this can be propagated down to child objects somehow. Otherwise it would be a lot of work to redo old models which could have hundreds or thousands of objects that require this property and blender as far as I know still has no support for editing properties of multiple selected objects. Maybe the propagation can be controlled with an extra custom bool property something similar to what we have in the egg syntax with the "descend" tag. If it's active, child objects will become collision objects too.

• Presence in a special collection

This is what I initially proposed and I still think it would work just fine. Not sure if there are any drawbacks to this though but for now I haven't had any issues with collections in blender and exporting.

[fireclawthefox]

@Moguri are there any news for this? It's quite some time since the last post and since there hasn't been brought up any new ideas I guess it may be time to make a decision for how to implement it. If there are still things unclear or not ready to make a decision, I'd like to continue the discussion.