CompuServe Messages

#3DS Flic vs NumPic

    13-Dec-94 18:40:25
Fm: NAAUG 73204,3522
To: Brent Bonet 73617,2423
/* 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