#MAGIC4 fieldrend prob?
6 messages in this thread
I have used MAGIC4 from Digimation on a project. Everything works ok when
testrendering in frame mode. When then trying to make the final rendering
fieldrenderd the "magic" comes totaly off key!! It seams slower!?
Has anybody else had this problem!?
regards, Martin Enthed
It is my understanding that Magic is NOT field render capable. You should
check into Sisyphus Particle Systems. All are field render capable.
Lee
We've run into that problem as well. Apparently, MAGIC4 uses the wrong value
from 3DS as its "current frame" counter, using instead a "current FIELD"
counter.
A possible workaround might entail enabling FIELD-NO-DOUBLE in 3DS.SET (r"4"
only), but that's a pain when you have several network slaves and only want to
do it for a few projects, as it means bringing down all the slaves and bringing
them back up with the appropriate SET= parameter on the command line — tedious
indeed when you normally don't even have keyboards and monitors connected to the
slaves! Also, FIELD-NO-DOUBLE has its own problem (notably, it does not work
with .IFL files the way it should).
A better workaround is the one someone suggested to the .IFL problem
mentioned above. It does what FIELD-NO-DOUBLE _should_ do, and it works with r3
as well as r"4." You need to create a B&W bitmap file in any format 3DS accepts
(.GIF, .TIF, or RLE-compressed .BMP recommended, .TGA and .JPG will work but
those are wasteful of disk space in this case) that consists solely of
alternate black and white scan lines going all the way across the screen. All
odd-numbered lines should be white, and all even-numbered ones should be black.
It should be the size you usually render to (756×486 if you render to a PAR or
VISTA, for instance). If you use several different horizontal resolutions but
only one vertical resolution you can make only one and allow 3DS to scale it,
but that will slow this down a bit. You only need to make this file once. Call
it "ODDFIELD.???" where ".???" is the appropriate extension for the bitmap file
type.
Now Time/Scale your animation to 2x its designed size, or design it around
60fps instead of 30fps from the beginning. Set up a Video Post queue to use a
length of [Use KF] + 1 (e.g. if your original animation was 5 seconds long and
thus 150 frames at 30fps, and you Time/Scaled it to 300 frames, your Video Post
queue must be 301 frames long).
Set up two lines in your queue as follows (here assuming 20 frames):
Queue Alpha Trans 0 10 20
[KF Scene] ODDFIELD.??? *—————-*
[KF Scene] ODDFIELD.??? *—————-*
The Alpha box for ODDFIELD.??? should be set to [Queue RGB] with Opacity
Threshhold of [255] on both, and have the Modifiers [Negative] button set on
ONE of them (which one depends on the proper setting of FIELD-ORDER for your
video equipment — use trial-and-error to determine the proper value).
Now Render from Video Post, All frames, with Render Nth Frame set to [2]!
Voila! Field-rendering done RIGHT with one KF frame per field, no
interpolation, .IFLs handled correctly (one per field, not one per frame), and
MAGIC4.APX should also handle it correctly since we're now dealing with one
field per KF Frame, not two.
M&Ms:
>> It should be the size you usually render to (756×486 if you render
>> to a PAR or VISTA, for instance).
FYI, you are correct with the AT-Vista at 756×486, but the PAR is 752×480.
Greg Pyros
That may be, but I was also incorrect with the whole Video Post idea. It
won't work. At all. Period. Why not? Because you can't apply either Alpha
or a Transition (which also would've worked by using the same scanline-masking
bitmap) to a "[KF Scene]" (or an .IXP Process for that matter). The only way
to make it work is to render the whole thing twice, once at Every 2nd Frame
with a Range starting at 1 (not 0), and again using the Video Post but bringing
in the previous render as a series of numbered bitmaps with the scanmask
applied as Alpha or Trans.
I'd never actually tried it until after posting my previous message 'cuz we
have software that will process frames and fields for us so why bother with
Video Post? (The software in question is Equilibrium's DeBabelizer, which we
have to use anyway to convert animations to QuickTime for importation into the
ImMix TurboCube, seeing as the QuickTime Movie Maker .IXP IPAS we tried from
Animetix just doesn't work reliably for us. And, of course, Animator Studio
will not write out QuickTime movies reliably either. Neither will CorelMOVE.
Apparently nothing on the PC can, which indicates that the bug may well be in
Apple's QuickTime for Windows export routines that all these applications must
use.)
— Joel Ellis Rea @ M&M Communications Concepts.
Joel:
Yes, you have to have the pre-rendered images for VP to do the compositing to
fields, so you will need a bit of extra disk space!
Greg Pyros