This content has been marked as final. Show 12 replies
have you tried using render to texture on the object before you export. you wouldnt have to be concerned about how it will line up. once its reapplied
Thanks for the response. I am using LightWave's Shockwave exporter and do not see any sort of "render to texture" option in the dialogue boxes. Perhaps I am missing something, or maybe you are using a different 3D application and/or exporter.
By "render to texture" it sounds like you may be referring to texture baking, right? Even if I bake all of my lights, bump, etc. to a new image I still need to worry about how it lines up in Director.
Just so I am clear, when the object is initially brought in to Director it looks fine. The map is lined up on the geometry perfectly. The problem occurs when I try to replace the existing image mapped to the object with a new cast member image. The new image from the cast gets mapped to the object in an odd, inverted-looking way. It may be that the map is getting flipped across an axis, or all of the UV coords are getting multiplied by -1 or something. I am guessing that there is a conflict between the way that LightWave writes UVs and how Director reads them.
it may be a problem with lightwave. I export from max and flip textures that have been baked without a problem from within director. have you tried baking one texture. exporting that and making a copy of it in photoshop and adding adjustments to that texture in photoshop or whatever the editor may be. the placement and dimensions would be the same as the original. only the way it looks would be different
i'm not sure if it makes any difference but you may want to ensure your original texture and the replacement texture the same size, or at least the same proportion (of course powers of two).
The way that LightWave writes the UVs in the .w3d is likely the problem. Why it works on the initial import and then fails later is baffling to me. Someone in the LightWave forums said that flipping the image (prior to importing to the cast, or within Director through scripting) solves the problem.
This problem doesn't require baking to be seen, though; baking really has nothing to do with it. I can reapply the same image that is already on it in the 3d application and the problem occurs- his face gets mapped to his rear end.
all you cant switch the textures if you never instantiate the red texture. redTexture=member(1).newTexture("redMap",#fromcastmember,member("redMap")
then you can switch the texture with
now the problem with your texture coordinates. Well the simple fix might be this:
But you will notice that the belly button is in the wrong place because the problem is that your UV coordinates reflect the image and so rotating the face into position doesnt really fix it. Furthermore if you reapply the original texture it is now off by 90 degrees since it the texture was exported correctly (for the UV coords you specified), why because your UV coordinates are flipped vertically! SO it is a matter of reflecting the image not rotating it. So what you really need to do is either flip the V coordinates in your modelling aplication and reexport or use imaging lingo on the image of the source texturemember before creating its texture something like this:
Thanks for the response, _eyesonly. I will try and apply your advice first thing at work tomorrow.
Instead of flipping the images inside of Director, I have just flipped them in Photoshop before importing them. Worked great.
Also, I don't know if you need to create the redTexture variable that you are talking about, but it certainly may be useful for clarity. I was able to accomplish all of my map swapping using the attached code in 2 scripts, a Behovior and a Movie Script.
you can certainly change the image of the texture the way you are doing but it is creating a memory leak (recursive pointer) and you wouldn't be able to get away with more than one of these going in a scene and if you leave your movie going long enough it will crash eventually. If anything you should use:
which does not create a recursive pointer. But you really dont need to mess with the image of member in yoour case since you arent compositing or blending images, you could simply change the member of the texture and get the same effect.
Also I wouldnt gratuitously apply a meshdeform modifier if you dont need it. In fact even if you use a meshdeform modify to actually retrieve data from the mesh or to change it you still want to remove the modifier afterwards since each modifier in the scene adds a significant drain on resources.
Thank you very much for pointing out the memory leak issue. I am fairly new to scripting and usually don't discover those problems unless someone like you points them out, or I spend hours debugging.
I think I need to use the meshDeform modifier to access animations, right? Your point is well taken though regarding the modifier's removal when not needed.
Thank you very much for your excellent advice, _eyesonly, and to everyone else that has lent a hand in this.