#Field Rendering
18 messages in this thread
I've heard a lot about field rendering and how it makes animation
look smoother, but can anybody explain to me exactly what's going on
when you render to fields. I understand that an animation is rendered
at 60 fields per second, where half the lines are rendered per
frame. But how does this translate to video scan lines? I render at
640 x 480. NTSC is 525 lines, isn't it? What's the connection? How
does 480 lines of pixels translate to 525 lines of video signal?
Shouldn't we all be rendering at 640 x 525? This has always confused
me.
Glen, Actually I don't know about the 525 lines vs. 486 lines. Someone
else will have to answer that one. But, per the CCIR 601 standard for
digital video the resolution is 720×486, it is also 486 lines with
most frame buffers such as the Targa+ and the Vista, Max etc. Anyway,
field rendering produces better results because of the fact that all
NTSC devices are interlaced. Interlacing refers to the fact that each
frame is composed of two sets of scan lines, one odd and one even.
The electron gun in the TV first draws the odd set of scan lines in
1/60th of a sec. and then goes back and draws the even lines
producing 30 frames per sec or 60 fields per sec. If your animation
is _frame_ rendered then on every frame both _fields_ will be the
same producing a 30 frame per second animation. If your animation, on
the other hand, is _field_ rendered then each field will be slightly
different resulting in basically a 60 frame per second animation –
much smoother, especially noticeable on both fast objects and objects
traveling horizontally ascross the screen. On some animations you
can't even tell the difference and on others it's easily apparent. If
you're going to video you should really always field render, it does
take slightly longer but it's not twice as long, and it's worth it. If
you have the chance you should do some tests and see for yourself.
I've been wondering what's going to happen when HDTV becomes the
standard. Since it is a non-interlaced format I wonder if the frame
reate will be changed. Because really, interlacing makes the
animation more smooth than if it were not interlaced. So while
interlacing is bad for a computer display where nothing is changing
too quickly, it's good for a system where motion is prevalent.
DM
Yeah, but you see, this is where I get confused! Even and odd scan lines.
You're talking video now. How does video translate from rows of computer
pixels?
I've got a program called Producer by AXA. It's an ink & paint
2-D animation program, but it has a 24 fps to 30 fps converter when
transferring to video. It uses mixing of fields to stretch every 4
frames to 5 (thus 24 frames to 30), but it's in the transfer stage
that the stretching ocurs! The field-mixed frames aren't saved to
disk that way. They jitter wildly when viewed singly, but played back
at 30 fps they're invisible. The field splitting and combining is
strictly a VIDEO thing. How can rendering half the resolution at 60
fps do the same thing?
Glenn, Ok, Yeah it took me quite a while to really comprehend fields
also. The reason a field rendered image flickers when viewed as a
still image on an NTSC monitor is because the monitor is interlaced.
The jittering is that one pixel wide line turning on and off 60 times
per second. You can create a one pixel wide line in Animator Pro,
Photoshop or whatever and if you send it over to your TV or video
monitor it will flicker. If you make it two pixels wide the flicker
will be gone. If you look at a field rendered image on your computer
monitor you will see the field seperation. It's most apparent at the
edges of moving objects where the change/field is greatest. When you
tell 3DS to render to fields it actually does the rendering twice per
frame and combines the two fields. You could not take a flic for
instance into video post and have it rendered to fields as it needs
the geometry. The images can be converted into video with something
like a Targa board, a PAR, MAX etc. Or even a VGA -> NTSC converter
although the quality won't be as good. Hope this helps.
DM
This is what I mean about not being able to get a straight answer on fields
and pixels! You've got 525 lines of video, right? You've got 480 lines of
pixels, 640 pixels wide, right? HOW DO YOU FIT 480 LINES INTO 525??? Field
rendering renders every other line, right? Or am I wrong on that?
Is it true that 2 fields rendered separately will NOT flicker when combined
using 3DStudio? However if they're combined on tape they WILL flicker?
I'm so confused!
Glen, As someone else pointed out to you the extra lines are used for
the vertical retrace. I'm not an engineer, and can offer no more on
that issue. Actually it is 486 lines vertically. Horizontally really
doesn't matter it can be anything from 512 – 752 or even higher using
a Vista or something. Yes, field rendering renders every other line.
But the two fields are always combined to make one frame. There are
always two fields in a video signal. If you render to frames instead
of fields then those two fields are just the same. Your NTSC device
displays the first 243 lines in 1/60 of a sec. then goes back and
displays the other 243 lines. That's why if the images being displayed
have field info. (rendering to fields) the output appears smoother. I
don't exactly follow your question about rendering two fields
seperately, they are always combined. The only difference is where
you view a field rendered image. A still on a TV will flicker and it
won't on your computer monitor.
So if animation is rendered at 640 x 486 on fields, meaning a 90 frame
sequence would actually be a 180 FIELD animation, and then it's transferred to
NTSC video, the transfer will automatically divide the 2-field frame into
separate fields. Does that sound right? But you HAVE to render at 486 lines
vertically or the field transfer won't work, right?
Thanks for your patience and thorough explanations! I've always wanted to
try rendering on fields, but a few years ago when I tried it using Wavefront
software The results were totally messed up, for reasons, I assume, other than
what we're talking about here!
I'll do some experimenting!
Glenn, There's not actually a step that _divides_ a frame into fields. Your TV
just does this automatically when it projects an image. The fact that every
other line is drawn is hardware dependent on the device. What you are doing
when rendering to fields is _taking advantage_ of the fact that TV is crappy
and interlaced and making your images look even better than they otherwise
would. A frame of video is a frame of video. It _always_ contains two fields.
Whether or not you take advantage of this is up to you. You don't have to
render to 486 lines. The PAR, for instance requires a 752×480 image. It still
outputs a valid NTSC signal though, it takes care of all of that internally.
Basically, though, the PAR is not a legal NTSC device though that issue would
only come up for someone like Jim Murphy. Inside joke. Let me know if you still
don't fully understand, though I think I've exhausted my knowldege on fields.
Take care.
DM
Yeah, that's what I meant by divide the fields: it's an automatic tv-thing!
I'll give it a try.
Glenn,
To see the visual effect of what a field rendered image looks like, just render
out to fields, (not frames), a single frame of something like a light ball
moving fast across a dark background. (Frame 1 of a 15 frame animation where
the ball moves pretty well.) What you will see is that every other line is
shifted halfway towards where it would be in the next frame. The end result is
that when viewed on an interlaced monitor, such as a TV, the first pass, which
takes 1/60 second, gets all the odd numbered lines, and the second pass, which
takes another 1/60 of a second, gets all the even lines. Since these even lines
are halfway to where the next frame starts, it gives a smoother motion when
viewed *on an interlaced screen*, such as a TV). If it were *frame* rendered,
both odd and even lines would basically be in the same place, so the movement
to the next 1/30 second would be "farther, resulting in jerkier motion when
viewed on an interlaced TV monitor. Now if you just hold this same image
*still* on an interlaced monitor, it will look like it is flickering, as every
1/60 second it is switching between the position of the odd lines and the even
lines, which are susally slightly offset from each other, depending on the
motion involved in your scenes.
Just render two sample images like I mentioned, using fields on one and frames
on the other; and compare the two; hopefully it will make things a little
clearer. Just assume that a field rendered frame will be sent to an interlaced
monitor in 2 passes, with the first pass showing the odd lines and the second
pass getting even lines, and don't worry about how many lines the TV monitor
has; it always appears to work out.
John
So animation rendered on fields will not produce single images that don't
either flicker or look like 2 images overlapped, right? The full effect is
only visible when the tape is running at 30 fps.
Thanks for the info! I'll definitely do some test renderings & see what
happens. I've had problems in the past with strobing that might have been
correctible using fields, but I never took a stab at it.
>> So animation rendered on fields will not produce single images that
>> don't either flicker or look like 2 images overlapped, right? The
>> full effect is only visible when the tape is running at 30 fps.
Glenn, PMJI, if your image is not moving then there will be no field seperation
and hence your image will be stable, even if viewed as a still.
DM
Yeah, but if you need a "dynamic" frame of animation, say, to impress a
client or to go into print material, a field-rendered frame wouldn't look
right. You'd have to render that special.
The problem I had with Wavefront was that I was rendering at 648 X 486, but
to output to a CRV laserdisk I had to blow the image up to full-screen, which
was 1024 by 1280. Wavefront renders the fields as separate images that you
combine as a separate step. This didn't work at all.
Glenn, True, you would not want to display a a field rendered image as a still.
I'm glad you're getting all of this though.
DM
Glenn,
>> So animation rendered on fields will not produce single images that don't
either flicker or look like 2 images overlapped, right? The full effect is
only visible when the tape is running at 30 fps.
You got it, basically. There are still a few little things to look out for when
rendering with video output in mind, and *still* frames rendered to fields
usually work O.K., since there's no movement ,but you're pretty much on your
way now.
John
Glenn,
Cool down man !
Don't let yourself confuse by technical details.
Simply don't render to 640×480 but to 712×525 (thats for PAL, since I'm from
Germany, you should easily get NTSC values if they are not the same)
Then render to fields, that does the interlace stuff and put it out.
If you want to comprehend the magic behind it, better go to your local library
and lend a book on it, it's quite complicated and probably not explicable in a
few message lines.
For putting 480 to 525 lines, well, how does Animator scale pics *up* ?
It's a weird bunch of mathematics and approximation and dithering and so on.
And, for my part, I don't want to know HOW it works, but THAT it works.
Good luck
Michael
I'm not really curious about the nuts & bolts of how it works, as long as it
DOES work! I've got some experimenting to do now!
I think my questions have been answered, I've just got to try it & see.
Thanks for the input!
I believe the extra 38-45 lines go to the time called 'vertical retrace', in
other words, the time it physically takes the beam to go back to the upper
left. This would happen once per field, twice per frame.
You can see this portion of the 525 lines by adjusting your 'horizontal hold',
so you can see the (mostly) blank area separating frames roll by.
Bri