You didn’t understand, this pip is part of the blender, it has its own internal python.
Ah, I see. I’ve never used that one, I don’t think.
(I’m not even sure that my old version of Blender has it.)
The plugin is only for 2.8 +
Ah, right, I’d forgotten about that. Well, fair enough, then!
At least for my purposes, I only see two major issues with glTF support as it stands now, which is that our flatten_*() methods remove bump mapping support in PBR and are limited to a small vert count (the latter of which is also true for .egg).
With my snippet to do collision modeling for Bullet, and Epihaius’ snippet to do collision modeling for the built-in collision system, I suppose I see direct tag support without blend2bam as an enhancement rather than as something totally lacking from “our” glTF support.
As of the current day .gltf can be used to skeletal animations too. I disagree that our glTF support is not production ready.
The thing here is, that’s not great for new devs, I feel.
I’m not ready to expect a new dev to dig up a forum post, examine relatively-low-level code, and then use that to produce collision geometry. Not to mention that neither snippet really speaks to the question of how collision geometry is identified within a model-file, when both visible and collision meshes are present in a single file.
So it’s awkward for experienced devs, and problematic for new ones.
And on top of these things, it’s been noted that blend2bam sets up various export-values that aren’t obvious; that, too, makes exporting to glTF without blend2bam potentially problematic, especially for newcomers.
1 Like
I certainly agree on this. One remediation might be to create some modern documentation for these more manual methods, mirroring the Panda3D manual, or perhaps extending the manual officially to describe a “full” glTF workflow with Panda3D and Blender.
1 Like
That would likely help, I do think.
I wouldn’t call it a solution, as such, but it might at least ameliorate the issue!