When using Blender’s glTF exporter (i.e. not blend2bam), is there a way to export collision geometry, specifically of the sort used by the built-in collision system?
Further, is there a way to specify the presence of a non-polygonal collision-shape–i.e. a CollisionBox, or CollisionSphere, etc.?
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.
Ah, I see, and thank you.
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!)
Ah, that’s good to know–thank you! 
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.
Ah, interesting, and thank you.
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.
Tag practice is a bad approach.
I disagree.
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.
Because this is not always the case. And visual geometry is not always the same with the data for calculations. They are usually simplified.
And I don’t think that the tag will do a magic job for a beginner in this matter. This will only make things worse for him.
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.
In fact, this has already been written, if I’m not mistaken, there are solutions in the code snippets. Like Epihaius published, I can be wrong.
It is not necessary for a beginner to write this, I assume that by default the panda should have a script for creating a collision from a geometry file. This would be correct and consistent.
As I said above, it is possible to do this with the existing EGG API or create an official script for general use, there are many options.
This will get rid of format restrictions. For example, someone will want to use it with .x or .obj is a flexible approach.
In any case, my exporter is ready for exporting collisions, and it can be used on top of these formats. So it actually exports to .bam node with the necessary data.
ADD:
However, this is also bad, since it binds the user to the blender editor. While he prefers to work in 3D max.
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.
My exporter requires tests, so it relies on a non-standard approach to installation.
https://discourse.panda3d.org/t/development-of-the-exporter
It works well in windows. On linux systems, an instruction is required. However, at the moment I am implementing animation export. I need linux tests, I think I can then put the system for tests.
Ah, interesting!
What testing do you need done?
If it’s fairly quick and straightforward stuff (“export these models, then load them in Panda and see whether they work” sort of thing) then I might run some tests for you, should you want it. 
I meant that it must pass the testing stage before it is presented to users.
Tests are required in order to understand the installation procedure in Linux systems. As far as I know there is no way to use pip without pain.
Perhaps this is no longer relevant, but in any case, I would like to know what Linux system users are facing.
Of course, I expect to receive comments and suggestions for improving the interfaces and some functions.
For example, how convenient is it for you to separate the collision nodes by material types, and so on.
The basic ones are probably mentioned here.
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.
Aaah, fair enough, then! And indeed, that does seem wise!
This sounds like my experience of GitHub! XD;
If it helps, I’m using Ubuntu 18.04.5 LTS.
You know, I don’t think that I’ve ever settled on a way of doing this that I found entirely satisfactory.
Ah, I see–thank you for that. It’s promising that the extensions exist, but a pity that there isn’t further support for them! If I may ask, is there any work being done on the matter?
It’s not so much about the operating system, but about the performance of pip, which comes with a blender on Unix systems. There is information that it works only after a number of manipulations.
Ah, I see.
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.)