The fact that there are two different native model file formats in Panda (.bam and .egg) has always felt a bit awkward to me and may be quite confusing for new users. Lately some opinions were voiced concerning the usefulness of the .egg file format, so I decided to create this topic to discuss its future. Should it remain as it is? Is it worth it to keep enhancing/patching it (as well as its converters – egg2bam, bam2egg)? Or should it simply disappear?
While I do see the reasons for the existence of the .egg file, I’m not sure it’s a good idea to keep it around – at least not as a model file.
Let’s think about its strengths for a moment:
human-readable;
easily editable using a simple text-editor.
But what exactly would we want to edit in it or learn from reading it? Among other things, that could be:
texture file paths;
the material properties applied to the model;
whether the model has tangent and binormal vectors;
the names of any additional texture-coordinate sets.
But this kind of info is interspersed with loads of vertex data, so it’s not very comfortable to navigate to the data you’re interested in (a good editor makes this easier, but that’s not really the point).
And who would ever want to edit that vertex data itself? This seems better done by using the low-level geometry-manipulation methods in Panda and writing the results back to .bam, I think.
So my idea would not be to get rid of the .egg file, but to repurpose it as an optional “companion file” to the .bam file.
It would no longer contain any vertex data (which makes up about 99% of it currently), but rather those things truly worth editing, e.g. texture file paths – which would then serve as an override to the data in the .bam file – as well as useful info like UV-set names, whether the model is double-sided and so on.
What do you guys think? Feel free to share your thoughts!
At the moment, .egg is the bridge that connects panda to other 3D editors other than the main blender. However, the rejection of .egg is possible when the alternative is ready, .gltf format.
The files should be stored in the 3d editor project format, such as .blend and others.
I believe we should replace EGG with glTF, which already supports external buffers for things like vertex data. glTF has the same benefits of EGG (e.g., human readable, editable), but is a popular format that many tools/editors support.
I prefer the .egg file format, since many tools are built around it and I doubt many users of panda would even bother with opening up .egg files to examine their content, since they would probably depend on the existing tools, e.g. YABEE to generate .egg files.
Even if the shift is made to some other file format, will the average panda3d user really open the files in that new file format to examine them comprehensively? Won’t they simply continue to use whatever tools exist to import/export models without caring what’s happening under the hood? Will the average panda3d user want to open up a .glTF file and look into it, or will they more be interested in just loading it up to the scene and using it?
I think, in my humble opinion, it would be better to have a tool that converts an .egg file to some other format as opposed to getting rid of the .egg file format entirely, since I doubt most users will open up .bam files, .egg files, .gltf files or any other kind of file format to examine them anyways.
Also, some projects exist that already use the file formats and systems as they are, changing up too many things may cause complications for them as well.
Usually, those who examine the contents of files are not the copyright holders. And this is unacceptable, your own files must be source files in the form of a 3d editor project file.
Yeah, but I mean a typical panda3d user, especially a new one, won’t bother with opening an .egg file, or any other type of file to look into it.
They will usually just load the model directly into the scene and use it as an actor or nodepath from there. They therefore aren’t concerned with legibility or how “readable” one file format is when compared to another.
Very advanced users like @epihaius however would be more interested in looking into files and file formats, but not the typical panda3d user. I hope my point is clearer now.
Do I understand correctly that glTF doesn’t support tags of any sort?
If so, then that’s a bit of a nuisance: tags are an excellent way of enabling the dev to specify data in the modelling package and have it be available to the game.
(An example might be in-level spawner data; another might be the specification of a custom shader.)
Now, if Panda had a dedicated editor, then the lack of this might not be quite so bad: the editor could take part of the work that might currently be done by the modelling package.
But as it is, tags are a very useful tool, I’ve found.
Which then removes the advantage that glTF doesn’t require such an exporter.
(Similarly, one could create an exporter that writes things like tags to another file… but then, again, the advantage of not requiring an exporter is lost.)
In fact, I’m not concerned about the lack of alternatives when exporting files. Because I have a plan. Just yesterday, I added the ability to export collisions to my exporter. I think it won’t be difficult for me to add tags.
I think we need a table of differences between EGG and glTF.
For example, glTF does not support billboards and so on…
What about the texture parameters, whether filtering can be specified, and so on.
Mixing, stencil, and so on.
Egg supports many features that glTF doesn’t. But most of the features of Egg go unused for most people. I would rather look on a case-by-case basis when people run into problems with glTF about how we can solve that (possibly using a glTF extension).
If there are people who need Egg in their pipeline, then they can continue to use Egg. I don’t see an issue with offering an Egg module on the side. But I would like new projects to be able to use glTF and get all the benefits of that without hitting a brick wall.
Texture filtering options can be specified in glTF, but I do not think advanced texture stencilling is possible.
To clarify as to why I suggested the companion text file to a .bam file: it was actually my intent to promote the export of .bam files directly (at least for Blender, for which we have blend2bam). The downside of .bam files is of course that they cannot be edited or read, but apart from that I still think they are the preferred model format for Panda, as they are native to the engine. That’s why it seemed like a good idea to have an additional file to store all of the editable and informative data. But I realize now that one could just edit a .glTF file and then convert the result to .bam if desired.
Just out of curiosity: are there any other downsides to the .bam format currently? Is backward-compatibility still a problem?
On a related note, it seems that loaded .bam files still get added to the model cache. Could that be changed? (Without having to set some config variable – which could easily be overlooked by the developer, but by detection of the loaded file-type, I mean.) After all, finished projects usually ship .bam files, so why fill up a cache on the end user’s machine with copies of them?
Actually, bam files are the core format. Internally, the engine will use bam files anyway. The point here is which path is better: egg2bam or gltf2bam. Even with egg files, you already decorate the nodes with several custom/well-known properties in a real project (an example is the Collide property illustrated here, but you need several other custom properties in a typical project, in order to communicate the semantics of the nodes from Blender to the application). This may be the same with glTF. You can use your properties/extensions and well-known properties/extensions eventually managed by gltf2bam.
I think that would be the best option. To not do away with the present egg and bam file formats, since some people have already heavily invested in building their projects around that, even when it comes to things like producing models, actors and animations procedurally within their applications and then storing the results as an egg or bam file. If you completely do away with the egg and bam formats, such people would have to make too many changes to their projects unnecessarily just to accommodate a new file format.
So I humbly implore you to kindly retain support for egg and bam files as they are, even if you want to add support for glTF or any other file formats going forward, please.
If glTF supports the basic functions of Egg, then of course it is better to remove Egg.
Practically, Egg support was discontinued with the release of Blender 2.8. During this time, no one took the responsibility to create a new exporter or keep YABBE up-to-date on an ongoing basis.
Also, the egg has design flaws. I don’t think supporting an outdated format will benefit the community and developers. I’m pretty sure the people will split into several camps. Those who prefer glTF and those who like Egg. Over time, the latter will be few and far between in terms of content creation techniques.
