xxxToEgg Problems

My first post … Let me first say that I hope to be a frequent contributor on this board. I am new to Panda3D and Python but so far I am excited as the Panda3D engine appears to be incredibly powerful.

I am experiencing a problem with maintaining the proper texture coordinates of 3D models whenever I convert them from VRML/LWO to EGG format using vrmltoegg and lwotoegg. This does not happen for all textured models, it is intermittent. I believe that it is only happening for those models where all of the textures are squeezed onto a single image.

My procedure for converting models is as follows:
Load model into Deep Exploration
Save as VRML2 or LWO
Convert the saved file with vrml2egg or lwo2egg

Note that I am using deep exploration to convert the original models from other formats. I have however, rendered these models without a problem with my own OpenGL 3DS model loader/renderer so I know that the problem IS NOT Deep Exploration.

[color=red]Has anyone else seen this problem?
Has anyone found a solution to this problem?

Thanks in advance,

Here is an example:

Original Image rendered in Deep Exploration

Converted Image rendered in Panda

Hmm, I’ve never seen or heard of that problem before. Are you sure that the DeepExploration program is correctly writing the VRML/LWO files? You could prove this by re-importing (back into DeepExploration) the VRML/LWO file after you write it out. It might also be worthwhile trying to import the file into some program other than DeepExploration (and other than Panda), for instance, any VRML viewer you can find on the net.

I suspect DeepExploration, rather than Panda, because you say the same problem happens on both VRML format and LWO format–but vrml2egg and lwo2egg are two completely different programs, so it would be very strange if they both produced exactly the same error. It’s not impossible, of course, but it seems unlikely.


"Are you sure that the DeepExploration program is correctly writing the VRML/LWO files? You could prove this by re-importing (back into DeepExploration) the VRML/LWO file after you write it out. "

I did that … wrote them out then read them back in again … no problem. I also used a different program to read them, my own 3DS loader/renderer using the models imported with DE from the exported VRML/LWO files. This worked fine also. All indications are that the problem is not Deep Exploration.

It seems likely to me that vrml2egg and lwo2egg could exhibit the same problem if their EGG format writer is in a package/library used by both applications.

Have you tried importing models with all textures embedded in a single image?


Just out of curiosity, what’s the original file format?

I have tried it with 3DS, OBJ, and FLT formats.

Right, this is so; in fact, there is quite a bit of shared code between both programs, handling the actual generation of egg files. But this appears to be a problem with the content of the egg files, that is, the assignment of the UV’s to vertices; and that code is unique to each program. Furthermore, if there were a problem such as this with the egg library, I would expect it to be quite widespread and I’d expect to have heard about it sooner. Still, I can’t rule it out altogether.

Do you mean, lots of textures mosaicked together into one image, with the model UV’s adjusted to match? We do that all the time; in fact, Panda ships with a tool called egg-palettize to perform this operation. But I’m not sure that it’s qualitatively different from the ordinary multiple texture case.

Unless it happens that Deep Exploration is performing this UV adjustment by using some obscure feature of both LWO and VRML syntax–so that, rather than adjusting the UV’s directly on the vertices, it leaves the UV’s at their original values, and then writes some additional notation that means “scale the UV’s on these vertices by this amount and transform them to this position”. If this is the case, and neither lwo2egg nor vrml2egg understand this obscure syntax, than you might end up with the problem you describe.

Can you post one of the sample VRML files somewhere where I can download it, so I can inspect it?


Yes, that is what I mean.

I will post the model in question and PM you the addresses in just a moment. … Thx

Model address PM’d to you

OK, it is as I guessed. If you look at the VRML file, you see syntax like this:

          textureTransform TextureTransform{
            translation 0 0
            scale 1 -1

This syntax appears to be saying “take all the UV’s that reference this texture, and invert the V value.”

I’ve never heard of this VRML syntax before, or encountered any other VRML file which used it, but it does appear to be a legitimate, defined VRML syntax, and so it is a bug that vrml2egg doesn’t respect it. Presumably there’s a similar obscure syntax in LWO that lwo2egg doesn’t know anything about either.

I’ve just checked in a fix to vrml2egg to support this syntax (it was easy to add). Since I don’t have a wide variety of VRML files that demonstrate the syntax, it’s difficult to be sure that I correctly intrepreted the meaning of the values, but it works in the case of the model you sent me, at least.

The next release of Panda should probably include this fix. In the meantime, you might look closely at the options to Deep Exploration to see if you can figure out what triggers the use of this whacky syntax, and if there is any way to disable it.


Wow thanks! I am looking into DE now to see what I can find.

Thanks again,

I find no such options.

Just for fun tho, in the VRML file I changed this:

          textureTransform TextureTransform{
            translation 0 0
            scale 1 -1

To This:

          textureTransform TextureTransform{
            translation 0 0
            scale 1 1

Then I viewed it in DE and guess what … it appeared exactly as the Panda3D version did … flipped textures.

Just for more fun I googled TextureTransform and VRML97 and found that it is indeed part of the VRML format (v1.0 I believe is VRML97).

See … h3-349.htm

If you wish, I can send a bunch of models that use this syntax. Just PM me and I’ll do it …

Thanks again …

I’m getting ready to release panda 1.2.2, which is a trivial bugfix release. It fixes this one bug and also one other bug, which occurs when you have a bad fmod DLL in your windows directory.

Wow, you guys are great, quick too.

BTW: Will SceneEditor be working in this next release?


No scene editor. The scene editor problems are part of a bigger problem: panda uses “import *” too much. That, combined with the fact that panda contains modules that have the same name as panda classes, tends to lead to a lot of namespace collisions.

The import statements in the scene editor have stopped working. I could spend an hour sorting it out, but it would be the third or fourth time I’ve had to sort it out. In fact, with almost every release, I have to sort out the import statements in some program or other. I’m tired of it. So instead, we’re developing a permanent solution.

What makes it particularly tricky is that we have hundreds of modules and literally a thousand uses of “import *”. So whatever it is we do, it better be almost completely automatic.

I have a demo coming up the first or second week of june and sure could use the model texture fix. I have version 1.2.2 installed and it doesn’t fix the problem. Will the release with this fix be available any time soon?

It doesn’t? That’s funny, it certainly should.


move :wink:

Regards, Bigfoot29

As near as I can tell, the 1.2.2 version does indeed include the fix to the VRML importer (I didn’t fix the LWO importer yet). I don’t have your sample models any more, so I can’t verify this end-to-end. What behavior are you getting when you try to import your models? Are you sure you have uninstalled the previous version(s) of Panda?


My bad, it does work. I had put vrmltoegg from the previous version into my common tools path.

Thanks for the help again,