CompuServe Thread

#video post slowing down

20 messages in this thread
#117556From: Tim c BrananAug 10, 1994 3:55 PM
I ran into a problem last night that strikes me as alittle mysterious. I have a 1200 frame animation that was 512×486. I loaded it under bitmap in video post, witht the option to resize to a custom size of 286×273 to the whole flick. I set it to run at 9:30 last night and it was taking 4 seconds to resize each frame. To my suprise, I came into work today at 1:00 pm to find it still running and taking between 2 and 3 minutes to load the frame. it was at frame 972 when i killed it. It seems to me that this should not happen. The computer is a 90mhz pentium with 64 megs of ram with two scsi 2 hard drives, one is 1 gig, the other 2 gig. The video card is a Matrox MGA with 4 meg of ram. I am running DOS 6.2 and 3DS version 3. Why is this happening? There is plenty of disk space and 3DS was only reporting using 7.7 megs of ram.
#117567From: Ian ChristieAug 10, 1994 4:25 PM
I've had this experience also. The only thing I could think of was that it was a problem of memory fragmentation. Could you work in smaller segments then piece them? Ian.
#117597From: Tim c BrananAug 10, 1994 6:39 PM
I suppose I could try cutting it into pieces, but it doesn't quite seem satisfactory as solutions go. Better than nothing, I guess.
#117579From: Yost GroupAug 10, 1994 4:58 PM
Were you using an IFL to load Targa files, and is your USE-TGA-GAMMA set to yes? If those are both true, you might be looking at the Video Post memory leak problem in R3. Just set USE-TGA-GAMMA to NO and you'll be fine. – G
#117598From: Tim c BrananAug 10, 1994 6:40 PM
Actually it was just a big flc file. I wanted to just shrink it to fit in ram to record on the vcr.
#117609From: Yost GroupAug 10, 1994 7:29 PM
Then the use-tga-gamma memory leak wouldn't be at work here. There are absolutely no other reported memory leaks or performance problems like that. That usually means that it's a system environment problem on your end. As always, if you can identify a 3DS problem, send a reproducible case to Jonas, Nik or Brian. – G
#117653From: Tim c BrananAug 10, 1994 10:47 PM
<<There are absolutely no other reported memory leaks or performance problems like that. That usually means that it's a system environment problem on your end. As always, if you can identify a 3DS problem, send a reproducible case to Jonas, Nik or Brian.>> If it is a system environment problem, whereabout to I look for the problem? Memory managers? Set statements? Other drivers? My config.sys and autoexec.bat aren't a nightmare quite yet, but any pointing you can do in a particular direction might save me a little grief and would be appreciated.
#117675From: Yost GroupAug 11, 1994 1:01 AM
I wish I could help you, but I'm a hardware idiot. – G
#117971From: Jim LammersAug 12, 1994 12:28 PM
>>The problem you are having may be >>that 3DS must read that flic file each >>time from frame 0 to wherever you are. >>Going from 0 every time will add a bit of overhead! Greg is right. I was warned a long time ago that FLICs will go from the start frame to the desired frame for every frame rendered when used as a material or VP entry. On long and/or hi-res FLICs, this can just about stop the job (as you found out with 1200 frames!). As you know, FLICs are delta compressed, so I guess that the program sort of re-builds the image during each new frame by taking it from the top every time. Anyway, the solution is easy. I use a utility to break a flic into all of it's single frames (in one shot), and then use an IFL. If you have the hard drive space (which it sounds like you do) then this is the most elegant and easy way to handle any motion-bitmap. The utility is shareware, it's on the Rendering Plant BBS. Jim
#117996From: Tim c BrananAug 12, 1994 2:21 PM
What might be the number to the rendering plant bbs?
#118067From: Jim LammersAug 13, 1994 1:24 AM
>>What might be the number to the rendering plant bbs?<< It's 816-525-5614. Jim
#118131From: Tim c BrananAug 13, 1994 4:56 PM
>>>What might be the number to the rendering plant bbs? It's 816-525-5614. Jim<<< Thanks, got it.
#118038From: Aug 12, 1994 6:39 PM
Jim: >> Greg is right. A first! Someone please mark this down, time & date included! But don't expect anything else for the rest of the month, I've used up my quota! <g> Greg Pyros
#118068From: Jim LammersAug 13, 1994 1:25 AM
>>I've used up my quota! <g><< Oh, Greg… you're not going to tell us you get 'no respect' around here! Jim
#118112From: Aug 13, 1994 2:10 PM
Jim: >> Oh, Greg… you're not going to tell us you get 'no respect' around here! Around here? Why should 'here' be any different than anywhere else? Greg (asking for it, again) Pyros
#117688From: John TissavaryAug 11, 1994 1:51 AM
I've experienced unusually long image loading times when specifying too many paths in 3ds.set and/or CONFIGURE. Nothing as dramatic as what you describe, though. John Tissavary (LUNA cie, inc)
#117635From: Aug 10, 1994 9:16 PM
Tim: The problem you are having may be that 3DS must read that flic file each time from frame 0 to wherever you are. Going from 0 every time will add a bit of overhead! Try breaking your flic into 100 frame pieces and adding them to different lines in Video Post should solve it. Greg (I've been there before) Pyros
#117654From: Tim c BrananAug 10, 1994 10:50 PM
I will probably end up doing it this way anyway, since 972 frames are already done. I'd like to just set it up and let it go it's merry way all at once (now that I think of it, I suppose I could just have multiple video post entries for each segment), but it is not to be, I guess. Thanks for the tip. By the way, I picked up Inside 3D studio when it first came out, and it has been very useful. Thanks for putting forth the effort.
#117840From: Aug 11, 1994 6:50 PM
Tim: >> I picked up Inside 3D studio when it first came out, and it has been very >> useful. Thanks for putting forth the effort. We're all glad you like it! Greg Pyros
#117655From: Tim c BrananAug 10, 1994 10:53 PM
This is to note that I missed the middle segment of your message (**Try breaking your flic into 100 frame pieces and adding them to different lines in Video Post should solve it.**) and stupidly just echoed your statement back to you without realizing it until 5 seconds after posting it. Brain fry, I guess…