Honestly, even I am only really sticking with egg because my main project’s pipeline is built around egg + YABEE, combined with not having gotten around to learning the new version of Blender.
I do have concerns about a move to PBR–but then I don’t know enough about PBR to know whether those concerns are valid.
The development of the blender is happening rapidly, to be honest, I thought that this fact could become a problem for maintaining the exporter in an up-to-date state. Based on this, I had the idea to create tools based on the panda itself. However, I still decided to use the plugin / editor approach.
It makes no sense to inconvenience anyone. There’s no reason for .egg/.bam to be discontinued simply because a new file format is proposed. Multiple file-formats can co-exist and everyone can be happy. There is no reason for people to split into different camps, when people can simply choose the file format that best suits their needs.
There is one reason: maintenance. The more file-formats are supported, the more systems there are that call for maintaining, I imagine.
And if people are moving away from a given format, or if another proves superior, why insist that the engine’s devs continue to do the maintenance for a deprecated format as well as for a new one?
Well, if there are certain projects that are about to be published which already heavily utilize the egg/bam format, then changing up file formats will cause further delay, since a lot of changes would have to be made unnecessarily. (Some people have written custom tools that generate models, actors and animations from within their Panda3D application, all of which are based on the bam/egg file format, for example).
I also doubt at this point it takes a lot to maintain egg/bam, since the devs are already familiarized with them, moreover, upon adding glTF, that would only make 2 file formats to maintain: egg/bam and glTF.
If some people are using egg/bam to publish their projects, that brings traction to Panda3D. If others want to use glTF, that brings traction to Panda3D as well. Everyone wins in the end.
Sure–but I don’t think that anyone is talking about entirely dropping the egg format this very minute. This is likely to be a process.
To be clear, I’m one of the people who is currently relying on the egg-format, and I don’t see this move as a threat to that–as I’m not expecting such a move to happen immediately, or suddenly.
You might be surprised.
For one thing, as new features are developed, they may impact other features, including file-format support. For another, as technology moves on, adjustments may be called for in one or more features. Further, new functionality may be requested over time, whether in general or as a result of changes in the industry.
An in all cases, the more variants of a given feature there are, the more maintenance work is incurred.
Well, in this particular case, it would be the Panda3D devs that would know how much would be needed to maintain bam/egg. I just assumed it wouldn’t be too hard a thing to do.
I personally don’t really see the point in shifting file formats. It would be better to have a bam/egg to glTF converter written instead. In any case, if this transition happens, I hope that support for bam/egg isn’t dropped or if it is, it happens a long time down the road.
My understanding is that this is, in general, more likely to be an incorrect assumption than a correct one. Maintenance not-uncommonly has elements that are not apparent to the outside observer, I gather.
(Although I do stand to be corrected on that.)
Offhand, as tools and industry processes move on, the old formats become less useful. Further, the use of a format common in the industry would lower the barrier to entry for devs coming to the engine with experience in that format.
Ok, but I doubt incoming devs would look into actual file formats. They would just use exporters from blender, maya, etc. Even now, how many panda3D users understand the structure of a bam/egg file? Not many. Most use modelling programs then export their files for use in Panda3D. Changing over to glTF or anything else will not change that, as few would bother going into the details of a glTF, bam or egg file. This is true for other engines and their file formats too, from Unity to Unreal Engine. I doubt most who use those engines bother looking into the guts of the files they’re exporting, unless they are advanced users.
I do get what you’re saying however, about keeping up with the times. I just hope it isn’t a sudden shift with many inconveniences. I still think a converter would be the better option…
You’re somewhat right, I think, but I come to a different conclusion:
I’m not suggesting that devs will look into the internals of a given format, but rather that they may already have experience in using and/or exporting to that format.
A dev already experienced in a given format will likely already know how to export to that format from their modelling package of choice. As a result, having that format be supported here would mean that they wouldn’t have to learn the use of a new exporter, and thus ease their transition into the use of the engine.
If that’s the case, wouldn’t it be better to familiarize the exporter(s) instead of changing up the entire file system? It would be the exporter(s) they are familiarized with and not the file-format itself. Even majority of those using glTF right now don’t know what’s inside it, but they do know how to “export to glTF” using an exporter(s). That’s all they’re really familiar with in the end…
If it’s about ease of distribution, then a bam/egg-to-glTF converter would please all parties too.
Anyways, if there are other significant benefits to glTF and it proves costly to continue support for bam/egg in parallel (I truly hope this isn’t the case), then I at least hope it doesn’t happen too quickly and too painfully.
I mean, if it’s feasible to make the egg-exporters be just the same as the standard glTF-exporters, then maybe. There would still be the bump-in-the-road of getting and installing the egg-exporters rather than just using already-installed glTF exporters, but it would be less troublesome than learning an entirely new exporter.
But that likely calls for dev-time on the part of the engine-devs (or community-members), too.
In addition, would we be talking about having our own glTF exporters? Surely we’d simply be leaving exportation to whatever third-party tools the artist is used to working with. If so, then removing the egg-format also means removing maintenance on exporters.
That’s fair.
Conversely, however, I hope that it it doesn’t happen so slowly that it holds the engine and community back.
The incoming new users would still have to install and learn Panda3D regardless, whether or not they’d have to use an egg-exporter or a glTF one. In that sense, because they have to learn an entire new system no matter what, does it really make that much of a difference?
Ok, but in my humble view, I think two-way converters would work better. The final adjudicators are the Panda3d devs in the end, who are always pleasantly considerate! 
One less element to learn is still an advantage, I would say, so yes.
Even if they work better–and I’m not sure that this is true–they’d still presumably be more work!
This at least I do agree with, I believe! 
@Game_Starter I want to reassure you, Bam cannot be deleted. Therefore, your work will not be in vain. You can convert Egg to Bam using any latest version of Panda.
Thanks for the assurance, however, the work I’ve done is mostly centered around the .egg format thus far, producing actors and animations from within Panda3D and not any other modeling program such as blender/maya and then storing the results as egg files. I hope to post some of it in the near future as a devlog of sorts.
I can only hope for the best outcome in the end. 
Can you not store the results as bam files–or even glTF files–perhaps?
Once I post it on the showcase section soon, then you will see why I cannot do that at this time. If I had to change the file-formats, I’d have to study glTF files and change up quite a few routines in my application to adapt to them, time that I could spend finishing up other parts of the project…
As for converting them from .egg to .bam in real time, you mean using some Panda3D in built method or tool? Wouldn’t that mean continuing support for .egg/.bam? I can’t say much about that now since the final decision on the future .egg hasn’t been said. I can only hope it’s a considerate one.
I used to also have the misconception that Bam is a binary representation of Egg. However, Bam is a Raw snapshot of RAM from the Panda classes. That is, this is the same thing that Pickle in Python does.
Ah, fair enough–you know your project best, so I’ll take your word for it.
(I would have thought that a third-party package might have handled the actual writing to glTF, removing the need to study the format yourself–and so want to have it mentioned here as I just did–but there may be other constraints on your program that I’m not aware of.)