Exporting Textures: UVHelper vs. PolygonMesh.uv_at
-
Hi all,
I'm having a problem exporting textures from models. It may or may not be related to the problem described by Tomasz in the "Material with coloured or distorted texture" thread, but I didn't know what a "distorted texture" is. (And in any event, I didn't see an answer that would help.) I'll try to summarise the problem, 'cause the whole story is a bit long. If I'm skipping too many details, I can try to supply more later.
Essentially, I'm trying to export all the geometry of a model, including texturing information, and store it in an XML-like file format. I originally wrote the script in January. Most of the testing used the SketchUp Warehouse's Western Canadian Place model (a.k.a. "the Husky Towers") in Calgary (Warehouse --> Cities --> North America --> Calgary --> Western Canadian Place). The Texture-related part of the algorithm used the uv_at method in PolygonMesh. (The PolygonMesh's are generated using Face.mesh.) (PolygonMesh's were used for a couple of reasons.) This approached worked perfectly fine for Husky.
I recently started more rigourous testing on the script, and found that there's a whole subclass of models that the script actually fails on. The Capitoline Hill Warehouse model (Warehouse --> Featured Google Earth Collections --> Ancient Rome --> Capitoline Hill, Capitoline Museums [...]) is an excellent example of this. Essentially, the Texture mapping is wrong. I figured, "Hmm. This must be what that UVHelper class is about." (One of the reasons why I didn't use UVHelper in the initial version was that I simply didn't understand it at the time.) I re-worked that part of the script, and the Capitoline Hill model exported perfectly. "Good guess!" I proudly thought to myself.
As a sanity-check, I ran this new, UVHelper-based algorithm on the Husky model. To my dismay, export fails on /this/ model. Most Textures are indeed mapped correctly, but a couple of them (like the terrain, and the front face of the small tower) get "shifted" by about a quarter of the Texture's width.
I'm at a bit of an impasse right now. I can't seem to identify any meaningful different between the Capitoline Hill model and the Husky model. In particular, both are "complicated" models, with several levels of nested Groups/Components. The Groups shouldn't be the problem, 'cause I've already figured out how to handle them. What /does/ seem to be the problem (although this is only a guess) is that the Capitoline Textures were "Tweaked"(?) (is that the right word?) with the "Texture Pins"(?) (my vocabulary is failing badly now), whereas the Husky Textures were all very simple ("square") applications. This is just a guess though. Even if this is indeed the problem though, I don't know to detect whether or not a Texture has been applied using the pins.
Any input would be greatly appreciated!
K.
Edit: Actually, I just realised that the description I wrote above is slightly incorrect, albeit in an important way. If you run the export script on an unedited version of Husky, both versions of the script (UVHelper-based and uv_at-based) actually work fine. The one that's failing is actually a version that I've edited. I'm not sure why editing the model would affect anything (I didn't manipulate the textures -- only the geometry changed), but at least I sorta have an avenue to explore, I guess.
In any event, I know all the missing information makes this question a little tricky to address. On the outside change that anyone can think of something of the top of their head, I'd still very much appreciate it. Alternatively, if I end up solving it myself, I'll post a reply here letter people know what the problem was (in case anyone runs into a similar problem in the future).
-
Blah. What a dumb problem.
So, despite my assertion to the contrary, the problem seems to have been exactly that I wasn't correctly dealing with Groups/Components after all. The problem only seems to manifest itself if the geometry is located in a nested group -- top-level groups didn't seem to have this problem. It's probably related to the admittedly very messy way in which I apply the transformations and inverse transformations to export the geometry in the right place.
Anyway, sorry for wasting everyone's time with a dumb problem. If nothing else, perhaps this post can serve as a warning: Never trust a Group!
K.
-
@unknownuser said:
Never trust a Group!
Oh YES !!!
Group is the bastard son of component definition x entity -
Ditto that.
-
@kevd said:
The problem only seems to manifest itself if the geometry is located in a nested group -- top-level groups didn't seem to have this problem. It's probably related to the admittedly very messy way in which I apply the transformations and inverse transformations to export the geometry in the right place.
Hi Kevin,
I am an author of SU2KT exporter. I have faced same problems as you have had. I've got still several test models where photo-matched textures are not exported correctly. Can you try them with your routine?
Could you describe in detail what was actually wrong with applying inverse transformations to export the geometry? Mine has been inherited from Ogre exporter and it is messy indeed
Frankly speaking my routine still doesn't export photo matched textures inside nested geometry
Thanks
Tomasz
Advertisement