Start a new topic

mgUpdateTextureMapping

Original Post by: IanCheung Mon Jul 13 14:20:39 2009


Hi all


I am applying lots of different textures and 3 point texture mappings to many different objects in an FLT. Sofar the different jpgs are applied, but the texture mappings are incorrect. Looking at the file in Creator, the texture mapping palette contains many many instances of the first mapping. There are no other mappings in the texture palette. Oh, and the first object's mapping is correct - it seems that mapping is used for all the other objects. Even though I'm creating unique mappings and storing them in a list temporarily.


I think my problem is that mgUpdateTextureMapping fails. I call it after having done a mgSetAttList which applies a new jpg and the new texture mapping. I am unable to find out any more info on why it's failing, does anyone here have any ideas? I may be doing something completely silly as well, am still quite new to the Openflight API


Also, the specific part of my script is buried inside nested functions and loops so it's difficult to copy and paste my code. If necessary I can extract specific bits though and post it here


Thanks in advance for any help,


Ian


Original Post by: IanCheung Mon Jul 13 15:55:30 2009


Hmm ok - I went back to one the sample scripts provided in the Openflight API directory, egtexturemapping.py, found the line


ok = mgUpdateTextureMapping (textureMapping3Point)


and added a test afterwards:


ok = mgUpdateTextureMapping (textureMapping3Point)

if ok == MG_FALSE:

print 'Error updating mapping palette'


The Openflight API Reference states:


mgUpdateTextureMapping() returns MG_TRUE if successful, and MG_FALSE if not.


However when I run the sample script, mgUpdateTextureMapping returns MG_FALSE - even though the script does create the FLT and different types of texture mappings. Am I missing something here?


Ian

Original Post by: ChrisRogers Mon Jul 13 16:55:32 2009


I ran some tests and verified that the mgUpdateTextureMapping function does indeed always return MG_FALSE. A quick glance at the code confirmed this to be the case. I will log this as a bug.


However, I could not reproduce your original problem. My texture mapping entries all look and behave correctly. Can you post a snippet of your script that exhibits the problem?


Thanks.

Original Post by: IanCheung Tue Jul 14 08:41:32 2009


:D I was getting quite frustrated - and as I am still new to Python as well as OF API I was pretty sure I was doing something silly.


Glad you had the same result with mgUpdateTextureMapping - and I was starting to realise yesterday evening that some of my other code isn't quite right, so I am almost certain that my problem is down to sloppy coding. It's also difficult to post my code because at the moment it's embedded in quite a large script, bits of it here and there. Also, I haven't been able to pinpoint exactly where the problem is - up until yesterday I thought it was mgUpdateTextureMapping so...


If/when I find the buggy lines of code I'll post it here, it'll probably end up being something silly/highly embaressing :)


Thanks for the help


Ian

Original Post by: IanCheung Tue Jul 14 11:39:00 2009


:(


The problem was mgSetAttList - I was passing the texture mapping palette entry as the fltPolyTexmap value instead of the texture mapping index.


I was using the index before but as I was changing between variables and lists and passing stuff as function parameters, I must have had my eyes shut or something... I had spotted previously that it had to be the index and checked it several times as well. At that point I'm guessing I had a different problem in the script.


Oh well. All sorted now. Thanks again for clearing up the mgUpdateTextureMapping bug


Ian

Original Post by: ChrisRogers Tue Jul 14 14:19:42 2009


No problem. I'm glad you figured the problem out.


By the way, you never need to be embarrassed about your scripts. The fact is, scripting is a challenging task to accomplish. This is mainly due to small mistakes that are very easy to make and very hard to find once they are made. Scripting and programming in general very much suffer from the same challenges that plagues anyone that writes in any capacity. When you read your own writing, you read what you meant to write, not what you actually wrote. A fresh pair of eyes is often all that is needed to spot problems that would often take days to find alone.

Login to post a comment