Is there a practical maxmimum to the number of polygons an EGG file is able to handle?
I’m new to Panda3D (great experience so far) and I exported a 1+ million quad(2+ million triangles) interior set from Maya 6.5 (not heavy at all) into a 350 meg EGG file. However, when I tried to convert this EGG file into a BAM file the process died - both under Windows XP and Windows XP64 - and I have 3GB of memory. I fully understand 32-bit OSes have a 1.6 GB process memory limit, but egg2bam.exe died after eating 2GB of RAM under Windows XP64.
What about practical texture limits? If I baked global illumination into textures would Panda3D not care about the total number of textures used and rely on OpenGL/DirectX drivers to upload textures to the video card memory?
I’m kinda stress testing Panda3D at the moment… so yes these are all kinda of degenerate cases, but at the same time 1 million polygons in scene is not uncommon. Ideally I should split the set up into PVS (potentially visible sets)…
There aren’t any fixed limits on triangle counts or texture sizes.
However, there can be a practical limit on the number of triangles within a given node. I would call 2 million tris in one node to be on the heavy side. I suspect Panda is dying trying to generate triangle strips for all of those triangles. If you divide your scene up into multiple nodes, it will be much easier for Panda to strip them up, since it limits the search space for the ideal strip length.
Even if your Maya scene is defined using separate nodes, if you are converting as a character (with -a model, for instance), then you are asking Panda to drop everything into one node. This is certainly a mistake; environments should be converted as static models, with -a none (or without specifying -a).
If your Maya scene is defined using one big polyset, then it will be converted as one big node. Ideally, you should subdivide this polyset spatially and hierarchically before trying to import it into Panda.
As a workaround, you can disable triangle strip generation by putting:
egg-mesh 0
in your Config.prc. This should allow you to convert the egg file without having to divide it up first. Panda should then internally subdivide the model into small enough pieces to feed to your graphics card, which isn’t going to like receiving more than 64K vertices per call, but you’ll be walking on new code there, so tread carefully. But the point is that there’s a huge difference internally between a big monolithic model and a big subdivided model.
As to texture sizes, I wouldn’t expect you to run into problems until you ran out of RAM and/or framebuffer memory.
When I exported the scene using the MEL GUI I got a 350 meg EGG file. Using the command line exporter and the “-a none” option, I got a 310 meg file. I assume the exporter detects keys on the topnode?
No tool on my computer would diff the results in a reasonable amount of time.
Most of the geometry in the Maya scene (an interior of a room) is in separate groups/nodes, but I tried ungrouping a few larger nodes and got the same results (with egg-mesh 0). The egg2bam process died when it ran out of memory. From the Task Manager I saw the process hit 2.0GB and halt. I was about to ask about Panda’s support for tristripping eventually. Thanks for info. However, I didn’t think tristrip generation was such a memory intensive operation - computationally yes. I plan to split this Maya scene into separate MB files.
Is there metadata support in EGG? i.e like tagging bits as “goal” or “tree” or “flammable”
I’m not sure what the maya2egg defaults for the MEL GUI are. Probably that extra 40MB bulk is for the skinning information that comes along with character models, which does suggest that the GUI is defaulting to exporting a character model (which isn’t really a good default behavior, in my opinion).
Tristripping can be a memory-intensive operation, because it has to build up a big cross-reference table for all of the vertices, edges, and triangles in your cluster, and keep track of the edges it has already stitched together. Still, if you are converting as a static model, it shouldn’t be much of an issue; if you’d like me to take a look at it and have some web space somewhere, you can post your (zipped) egg file somewhere I can get to it, and I’ll be happy to investigate a little more closely.
The egg syntax supports various kinds of metadata tags. The most general is the “tag” syntax, which simply adds whatever tag and key you specify so that it can be queried at runtime with the NodePath.getTag() interface. There’s also a simple Mel script we supply called eggImportOptions.mel that adds a pull-down menu to Maya to add any of a handful of predefined flags to a node (and you can edit the script to add more flags of your choosing).
Doh. I looked in the bigger file and saw the joint weights for each vertex in the form “// xxxx” - a couple of objects were skinned with simple joints. Even props need to be animated once in a while…
Thanks for telling me about the file, it was buried in source (not in the binary install). However, I can’t see how to tag a node in Maya with it.
Looking at the Egg file format doc… I see
key { value }
This attribute defines the indicated tag (as a key/value pair),
retrievable via NodePath::get_tag() and related interfaces, on
this node.
Of course none of the egg files I’ve exported from Maya have s. Ideally I’d like to change the exporters to generate Tags from user-defined Maya attributes (sans Mental Ray / Renderman junk).
OK. I’d recommend putting animated props of this nature in a separate file, so they can be easily controlled independently, and also so that Panda can load the bulk of the file as a simpler static model. (Also, some kinds of prop animations can be done in Python code, by setting transforms in a task, without using Maya animation and skinning. It depends on the nature of your scene, of course, but if you have simple programmable type animations like this, then you can still export the whole thing as a “static” model.)
Oops, what a big gaff on my part–I said the wrong file name. The mel script that tags egg nodes is eggObjectFlags.mel, in the directory pandatool/src/maya. I don’t know if this is shipped with the binary install or not.
The way it works is by adding the syntax “ { foo }” to your egg file, where “foo” is the option that you pulled down from the menu. It is then up to you to define what “foo” means in the egg syntax; you do this by putting the appropriate line in your Config.prc. For instance:
egg-object-type-foo <Tag> street { brick }
would cause objects tagged with “foo” to return “brick” for the query nodePath.getTag(‘street’).
But the point is that there’s a huge difference internally between a big monolithic model and a big subdivided model.