#Field rendering
11 messages in this thread
Hi,
I am rendering a long animation with field rendering, in the default field
order of 1.
Some parts of the animation are calculated in reverse order (e.g. from 100 to
1, by -1), just to let computers work "towards each other".
It now turns out that for the sequences that are reversed, the field order is
reversed too, which yields of course terrible animation (because the fields are
appearing in the wrong order, the movements become very jerky).
Is this a known bug or was it meant to be this way (which I doubt very much) ?
In each case, since I don't have time left to recalculate, I now have to solve
this problem by shifting up each wrong frame with 1 line, such that the even
and odd lines fall in the right field, but this gives a visible shift at the
"border frame" between the normal sequence and the reversed sequence.
Does anyone have comments on this matter ?
CU,
Wim Lamotte
What was the logic of having the slave machine(s) render "towards" the master.
I don't get it. Are you using R3 ?
BILL
Bill,
I am using two machines simultaneously but seperately (no network). The one is
a lot faster than the other (Pentium 60 – 32 MB vs. 486-50 – 16 MB).
Therefore, I let them render towards each other.
Wim
WIM,
Are you using command line rendering?
-Brian
Brian,
See my response to Bill's reply.
But just the fact that a reversely calculated animation uses a different field
order seems rather strange to me.
Wim
Wim:
Actually, if you think about it, rendering backwards _should_ have the fields
reversed, as you've noticed! 3DS assumes that you will lay the frames off to
tape backwards, and renders the fields appropriately.
Greg (he's baaaaack!) Pyros
Greg,
I'm not sure if that's true : I actually recorded the animation to video and
the part that was rendered in reverse order, appeared jerky, because of the
wrong field order. This is because e.g. at frame 1, fields 1 and 1.5 are
rendered, but because of the inverse field order, they are put to screen in the
order 1.5 – 1, giving that the animation constantly jumps back and forth. The
field order should be exactly the same when rendering both ways.
If I understand it all correctly, the field order only determines which field
(even or odd) will be displayed first and this is perhaps different for PAL and
NTSC.
Another reason I can come up with for reversing the field order is that one
maybe can render immediately to video in field mode, in reverse order. In this
case, it is only natural that first field 1.5 is renderer and recorded and then
frame 1. But the fields should _still_ be recorded on the right half of the
frame (even or odd). So I guess there has been a mixup between reversing the
field _order_ and reversing the field _position_.
Wim
Wim:
>> So I guess there has been a mixup between reversing the field _order_ and
>> reversing the field _position_.
I don't know what the difference between the two would be! <g> If you are
rendering forwards, what you should get on each frame would be 1+1.5, 2+2.5,
etc. If you are rendering backwards, what you would want would be the same
fields on each frame, but in the order 2.5+2, and 1.5+1, reversed from the
previous order. This would allow you to record the frames backwards without
any jitter.
Make any sense? <g>
Greg Pyros
Wim,
I'm aware of this issue, but it's not really a bug. It's been that way since r2
– it's just the way it is. Anyway, for the least work, I'd just rerender the
reversed portion of the frames. But, I've figured out a fix which may be too
late, but I'll let you know anyway.
You'd use video post to reverse the field order by using a alpha matte of
alternating, 1 pixel high, horizontal black/white lines (easy to create in
animator pro). If you had a 486 line .tga file create 243 pure white (rgb
255,255,255) lines interlaced with 243 black lines (rgb 0,0,0). If using PAL it
would be 576 lines (288 white/288 black). For example:
wwwwwwwww
bbbbbbbbb
wwwwwwwww
bbbbbbbbb
where w=white, b=black and the lines extend the full width (756,720,512 etc,
whatever your .tga file width is). Save the file as filter.gif, or similar.
In video post you'd have 2 entries using .ifl file lists of the offending
frames. The first 1 would need an offset of Y=-1; the second entry would need
Y=1. The first entry's alpha column would be RGB Mask (use filter.gif),
Intensity ON, Blur edges OFF, negative OFF; the second would be the same with
negative ON (to work on the other set of lines). Render and save the files
under another name.
I haven't tested this theory, but it should work, and would be much quicker
than re-rendering a heavy-duty sequence the normal way.
>> but this gives a visible shift at the "border frame" between the normal
sequence and the reversed sequence. <<
This shouldn't happen if the above method works.
Martin
Thanks Martin,
I am going to try this solution and if it works, it will be best to do this
video post always _while_ rendering backwards.
Wim
Wim,
>> I am going to try this solution and if it works, <<
It does work I just tried it last night, and it does work exactly as I
described. Perfect field-reversal.
>> it will be best to do this video post always _while_ rendering backwards. <<
Generally, that wouldn't be necessary. You can reverse the field order for
_only_ the machine that is going to render backwords by changing the
field-order parameter in the 3ds.set file. I've done this before, too.