While i’m aware that a lot of the community is moving to the Collada format, I believe that a lot of us still use the default exporters that come with Panda for whatever 3D package we have. Here at the ETC we use both Max and Maya.
That said the members of the Panda SE project were wondering if there was anything we could do to make editing and updating the Max egger easier.
We’ve been fixing a few bugs here and there in the .dlo, and for whatever reason it looks like a lot of the code to pull things from Max and the code to actually process it is in the same place. Also editing the UI via a .rc file in Visual Studio didn’t seem too “max like” to us either. The more and more we thought about it, it might be a good idea to move the UI out of C++ and into maxscript. Still keeping the .dlo to get access to the Egg helper functions.
Before we do any kind of overhaul on the egger like this, We decided it would be better if we asked everyone in the community if they thought it would be a good idea. If there isn’t huge opposition to the idea we’d like to get moving ASAP. Here are some benefits we think the community would get out of the overhaul:
-quicker UI updates independent from processing code
-easier debugging of max scene data to be egged
-still retain the speed of the C++ code
-easier for a less experienced code to maintain and fix for most issues
-Maxscript hasn’t changed much since version 3.0 while the C++ API has.
-easier way to add support for certain max features/modifiers (ie. Morph targets)
Let us know what you think. We obviously don’t want to fix what isn’t broken. Remember the eggs will still look the same, it’s just the exporters architecture we’re talking about here. Thanks in advance.
Hi Andrew. One of the goals of Panda 2 (for which we did the first commit today) is probably gonna be native Collada support, and dropping egg. I say “probably” because we are discussing other priorities first, but it’s desired by the small group of community developers and I think David from Disney would be favorable to it, as a long-term thing, so I don’t think you should put any work in egg at all, IMHO.
By the way, the underlying graphics system is also gonna change a lot, so your planned improvements of the shader system are gonna be useful only for a couple of years at best for most people.
I think we should try to coordinate the efforts between the student groups and the community developers more (and we in the community in turn tend to check every idea with David first) so that your changes can stay and be relevant. For example, the Helix support done by a student group was ultimately removed from Panda some days ago, it just didn’t make much sense, plus it was a GPL dependency. This kind of thing could have been avoided easily. I will discuss this and contact you privately so that we can open a channel of communication.
I’d be interested in any improvements over the actual state. But i see Goggs points. So i guess i’ll just point out my view.
I just want to think of the least amount of technical details when doing modelling/texturing. With panda3d i have to consider all kinds of limitation; limitations due to Panda3D and due to the exporter (which i had to find out the hard way).
There is no scripting support which makes it a tough time for anybody without C/C++ knowledge to create any sort of project-based pipeline.
The dlo exports every object with it’s pivot at (0,0,0). If you want to do any rotation or scaling to it, you run into all kinds of problems.
The dlo exports only the very basics of any shader without taking advantage of neighter 3DSMax capabilities nor the ones of the EGG format.
It only works for geometry and bones. Cameras, lights and other objects ain’t supported.
Like this, exporting a simple scene of a room with some furnitures into panda is a huge amount of work with the actual dlo. I have to split up all objects with more than one texture (which i already scripted). All the material settings are lost, even the ones that would be supported by the EGG format. I’d have to add them in code. And if i want to be able to transform anything in this scene, i have to move it’s position to (0,0,0), export it and move it back. As long as i have a handful of objects, it’s a little annoying. With several dozens the effort would grow exponentially, unbearable for a single hobby user like me.
It was easier for me to write a new exporter to overcome these problems than to work around them.
Collada exporters for tools like 3dsmax are more mature and featured, better supported and maintained elsewhere. Improving the Collada support in the engine would probably solve all those problems for all the modeling tools at once. Although I have no tested the collada exporters in the 3dsmax case, it seems they support lights and materials just fine, I doubt they also suffer from the weird behaviors you described. My 0.02.
That’s what i guess aswell, after all Collada is the PS3-format and therefore the 3DMax-exporter might be more production-proven, right? I don’t have the tools to test that…