So what formats does Panda import properly, besides egg in 2022?

[sutemp]

Info in the manual seems outdated or lacking. I know there’s a stickied thread called “Exporting from Blender: A Quick-Reference”.

There’s hints across the forum and info on the internet, but no info in the manual, that Panda can load any format ASSIMP can.
There’s also the third part gltf plugin.
But ASSIMP already supports gltf, so what’s going on?
Then there’s Collada DAE. Collada’s wiki mentions Panda can import it since version 1.6 through FCollada. Panda3D - COLLADA Public Wiki
But there’s no mention of collada importing in the manual that I could find.
Even through ASSIMP, Panda should support Collada, but again no reliable up-to-date info on ASSIMP either.

I have to be honest, this is a bit of a mess. There’s just 3 manual pages you need to update to clearly show what is and isn’t supported in 2022. There’s no need for forum posts and stickied threads, it just provides contradictory info on everything.

[rdb]

Yes, fair, the documentation is a mess. I’ll see if I can find some time to work on it.

The primary formats that Panda3D loads natively (as in, directly into Panda’s memory structures, rather than via an intermediate representation) are bam and egg.

We support loading arbitrary formats via assimp, also natively. This supports all formats that assimp does, but because assimp is a general library, it will load the common subset of features supported by most of these formats, but some of the format-unique features will not be supported as well. So, we do load gltf files via assimp, but things like PBR materials won’t work so well.

Then there are third-party loaders. Most notable is panda3d-gltf, which is a high-quality loader with support for PBR materials and is enjoying active use. blend2bam is a related tool that uses panda3d-gltf under the hood. This is the recommended way to get assets from the newer versions of Blender.

There are also some plug-ins to export to .egg for modelling programs like Autodesk Maya and older versions of Blender (YABEE). A few plug-ins export to .bam directly to support more features.

Finally, we have a suite of tools like obj2egg, x2egg, dae2egg, etc. Because they load through .egg, they only support the subset of features that are supported by the .egg format.

COLLADA has fallen into disuse for the purpose of getting assets into game engines in favour of glTF so its use is no longer promoted.

[sutemp]

Thanks, this clears up most things, especially the part of two libraries supporting glTF at the same time.

I may be wrong, but the documentation seems to be totally lacking info on ASSIMP, I may be wrong but it’s only mentioned in the Features page of the website in " Library Bindings", but not in the docs, and some info on it being developed in some old forum posts, so it wasn’t clear how maintained it is.

COLLADA is old, but in terms of most 3d tools being able to export to it, it is still used. Is it simply not promoted, or not feature complete with regards to the format itself?

You mentioning PBR materials raises more questions. All info I could find was there was a user by the name Tobias developing a shader manager with PBR support, but it looks like it was never added to Panda officially. So when you say a 3rd party model loader supports PBR materials, are you saying that third party model loader supports PBR materials for a 3rd party renderer, or something else?

Thanks

[rdb]

Yes, I’m working on rewriting the entire art pipeline section in the manual. It needs a good overhaul. Probably a table of formats with their supported features as well.

Our COLLADA converter (dae2egg) is based on the FCollada library, which was deprecated a long time ago and is no longer being maintained. It will work today, but will be removed at some point in the future, after which the recommendation will be to convert .dae files to .gltf via the Khronos-provided converter.

“PBR materials” refers to a material model that has become popular in modern engines that is designed particularly for use with renderers that emulate a physically-based rendering style, such as Tobias’ RenderPipeline extension and the panda3d-simplepbr library, or any custom PBR shaders you might have. It is also what is recommended for getting good results with modern versions of Blender, which has adopted this same material model. By default, Panda3D does nothing particularly special with PBR materials, however.

If you tell me more about your content authoring process (assuming you already have one) I could perhaps give you more specific recommendations.

Here is some information about Assimp that I am copy-pasting from the manual page I’m in the process of writing:

Panda3D also provides a plug-in out of the box that integrates with the Assimp
library. This library supports a broad range of different formats, such as .obj,
.stl and .dxf, allowing them to be loaded into Panda3D without a conversion
step.

The full list of supported formats is available on this page:

https://assimp-docs.readthedocs.io/en/latest/about/introduction.html

The quality of support varies substantially from format to format, and it is preferred
to use a more specific plug-in if one is available for that format. For example, it includes support for .gltf files, but the panda3d-gltf plug-in (mentioned above) is considered to be higher-quality.

Please note that while skeletal animations are supported, morph targets are not
currently supported by the Assimp plug-in.

[sutemp]

I guess the only remaining confusing bit is the suggestion to use a format (glTF) that only seemingly works correctly with PBR shading, while PBR shading is not supported in Panda natively and the third party renderer which does support PBR (panda3d-simplepbr) is too basic. GitHub - Moguri/panda3d-simplepbr: A simple, basic, lightweight, no-frills PBR render pipeline for Panda3D

In fact, doesn’t simplepbr have less supported texture maps than Panda’s non-PBR shader generator?

1. normal maps - supported by both
2. parallax maps - only supported by stock Panda?
3. specular maps - supported by both
4. emission maps - supported by both
5. ambient occlusion - only supported by stock Panda?

So if one is not planning to extend simplepbr themselves, the only advantage of the PBR materials and available PBR renderer is the texture maps working correctly with the glTF exporter? Rather than the additional rendering features PBR provides? Doesn’t seem like a good tradeoff for using a 3rd party renderer and specific file format.

[rdb]

When I talk about PBR in an art pipeline context, I am talking mostly about material parameterization, not shading. The classical way to think about material properties is in terms of diffuse, specular, and shininess colors/texture maps. The new-fangled PBR models instead ingest base color (=albedo for dielectrics, F0 for metals), and roughness-metallic maps. Other maps, such as normal maps and emission maps, are model-independent.

Some formats, such as .obj, only support the “classical” parameterization. Other formats, such as .gltf, only support the “PBR-style” parameterization (although since it is an extensible format, an extension might exist to add specular/whatever maps).

In my opinion, the choice of using glTF versus a “classical” format with diffuse/specular maps boils down to what is being produced by the art team / authoring tool. For example, newer versions of Blender have completely embraced the new parameterization. If you want to create an object with varying degrees of shininess in Blender, you’re going to have to use a roughness map—it’s not even possible to bind an “old-school” specular map in Blender anymore, at least not without jumping through hoops with custom shader nodes. So, if you wanted to get such a model meaningfully out of Blender, it’s going to have to be through some format that can meaningfully represent these “PBR-style” properties and maps.

While Panda doesn’t by default offer PBR shading in the shader generator, it does understand the materials that are found in glTF files and will apply the parts of it that it does support, such as the base color map, the normal map and the emission map, so if you don’t have or care about these maps, it will still work out of the box. PBR-specific texture maps like roughness-metallic maps will be supported by a future version of Panda3D. panda3d-simplepbr is designed as an interim solution to get models from Blender/glTF to show up closer to how they appear in the authoring tool.

Furthermore, many users of Panda3D who wish to achieve a particular look will end up creating their own shaders, which can of course be tailored to match the material model preferred by the art team and authoring tool.

[sutemp]

@rdb

While Panda doesn’t by default offer PBR shading in the shader generator, it does understand the materials that are found in glTF files and will apply the parts of it that it does support, such as the base color map, the normal map and the emission map

In that case it sounds like using simple-pbr without extending it only makes sense if you don’t want to use parallax maps which it seems to not support, and you want to use roughness maps which it does and official Panda doesn’t. Does this sound about right?

many users of Panda3D who wish to achieve a particular look will end up creating their own shaders

This may have made sense pre-2010, but in this day and age I believe most dev teams expect a shader generator and visual editor from a modern game/3d engine. This is just some feedback. I don’t think you will get many users these days ready and willing to write their own shaders rather than creating them in a visual editor, and it will just translate to less users using the engine.

[rdb]

Thank you for the great questions, by the way! This will help me know what to cover when writing the updated documentation.

@sutemp

In that case it sounds like using simple-pbr without extending it only makes sense if you don’t want to use parallax maps which it seems to not support, and you want to use roughness maps which it does and official Panda doesn’t. Does this sound about right?

This is a correct observation. I might remark that panda3d-simplepbr is really designed to render glTF models correctly. It looks like the Khronos Group is working on adding displacement map support to glTF, and I expect that when this is added, simplepbr will likely be extended to add support for them.

@sutemp

This may have made sense pre-2010, but in this day and age I believe most dev teams expect a shader generator and visual editor from a modern game/3d engine. This is just some feedback. I don’t think you will get many users these days ready and willing to write their own shaders rather than creating them in a visual editor, and it will just translate to less users using the engine.

Of course. We plan to add support for PBR shading to Panda3D’s own shader generator, making simplepbr obsolete in the process. I can’t make any promises about a visual shader editor, though. Aside from the limited developer resources, Panda3D has always been a bit more of a hands-on engine than Unity and Unreal, and many users appreciate it for that. That said, we’re always willing to consider ways we can make writing shaders easier.

[sutemp]

@rdb

Panda3D has always been a bit more of a hands-on engine than Unity and Unreal, and many users appreciate it for that.

I think they appreciate it being open source and more extendable than Unity/Unreal, but I’m not sure anyone appreciates not having a visual shader editor (a lack of a feature), as it’s not like it is a choice between writing shader code or using a visual editor: Unity/Unreal allow both.
If you don’t have the resources to add a shader editor, you can always maintain a Blender shader exporter plugin and rely on its node editor. Even if the user does not use Blender for their assets pipeline, they will only need to familiarize themselves with the stock “Shading” Layout of Blender UI to be able to use it.

[rdb]

That’s a great idea. Some number of years back, I’ve experimented with exporting shaders directly from the Blender material editor, which to my surprise actually worked fine at the time, though Blender has changed a lot since then. With Panda getting a significantly improved shader pipeline in the upcoming 1.11, that seems like something that could be revisited.

I’m also thinking that it might make sense to offer a simple API to string together shader nodes in Python, upon which such a visual shader editor might be built, while retaining the possibility of a code-based approach and not locking people into a particular editor workflow.

[sutemp]

@rdb

I’m also thinking that it might make sense to offer a simple API to string together shader nodes in Python, upon which such a visual shader editor might be built, while retaining the possibility of a code-based approach and not locking people into a particular editor workflow.

I think you are basically describing the non-GUI portion of a shader editor.

Should be relatively straightforwards to have

1. Such a shader node backend (core) for defining shader nodes by code

2. Blender API wrapper for the above, to map the Panda shader nodes to Blender shader nodes. The wrapper code can be part of the Blender plugin, does not have to be part of the Panda API.

3. Blender plugin to add GUI to 2

4. Ability to use 1 in code or allow to write a custom GUI for it by anyone interested.

[Thaumaturge]

@sutemp

If you don’t have the resources to add a shader editor, you can always maintain a Blender shader exporter plugin and rely on its node editor.

This is, I think, a good idea.

That said, I do have one qualm:

From what I gather, Blender has in the past, at least, been in the habit of changing things in their API between versions (aside from the major changes incurred by their reworking of the program after ~2.78). This potentially creates a bit of a maintenance issue, in which the plugin may cease to work with the next version of Blender and have to be updated, or even reworked, in order to retain compatibility…

Still, it might be wiser than creating a Panda-specific tool, as Blender has already done the work of creating a UI, and representations of various nodes. Not to mention the utility of potentially being able to preview one’s shaders in Blender, especially when using that program as one’s level-editor!

[sutemp]

@Thaumaturge

Still, it might be wiser than creating a Panda-specific tool, as Blender has already done the work of creating a UI, and representations of various nodes. Not to mention the utility of potentially being able to preview one’s shaders in Blender, especially when using that program as one’s level-editor!

I think you are talking about stripped Blender fork for only doing shader creation and export, when you say a Panda-specific tool.
That has the pros and cons of any fork.

I don’t think a fork in this case is going to be much different than asking developers to download an earlier version of Blender and using it for Panda shader editing. Blender does not prohibit having multiple versions on the same machine.
As a con you will have to do the work of stripping unused bits of Blender for your Blender-based shader editor, maintain the fork and have to redo it when new versions of Blender provide new needed features and you might want to migrate your shader editor for to use the new codebase.
In the end it may be more work than just maintaining a shader exporter script and keeping it up to date to the latest Blender version.

[Thaumaturge]

@sutemp

I think you are talking about stripped Blender fork for only doing shader creation and export, when you say a Panda-specific tool.

No, not at all–I was thinking of a custom-built program, unrelated to Blender, to the purpose of defining shaders.

Think Panda’s “Particle Panel”, but for shaders instead of particles.

As I said, Blender has already done the UI and node-definition work, so it makes a lot of sense to just use that.

[sutemp]

@Thaumaturge

so it makes a lot of sense to just use that.

My bad, I thought by this part you meant forking, rather than using Blender.

[rdb]

I’ve reorganised the Model Export section of the manual that was hidden away under Tools into a more visible Asset Pipeline section in the manual, adding more information about supported formats and their limitations, Assimp, glTF, COLLADA, etc. Starting here:
https://docs.panda3d.org/1.10/python/pipeline/model-file-formats
There are more improvements to be made, like Assimp and glTF are probably advanced enough topics that they should be split into their own pages, and we need more on troubleshooting common pipeline problems, but it’s a start. Writing documentation is quite time-consuming for me so if anyone else wants to contribute that would be greatly welcome.

If you’re still missing anything, though, or think something is unclear or in the wrong place, please don’t hesitate to let me know.

Apropos, while making the table on the linked page I noticed that Assimp has gained a bunch of features, including support for PBR texture maps through glTF and OBJ, so I’ve actually added support for those, while fixing a bunch of bugs, these changes will be in 1.10.13.

[Thaumaturge]

Based on an admittedly quick glance, that new page looks rather good to me!

In particular, the feature-comparison table is rather interesting, and potentially rather useful…

Further, I think that it was a good idea to create that “Asset Pipeline” section–that should make it rather easier and more-intuitive to find articles on these topics!

[sutemp]

Thank you.

When you say “This table lists the most commonly used supported file formats and the various features that are supported by these formats.”, do you mean “that are supported by these formats” or “that are supported by these formats within Panda”?

There seems to be several “types” of glTF files, and Blender by default export setting is for exporting a glb binary GLTF file which Panda ASSIMP fails to import.
The Assimp webpage does not clarify this which may cause confusion for the users.

Maybe this should be clarified.
In comparison, if panda3d-gltf plugin is installed, glb files load as well.

This manual page gives the impression that panda-gltf plugin is the only way to import GLTF and has no mentioned that ASSIMP can do that too without installing extra plugins. Converting from Blender — Panda3D Manual

[rdb]

Thank you, good questions! I will clarify those. glTF probably deserves a dedicated page at some point, there is a lot of information we could add, including on the supported extensions.

The list of formats is the subset that is supported by both the format and the importer for that format. For example, .dae supports morphs targets, but neither our Assimp loader nor dae2egg loads them, so it’s marked as an . And the Egg format can actually store metal-roughness maps, but no tool that we have that produces Egg files currently takes advantage of this, so it’s also marked .

For the record, Panda Assimp not loading certain types of glTF encodings properly is one of the bugs I fixed for 1.10.13. But these kinds of issues are exactly why we recommend panda3d-gltf in the first place, and don’t really mention loading glTF via Assimp a lot. panda3d-gltf is just more mature.

[sutemp]

Is Panda nightly builds still a thing? I could test out the fixes.

It may seem niche, but specifying which format supports vertex colors is still useful, a lot of current generation games still use it to add fake ambient occlusion to terrain.
I noticed exported from Blender, glTF doesn’t seem to support it, OBJ doesn’t support it, Collada DAE does but there’s some oddities, colors are not right, maybe saved in the wrong color space. I can provide more info if this doesn’t sound normal.
I check vertex colors on NodePath which is not illuminated by any lights, that used to work few years ago and I assume that’s still the expected behavior.