CompuServe Thread

Here's a guess (don't have the time to test it out). When you create your animation by outputting separate 24-bit TGA images, each image has a different random dithering, whereas in flic output the dithering is controlled for the flic in such a way that you don't get "dither-crawl" during playback. As a result, the deltas for a flic generated directly from 3DS are much smaller than those in a flic that's been converted from a series of TGA's. In the converted flic, because of the dithering, probably every pixel changes in every frame — resulting in a gigantic flic. – Jack

/* I'm saving in TGA then I use Hijaak to convert to 8 bit BMPs. I then use numpic to import and a use one palette to apply the same palette to all frames. The idea is that when I get close to a final product, to render and create a flic. If it's what the client wants I can then just record to CRV without having to re-render the file that I just spent 10 hours rendering! Thanks, Brent Bonet – POP! Multimedia Atlanta */ Welp, there's only so many things that can cause this. My guess Brent would be that by using individual TGAs, no "squeezing" is being done on the "near colors" between adjacent frames. Consequently, each frame is "on it's own", nothing to offer in repetition for the next frame. I tried a few things last night to verify this… I rendered out to individual TGAs in 3DS, then used NUMPIC on them to build a flic. I also generated a flic rendering out to an FLC from 3DS. I got the same results. NUMPIC is simply building a frame-by-frame flic by appending each new frame's palette and pixel values to the last treated frame. It isn't optimizing as it goes along appending. The TGA's palettes are so huge that the likelihood of two frames having the same exact color values is practically nil if cameras and lights are in motion. It's only after the entire flic has been constructed from the radically different individual images that palette optimization functions can be applied to it and you'll start to get some repeating palette values between adjacent frames. If you want individual frames, why not generate the flic using High Palette mode in 3DS and then use NUMPIC to bust it up into individual frames (images) quickly rather than re-rendering? Am I missing something here? <g> -dave

Hi! Why do this in Ani Pro (a fine product goodness knows). Just stuff a list of TGA file names in an ASCII text file. Put the TGA Files and the text file (which should have the extension .IFL (mytgas.IFL)) in a directory in your map paths (C:\3DS4\MAPS). Then select Renderer/video Post from the Keyframer. Enter the total number of frames you want to combine in the field next to the word SET at the top of the screen. Then select SET to create that number of frames. Select Add and click in area under the word QUEUE. Select the edit button. Click on the [KF SCENE] entry. Select the bitmap button and then identify your IFL file. Then exit back to the Video Post main dialog box. And select the Render button. This will convert all your TGA's to a FLIC inside 3DS (and will generate a single pallete as a by product. Furthermore – you can also convert all your TGA's into BMPs Gifs or any other 3DS supported format using the same technique – just select the Configure button in the Rendering dialog box to specify the output file. Learning this much video post takes less than half an hour and will save you hundreds of hours of rendering time. (Not that I don't love Ani Pro – I use it all the time to create custom pallets….) Seriously, its worth the hassle. At any rate – Sorry to butt in but I thought you might like to know about this solution if you didn't already which you might. Its certainly easier than HiJack Meets AniPro. Cool, Nancy Fulton (PS: You can also select that HIGH pallette option which should help reduce screen crawl if such a thing is really caused by a screwed up pallett rather than just a sincere limitation caused by having only 256 colors to work with).