Multitexturing, Maya... questions

Does anyone know what these rules were?

Bamming doesn’t seem to be forward compatible… I tried to bam a 1.5.2 egg file in 1.4.2 and ended up with a bunch of glitches. I have a copy of the 1.4.2 manual, but there are no indications in there about how to properly set-up multi-texturing in Maya in order to properly export the data to egg.

We’re considering migrating to 1.5.2, but a lot of code has been written, and we aren’t yet sure how much effort that will take.

No rule has changed. My script works well since 1.3 - 1.5.1

Uh… I can’t seem to get it to work using the Panda 1.4.2 maya2egg7 and maya2egg85 exporters, on any machine we’re using, using either the procedure specified in the 1.5.2 manual, or the one ynjh_jo laid out here.

Works fine on all our Panda 1.5.2 exporters though… same procedures and everything.

ynjh_jo, if Panda 1.4.2 works fine for you, do you have any idea what we might be doing wrong? Or what direction we might take as an alternative?

Why don’t you just use 1.5.2 ?
Do you have multiple Panda versions installed ?
If you still want 1.4.2, just use 1.5.2’s maya2egg. Nothing is stopping you from doing that.

If you’re not running maya2egg by hand (i.e. using the GUI) :

  1. add your 1.5.2’s /bin to your PATH, be sure it’s after 1.4.2 path, to give 1.4.2 executables higher priority
  2. rename your 1.4.2’s maya2egg, so the 1.5.2’s will be used instead
    It should work, I hope the invoked 1.5.2 maya2egg will use 1.5.2’s libraries instead of the 1.4.2’s, since the working directory is usually set to the executable’s path.
    Read this : discourse.panda3d.org/viewtopic.php?t=4328

We have several months worth of code in 1.4.2. The people paying our wages would prefer not to take the time to port the code to 1.5.2. Since our project is a networking app, and we’ve already released 1.4.2 clients, so we’re also worried about compatibility if we switch to a 1.5.2 server. We’re keeping this option open though.

On the artist machine? Yeah, why?

This is what we’re currently doing. Produce a 1.5.2 EGG, then BAM it to 1.4.2. When we loaded the files in our 1.4.2 app, there were several glitches that we couldn’t fix. We’re presuming changes have been made between 1.4.2 and 1.5.2 to EGG that prevent us from loading a 1.5.2 EGG/BAM properly in 1.4.2. EGGs aren’t completely forward compatible.

Right. Eggs that use the new shader generator features (which have been introduced in Panda 1.5.0) won’t work (completely) with older versions.

v1.5.2’s egg can’t be used by 1.4.2 ? It could be related to the new shader system. Have you tried using an older version ? try 1.3.2

The file loads, but some of the data we used to be able to access from the egg file are suddenly no longer there.

Particularly, there’s a quad in the egg model that represents a screen in the level that we want to get at run-time and set a texture to. We used to be able to do this with a 1.4.2 model using find(name). With the new egg, we can still use find name, but the returned nodepath has 0 nodes (np.getNumNodes() == 0). The screen itself is still visible, we just can’t get an np handle to it.

Not all that major a problem in itself, but the danger there is that future models that will run through this procedure (1.5.2 egg → 1.4.2 bam) might also contain errors, or might look different during run-time.

Actually, I’m starting to think its possible this isn’t a Panda problem at all, and that the artist screwed up somewhere accidentally.

I tried running our code in 1.5.2’s ppython, after uninstalling 1.4.2, and there were a couple unexpected surprises there:

  1. The code ran perfectly. Granted, we weren’t expecting too much trouble, but usually something changes, no matter how small. But no, everything ran without a hitch.

  2. The resources were loaded without any problems. All our bam files and txo files… I didn’t even have to re-bam our eggs. And here I thought bam files were supposed to be version dependent, and that we couldn’t just use the same bams everytime Panda got updated.

  3. The same problems cropped up when I loaded the 1.5.2 egg file the artist gave me.

What is .ls() result look like ?
Does the quad exist in the egg ?
Try to tag it with in Maya.

Does calling setShaderAuto() on your models (or better, on render) fix anything? That enables the latest Shader Generator functions that were introduced in Panda 1.5.0.

If that works, you can also take the next step by manually enabling auto-shaders in the .egg file.

Okay, I figured it out. The artists were exporting the level as an actor using the Panda exporter… which gives the exporter leeway to throw away any geoms it thinks we won’t end up needing.

Sorry for the wild goose chase everyone… Thanks for all the assistance. Much appreciated.