I've been rendering a tedious file which seems to decide to switch the main surface texture on just one object to something like digital tie-dye about three quarters of the way through the rendering. I've tried it on more than one machine. This only happens during a long rendering of an animation. I've checked the file at various frames with still renderings with no problems. Wherefore art this anomaly?
|Answer:||When textures have shifting or changes in animation renderings it's usually something to do with a movie file. Here is the dilemma: We allow sequential images to be loaded as movie textures, so if you have a number in the texture name (texture001.jpg for example) the application thinks it's a Sequential Image and loads it as such, thus the texture will shift to the next frame.|
What we've done to help prevent this: The application will go look for the next image in the sequence (texture002.jpg in our example above) if that image doesn't exist in the directory (folder on mac) of the original texture map then it loads the image as an image and not a movie. So if you have another texture that you've labeled with the number following the first textures, that image will suddenly display on your animation rendering because the images are being swapped just like they are in sequential image movies.
Does this clear that up? This may not be the problem, but at least it will help others to avoid the problem. I would also try converting the image to some other format and then reload it into the texture. Try loading it as a pict.
Actually that reminds me of a problem we found with 16 bit picts where they would come out tie dyed like you said. If your using a pict image change it to 32 bit, tiff or something else, 16 bit picts will have a problem when going from one platform to another and this may be related.
- Achieving smooth animation - 2002-04-10
- Flipping Normals - 2002-04-10
- Ripples (Making a flag wave) - 2002-04-10
- Raytracing > Rendering holes in letters - 2002-04-10
- Stencil Map > Rings of Saturn - 2002-04-11
You cannot comment on this entry