Hi everyone!
I not satisfied with the current EGG functionalities, but I not familiar with C/C++, so possibly I will try to extend it via additional file and appropriate python module to load this file.
It should look like this:
this code should load ‘box(.egg/.bam)’ model as usually, then load additional box.eggext and modify box respectively. For example - attach additional objects, shaders or something else.
If this module is needed to someone else, please tell your opinion - what should be included in this extension?
My opinion:
I would wait for .dae support, but I’ve been waiting for it for way to long… and I kind of like the egg format.
So I like the idea.
I would find a use for PythonTags, but maybe not with serialized objects, just dicts and lists(tuples?) of strings, ints, floats. What I do now is to dump a dict or list with json and write it as a ‘normal’ tag, making it more automatic would be nice.
I could also find a use for loading actors with just pointing to one egg file, the egg file should then have the names and filename of animations for that model.
Can’t think of anything else, shaders would be the biggest benefit.
It would be good to move to an extensible format like COLLADA, though the reason I’m not so motivated for the COLLADA integration is the fact that Blender3D’s support for it seems to be spotty and they don’t seem to be interested in keeping it in the long term. However, we might be able to make our own exporter for Blender, or perhaps even make a blend2dae utility.
In the meantime, it’s not a bad idea to add features to .egg as needed. I recently started doing some work on implementing shader support, however, I got sidetracked (don’t hesitate to poke me when I forget about things I promised to do), I’ll see what I can do about getting back to that code.
Feel free to propose new .egg syntaxes, and after we agree on a good syntax for a particular feature, someone could perhaps work on a patch.
About your proposed egg extensions: fine in principle, but it seems unnecessarily difficult to implement; it requires an additional file loader and there are also additional considerations such as complicating the mapping an .egg file to a cached .bam file. It’s probably easier to add a special node to the .egg file that allows you to hook a function in to process nodes of that particular type.
If you wanted to implement that on the Python side, you could use tags to do this, such an a “load-type” tag which contains a name that is looked up into a dictionary of Python functions that could be passed to the loader function. Each Python function would then select appropriate tags from the .egg file to load the required node type.
COLLADA is a good format and have two undeniable advantages:
It’s standartized and we don’t need to reinvent the wheel;
the most popular 3d editors can export models to the COLLADA. May be not full featured, but it better than nothing.
Hence if Panda would have a native COLLADA support, then bunch of exporter for each 3d editor will no longer be required.
As for Extension. I mean that I wouldn’t to touch main egg/bam file and loading mechanism for it, I’ll make additional file with appropriate information.
This extension have two main targets in mind:
It should has painless integration. Ideally - one line of code for plug/unplug it without changes in the other sources;
it should be extendable by user without making changes in the main API.
And converting any 3d editor to the Panda scene editor In the long term.
Here an example of how to extension can be integrated. Nothing happens if you don’t imported EggExt or if you imported it incorrectly (before init ShowBase). Just additional actions will not execute. extension_test.zip (644 Bytes)