Exporters: What to Recommend?

So, I would like to start a conversation regarding the asset-pipeline from Blender, and in particular regarding what pipeline to recommend to new users.


(And I may have missed some. I’ve also excluded PRPEE for the moment.)

From what I’ve gathered, the current recommendation is to use “blend2bam”.

However, as I understand it blend2bam exports the entire scene, rather than nominated objects–something that runs somewhat counter to any thoughts of organising multiple (presumably related) objects into single Blender-files. (e.g. Having all the table models in one file, and all the chests in another, etc.)

Furthermore, I’ve recently been seeing some reports of people struggling a little with it. This might in part be due to its command-line nature–but I also gather that it may be lacking somewhat in functionality as of yet. (See for example a recent thread in which someone was struggling to export an animated model that had included multiple meshes.)

Of course, the recommendation of old was YABEE.

And indeed, it remains, I think, a stable and mature exporter.

However, it’s also now somewhat outdated: it doesn’t support newer versions of Blender, and doesn’t support certain more-recent features, like node-based materials, I believe.


I gather that newer versions of Blender can export, and Panda can import, glTF files.

However, I’m not sufficiently familiar with the feature-set provided by this pipeline to be able to compare it to the other options. (At the least I’m told that it does support tags, if I recall correctly.)


So, the question then is this: What do we recommend to new users? The “blend2bam” exporter seems to be as-yet not mature, and has the disadvantage of being a command-line tool; YABEE is mature and convenient, but is shackled to older versions of Blender; glTF… I simply don’t know enough about to comment on.


1 Like

It is possible to use an entirely .gltf based way to export only the .blend parts that you wish, so you could have a hundred tables in Blender and only export the ones you want.

You can even do skeletal animations with .gltf files, though I’m not sure what the feature extent of this method is. I was doing skeletal animations in Panda before this support arrived so it may just be a bit of code inertia on my part to favor the separate .bam file method (though, I gather this is the recommended way, despite .gltf capabilities).

^ 100% .gltf as seen in gltf-viewer

As far as I can tell, the way of accessing and playing animations from single .gltf files exported directly from Blender is not currently documented in the manual, which is why I have strayed from recommending it.

This fails under any conditions I try and I’m not sure why:

        model_file = panda3d.core.Filename.from_os_specific(os.path.abspath('models/npc_1_death_anim.gltf'))
        model = base.loader.load_model(model_file, noCache=True)
        model_root = model.node()
        if model.find('**/+Character'):
            print("'Character' found.")
            death_anim = panda3d.core.AnimControlCollection()
            panda3d.core.autoBind(model_root, death_anim, ~0)
            # death_anim.loop('ArmatureAction', True, 0.0, 120.0)


'Character' found.

The model shows up in the game environment but doesn’t move. pose_all() and related calls also fail. I’ve tried it with a few different armature models.

Hmm… That is encouraging–but I would like to learn how feature-complete it is.

Can one export multi-mesh armature-animated objects in the glTF pipeline?

Hmm… I’m not familiar with that way of loading an animated model; I’m used to using Actor, and to just passing the animations into Actor’s constructor.

If this were an Actor, I would guess that the problem lay in the fact that it doesn’t keep a reference to said Actor–that being one of the known caveats of the Actor system.

Yes, at least for the simple case that I’ve tried with gltf-viewer.

I also continue to use the Actor system for all production work at this point in time.

I presume that it animates as expected?

If so, then that’s good, and a point in favour of recommending glTF, I would say!

Yes, you can verify this by running the .gltf provided below in a terminal with:

gltf-viewer ‘path_to_gltf_file.gltf’

double_mesh_arm_gltf_test.zip (102.5 KB)

Excellent! It does indeed seem to work as expected! :slight_smile:

(For those like me who might want to double-check that it works in a standard environment, I actually verified it by loading the model in a short test-program and running its animation.)

Here’s what my .gltf armature animation code looks like in a game environment:

        from direct.actor.Actor import Actor
        box_actor = Actor('models/two_color_cubes_arm_test.gltf')
        box_actor.set_pos(-147.988, 353.588, 288.784)
        # print(box_actor.get_num_frames('ArmatureAction'))
        b_anim_ctrl = box_actor.get_anim_control('ArmatureAction')
        def play():
            print('Beginning box spin loop!')
        self.accept('u', play)

In my case–and excluding some framework stuff and accumulated code, this being a general “testing/bug-hunting” program that I repurpose a fair bit–I loaded it like so:

from direct.actor.Actor import Actor        

# ...

        self.model = Actor("double_mesh_arm_gltf_test/two_color_cubes_arm_test.gltf")

# ...

Currently I am using glTF: my experience has been positive so far, so here is another recommendation for glTF. It is really easy to export glTF files from Blender’s GUI or using Blender’s bpy.ops.export_scene.gltf, and you can use the glTF files using panda3d-gltf or you can pre-convert them using gltf2bam. Since these steps are easy and the question considers new users, this may be the basis for a proper pipeline.

1 Like

Again, that is encouraging! Thank you for the input–it’s appreciated! :slight_smile:

For the record, blend2bam uses the Blender glTF exporter in conjunction with panda3d-gltf under the hood. The main difference is that blend2bam will configure the glTF exporter with the correct settings for Panda3D, making it harder to shoot yourself in the foot.

Indeed, Moguri said something similar in another thread, I believe.

I still have a few issues with blend2bam–as I understand it–however. First is that it doesn’t allow one to specify which models are to be exported. Second is that I’ve seen issues, I believe, in which it appeared that blend2bam had problems with exporting a multi-mesh animated model. Final is that I’m not all that comfortable with recommending a command-line-only tool (or at least one that has significant parameters) to very new devs.

(I’m also not clear on whether there’s a way to export a non-PBR material.)

Using glTF alone–while indeed having some issues with choice of parameters–would seem to alleviate at least the first and final, and I think that I’ve seen the second working, if I recall correctly.

If blend2bam’s major feature offering is configuring some settings for export in Blender’s preexisting tools, I’d like to offer the following suggestion:

  • We just ask the Blender devs to include an “Export for Panda3D” checkbox somewhere on the .glb/gltf export menu

For those of us building large projects regularly in Panda3D, having half the workflow require a command-line program that lacks object-specification is suboptimal.

It might be worth asking.

Another option is for us to build a YABEE-style export-plugin that sets those values, and that runs “panda3d-gltf”.

(What is the advantage of “panda3d-gltf”, if I may ask?)

Or could we perhaps come up with some sort of Blender-startup script that sets the values appropriately in Blender’s own export-screen?

However, I note that this approach wouldn’t allow the additional running of “panda3d-gltf”.

I’m not a big fan of this. We’d have no control over what this does exactly and every time we need to change what “optimizing a model for Panda3D” means there would need to be a new Blender release. For the time being the pace of improvements to the pipeline is too fast for this approach.

Maybe we should instead make blend2bam installable as a Blender plug-in, adding a separate option for exporting to Panda3D that always does the right thing, for those who do not want to use a CLI tool.

It allows you to load glTF files that are obtained from other sources, such as online asset stores.

That is a good point, I think.

Surely that would still have the limitation of only ever exporting the entire scene, and–if I do have this following issue correct–of multi-mesh animated-object exportation?

Ah, I see, and thank you. But is that really required when exporting from Blender? After all, in such a case the model being exported presumably isn’t in glTF format, as it’s being drawn from Blender. (Even if it was imported from glTF originally.)

I don’t think anybody building a game really wants to use a CLI to export models.

As it stands, it’s faster to just use Export Scene Operators — Blender Python API which makes blend2bam redundant, barring undocumented engine changes. This also allows the selection of specific model parts for export.

I question how pragmatic it is to actively avoid collaboration with the Blender community. Blender is for most purposes the default front-end of Panda3D. There’s only so much “wait for the features to mature” that a game developer will be able to tolerate. Without a timeline, and in the lack of information, it becomes easier to just build workarounds to design flaws than collaborate on them.

1 Like

A lot of scenarios require CLI tools. As instance, if you need Continuous Delivery, you use CLI tools for invoking the exportation from your building scripts. Actually, artists may prefer a Blender plug-in while they model, but scripts require CLI tools.

They are tools which address different levels of abstractions. Working with export_scene is a lower level approach, which makes sense when you need features that are not in the higher level approach (blend2bam). Anyway, blend2bam is faster since it abstracts several lower level aspects for you, so it may (should) be preferred in many scenarios. They target two different levels, it is not untypical.

To my mind it abstracts away a bit too much–in particular the ability to select what is to be exported–for it to be a tool that I’d suggest for general use.

That’s fair.

But when it comes to recommending a general-purpose tool, and especially one for use by beginners, it seems to me that continuous delivery and complex export-scripts are unlikely to be common requirements.

Further, I still feel that a non-trivial command-line tool isn’t a good choice for a recommendation to a beginner.