As far as I know, the gltf exporter in blender itself isn’t able to export the physics/collision settings.
The scripts used in blend2bam which also use gltf by default are adding those features as extensions to the exported gltf file. So even if you’d be able to export them somehow, the loader implemented in Panda3D would still need to know how to convert those extensions to their collision counterparts in panda3d if you want to have them loaded automatically. I haven’t worked with direct gltf loading in panda3d much, so I can’t really tell you more about how it handles extensions at all.
Regarding your other question, in blenders Physics Properties of a node, if you enable Rigid Body, you can set the shape of the collision solid in the Collisions section.
The lack of these things (outside of blend2bam) is a bit off-putting, I’ll confess.
(As to how it might be done, I might imagine something similar to the egg approach: a “Collide” tag that Panda’s glTF importer recognises and takes as a cue to generate collision-geometry instead of visible geometry. How feasible that is I don’t know, however!)
There are already discussions (see issue below) to get this feature directly in gltf but it probably takes some time until this gets integrated into the core definition rather than the extensions @Moguri has already proposed to Khronos which is also linked from the issue below.
Although I do wonder how long it might take to gain such official support. I wonder whether–at least in the meantime–it might not be better to implement support in Panda via tags. (Especially as such a feature in Panda wouldn’t necessarily conflict with the official feature, or at least so I imagine.)
In fact, this makes no sense, the panda loader (EGG) converts polygons into triangles, even if the polygon was coplanar. With such success, you can write your own loader and which will create collisions from geom data.
In general, tags are enormously useful, I’ve found; I see no reason to disregard them.
As to converting polygons to triangles, I’m not really talking about that; I’m talking about loading a model that specifies collision geometry and having the in-engine result include collision geometry.
As to writing one’s own loader… sure, that can be done. But it’s also exactly the sort of task that one might turn to an engine for. I’d rather spend time making a game than making a loader.
Further, it’s something that’s likely to be commonly used, I would imagine, and thus something that it makes sense to me to have included as part of the engine’s functionality.
And finally, collision geometry is something that a dev may well want from near their first steps in game development–is it really reasonable to ask a new dev, just starting out, to write a procedural geometry converter?
Basically, you’re offering a way to mix everything together and then decide what to do with it.
I suggest explicitly defining the data types. visualization, collision, physics. Accordingly, they should be prepared separately from each other and exported separately, too. I would give them my file extensions to logically sort them out.
I don’t quite understand why to make a geometry for a collision and mark it with an additional tag.
I think it will not be difficult to make the EGG API public for manual control, also blend2bam, although I have no idea how it does it.
Separating everything out just seems superfluous to me: If a level has visual geometry and collision geometry, why separate them? Especially as they’re spatially linked: the collision geometry shadows the visible, making it seem “solid”.
In all fairness, this may simply be a difference of approaches: I doubt that your way is “wrong”, and I don’t think that my way is “wrong”, either.
As to the tag, it’s simply so that Panda knows to convert the geometry in question into collision geometry. Or rather, a suggestion for one way that it might be done, given that I gather that the glTF format doesn’t have a built-in way to specify that a piece of geometry is collision geometry.
I’m not saying that the geometry is exactly the same.
I’m saying that if you have a visual pillar at a given location, you likely have a collision pillar there, too. And yes, the collision pillar is simpler–but that doesn’t mean that it can’t be in the same file.
And that’s fine: just place objects within the model-file as desired.
How would having a single tag, maybe with some options, be worse than asking a beginner to write a procedural collision-geometry generator? Especially if they’re making their own models, in which case they’d presumably have to define which models are collision-models anyway.
Sure, but then they have to follow and integrate unfamiliar code dealing with relatively-low-level operations, which is again not likely to be new-dev-friendly.
And that’s if they first realise that there might be something to be found, and then actually find it on the forurm.
Much easier to just have this be handled behind the scenes by the editor.
I imagine that Panda has something like this–it does, after all, generate collision geometry based on egg-syntax tags. However, there doesn’t seem to be a connection between anything in the glTF format and whatever code handles the conversion.
It is–but the current recommendation, which new devs might be following, is to use glTF. And further, it looks like the egg-format is being left behind.
And if one does want to use the egg-format, then the current Blender exporter for egg, YABEE, relies on an out-of-date version of Blender; devs coming in with newer versions will presumably find that it doesn’t work.
This is more or less what I’d like: code in the engine that, on loading a glTF-model, responds to a relevant tag to produce collision geometry much as is already done with egg-models.
I would still want some sort of internal tag, so that one file can contain both visible and collision geometry.
Is your exporter available somewhere? And how does its feature-list compare with baseline YABEE’s?
If it’s a solid exporter then I might want to mention it in my “exporting from Blender quick-reference” thread, and perhaps even recommend it in place of glTF exportation!
I mean, some sort of exporter is called for in each case, I would say.
panda3d-gltf supports both the BLENDER_physics and PANDA3D_physics_collision_shapes extensions, but blend2bam is the only exporter I know of that also implements these extensions. It does this by injecting the extension into the output of Blender’s builtin glTF exporter.
I don’t know where I got my version, but I’ve been using pip3 to load Panda for a while now, and it has seemed to work consistently and reasonably smoothly for me, at least.
(Funnily enough I did just yesterday or the day before, I think that it was, write a shell-script to streamline my use of it with Panda–but that, I think, is more because I tended to not remember the parameters involved.)