We have a weird issue with using “-flag” in egg-optchar.
We have an object that’s animated with a bunch of subgeometry we want to subtexture. So we’re using the -flag command… a lot. Our command is below… see all the crazy names? That’s because we keep having parts of the geometry refuse to show up in panda. If we change the part’s name in MAYA nad in the optchar command then it might show up… then invariably another part will not be read instead. Any ideas what could be causing this strange issue? Is there a limit to the number of sub geometry a part could have? we’re at a loss…
There aren’t any fixed limits on the number of pieces of geometry you can flag. You can simplify the command line a bit by replacing -flag x=x with simply -flag x (the default is to name it the same as the node).
I’m not sure exactly what you’re describing. You say when you modify the Maya file to rename a node, and also change the reference to the node on the optchar command line, that node will succesfully come through, but some other random node will disappear? That’s strange all right. Do you have a repeatable case of a particular node that is present in the source file, and named with a -flag parameter, that is not exposed in the output file?
Thanks for speedy reply-
We do not have a repeatable case. There are actually about 14 nodes from that list missing from the Panda file. If we keep changing the name we can get some to show up but then others seem to go missing. Our thoughts on possible explanations include some sort of name collision going on or some bug that limits the amount of sub geometry. I can post the .MB or .egg file if there’s interest.
Yes, please post the egg file and the egg-optchar command. (Maybe you should just post a link to it to avoid cluttering up the forum.)
Once a particular node fails, does it continue to fail with repeated executions of the same egg-optchar command, or do you get a random node dropped out each time you run time command?
This problem is solved. And lo, it’s the same problem as the nonsingular error. This time we never got to the part of attempting to play an animation on the model so the nonsingular error was never thrown. However, apparently a 0 scale will stop the egg convertor from recognizing the geometry.
We figured this out by recognizing that it was the pieces which started out scaled down, hidden in the other geometry, that always failed to come through in the egg file. Sure enough, changing scale to .001 fixed the problem.
Ah, excellent. That does sound like a bug in egg-optchar, it should do better than quietly throwing out joints with singular transforms. I’ll take a look at fixing it.