#Field vs. Frame
48 messages in this thread
Nop. You are all set for "field" rendering as it is up to 3DS to render the the
fields separately. 3DS will basically render the scene twice. The first time
around it will generate just, say, the odd fields. It will then calculate the
"tween" for the second field (1/60 of a second later) and render the, say, even
fields. The best way to understand this is (thanks to Greg) create a scene in
the keyframer with only 2 frames. Get something to move from one end to the
other and render with FIELDS ON. By the time you see the results you will
understand all these rather easily.
Well, not to beat a dead horse, but you say when I "see the results"
I'm assuming you're meaning when I render to videotape.
Right now I can only render to TGA files — even in the future (with
my plans for the Sanyo 950) I think I'll be rendering to disk and then
recording the frames. From what I read in the manual, fields are
only active when you record direct to the frame buffer/VTR. So,
my original question still is: Am I missing something here when I
do that? Does my animation, rendering to individual TGA files
which are frame orientated, lose something by not having the
fields rendered and recorded that way? I'm trying to picture this
in my mind (a scary place to be anyway) and what I see is this:
that there must be SOME quanitative difference between fields
and frames that I just don't get, because when you render a
TGA file you obviously have "all" the information you're ever
going to see in a picture.
Sorry to be so obtuse, but without being able to do the experiment
without making the committment I want to understand that I'm not
missing something.
PMJI-
I have a little rule I use for this choice of frame vs field rendering.
If your animation has lots of fast movement use fields if not much movement or
slow movement use frames because it's faster. You see, the fast movement can
be broken up into 60 movements per second rather than 30 which is smoother. If
you don't have much movement you won't see a smoother difference in the field
rendering.
The sequence of events is that you render one field first, then the second
field, then they are interlaced; and, finally, one frame (TGA file)is recorded
to either your VTR and/or harddrive, then the whole process starts over for the
next frame.
You CAN do the experiment by rendering to the null device if you don't have a
frame buffer. My artist does it all the time on his system which has just a
cheap 8 bit VGA card. As you can imagine he has other problems though.<g>
You don't lose any information when you render to TGA files, you just get finer
tweening when you render with fields. Fields represents video tape better then
frames. (2 fields for 1 frame) This gives you finer resolution. The reason
there is an option is because for most things it is hard to see the difference
(depends on what type of animation) and it also takes twice as long to render.
If your doing a fly through or lots of movement, then fields will get rid of
the jefkyness. If your doing standalone graphics with little movement then you
don't need to worry about it. The VTR doesn't do single field edits so the
frame buffer has to have the diffence in it before it goes to tape.
By the way, the problem with the bandit is that there isn't any software
written for it yet. The Video does look pretty good. It also has the scsi
controller built onto it so your limited as to what drive you can use to get
good full motion video at 30fps. There are advantages and disadvantages to
that. If you already have the Fast VM, they have there own digital recorder
coming out by the end of the year.
As far as an SVHS deck, if you want to spend 6k-7k for the best, Panasonic 7750
If you want to spend 3200.00 for good. Sony SVO9600.
Regards
L.
>You don't lose any information when you render to TGA files, you just get
finer >tweening when you render with fields. Fields represents video tape
better then
Okay, I think I got it through my old grey head. I'll try tonight, because
the example I did try (a fly through OLDCITY) did exhibit jerkiness that
I couldn't attribute to the lack of frame accuracy on the Panasonic 1970
I was using.
>By the way, the problem with the bandit is that there isn't any software
written for
Ah, yes, this was indeed what I was worried about as well. That's the problem
with being on the bleeding edge.
>There are advantages and disadvantages to that. If you already have the Fast
>VM, they have there own digital recorder coming out by the end of the year.
Yes, that was what started this whole train of thought, until I realized that:
1) Waiting until at least January (their latest estimates) meant I could do
no more animation — I've been spoiled seeing the results of even my
primative 24bit efforts on the 1970
2) Even if I get it (which I probably will) I'll have to hassle through the
beta… ooops, I'm sure it will be well tested by then… the first cycle of
usage to get the bugs worked out. Bottom line — I probably won't be
doing any 3D rendering with that setup until release 3 is out, a year
from now :>.
>As far as an SVHS deck, if you want to spend 6k-7k for the best, Panasonic
7750
>If you want to spend 3200.00 for good. Sony SVO9600.
Now you see, Larry, this is exactly the kind of opinioned text I was
looking for. Had I not seen the copy on the Sanyo I'd probably be
queing up to buy one of these machines — still, you never know. What, IYHO,
is the difference between the Sony and the Panasonic? I mean, what makes
one the best and the other merely good (other than cost). I assume this
will help me judge whether the Sanyo, at 2400.00, is worth buying.
And thanks for jumping in…
I take it from your comments that you've worked with this bandit board. Is it
capable of using house sync? If not, what is the stability if its internal sync
generator for use as house sync? I'm making assumptions that from what I've
heard it will output animation TGA's like a camera video signal at RS-170(A)
sync rates.
The bandit has a sync input. Very important that it genlocks (which it does
pretty well) otherwise its basically useless. It's like the panasonic AG 1970.
They put a TBC inside the machine for stable output but you can't genlock it to
anything so it's useless. Very important feature!
L.
Great, thanks for the reply. I got a call from a local dealer today offering
the thing at a price of $5995. I told him I didn't think it was out yet and
his price seemed low. Anyway I'm keeping my head up on this new technology.
Can't wait to hear from GPyros when he finishes his work with this.
Don:
>> local dealer today offering the thing at a price of $5995
$5,995 is the list price _without_ the 32 megs of memory or SCSI disk. But,
yes, it has been shipping in the RAM version since NAB. Disk version soon!
Greg Pyros
Greg,
will the disk version still require all of the 32mb ram? Will there be any
reduction in playback capability when doing disk versus RAM playback?
Martin:
The disk version only needs 4 megs of RAM for playback. What we are doing
is to sell the RAM now, and offer to 'buy it back' at market price in the
future when our clients upgrade to the disk.
However, it does take standard RAM chips, so most are just saying they'll
keep it and upgrade a rendering station when they upgrade.
Greg Pyros
Greg,
>> The disk version only needs 4 megs of RAM for playback.
Thanks, that answers one of the questions. My other was: will there be some
limitation on playback and/or video quality in the disk version that does not
apply to the RAM version? For example, you could only playback video compressed
at the 80:1 ratio from disk, whereas you could playback 15:1 video from RAM –
that's the kind of limitation I am wondering about…..
Martin:
Since the disk version is not yet shipping, and no specs have been
published, can I make up anything I want? (Not that not knowing has stopped
me in the past!)
Greg Pyros
Greg, do they have a component version of the Bandit out yet?
– G
Gary:
>> Greg, do they have a component version of the Bandit out yet?
Not shipping yet, but soon after they finish adding the SCSI disk support,
it's their next priority!
Greg Pyros
Larry:
>> and it [field rendering] also takes twice as long to render
Not really! Since 3ds only renders every other line in field rendering
mode, it may not take much more time at all!
The only time it takes more than 5-10% more is if you have to calculate
shadows and reflections twice, but that is still usually a lot faster than
twice as long!
Greg Pyros
You're right, Mr. Pyros. I found the exact same animation took only
about 25% longer. That's a small price to pay for the smoother flow
(even if I still don't quite understand it).
Now if I could only be assured that when I go to single frame VTR
I'll get complete smoothness… (sigh!)
Mike:
>> Now if I could only be assured that when I go to single frame VTR I'll
>> get complete smoothness…
With a smooth motion path, rendering in fields, I will state without a
shadow of a doubt that you will get the smoothness you desire in your
animations.
Whether the overall animation is any good is up to you, but the program can
sure make it smooth if you let it!
Greg Pyros
Rendering frames (option off) renders the same thing on both fields. Rendering
fields tweens the 2 fields in the frame. A full frame is rendered in either
case, but calculations have to be done in field mode thus taking a little
longer. (Maybe not twice as long if the program is optimized (?)) Field
rendering doesn't just render every other frame, that would look terrible.
(maybe I don't understand what you are saying?)
L.
Larry:
Field rendering gives you 60 updates per second for your animation instead
of the 30 that frame rendering gives you.
Remember this – video is _interlaced_! What is interlacing? Interlacing is
showing every other line on the screen, then coming back and filling in the
ones in between that it missed the first time, then starting again.
If you had a different image on each set of lines, you get 60 images per
second. That's what field rendering is, it's _using_ the interlacing in
video to help you, instead of hurt you!
Does that help?
Greg Pyros
Mike – I very possibly am wrong, but I *think* that a video which has been
rendered to fields will have, say, the odd lines from the first frame and the
even lines from the second frame as the first picture. The next picture would
have the odd lines from the second frame and the even lines from the 3rd, etc.
So you get each picture with 2 frames interlaced which, when later blasted onto
a TV screen, in interlaced fashion, manages to look intelligible to critters
with persistence of vision, like us. I *think* you do the experiment on your PC
and look at the frames that are generated and see both images at the same time,
laced together. If I'm wrong, experts, PLEASE clear up my confusion!
Dave:
You are correct!
Greg Pyros
Whew! Now if I only understood what I said! <G>
DT
I don't think that is correct (if I understand correctly). All VTRs edit on
field 1 and do a full frame edit. (some high end vtrs have a switch to edit on
field 2 and can do field edits but this is rare and not used in this case) The
frame buffer holds exactly what it says, 1 frame. If the current frame in the
buffer contains information from the next frame (field 1) you could have
dramatic results. What if frame 8 is my last frame of my animation and frame 9
is a cut to black. Then I'm going to have 1 field of animation and the other
field of black (according to what I just read). Makes for an interesting
looking frame. Am I understanding this correctly?
Regards,
Larry
Larry, the field rendering in 3DS has nothing to do with recording the finished
frame to a VTR. It's obvious some of you have never tried this field rendering
process. I'm surprised at all this confusion and over complication of such a
simple process. If you would just try it you would see that the sequence of
events is that after all materials etc are loaded 3DS goes into render mode.
See the red bar go left to right? OK, now see the red bar go a second time
left to right. That's right! it is now doing the second field which is being
interlaced. Next, depending on what you have set up the frame is either
recorded to video and /or stored to HDisk. The recorder is not activated until
both the even and the odd lines have formed the complete frame. You can watch
all this sequence of events on your monitor and see that the frame is not
recorded until 3DS is done rendering twice. Since materials etc are loaded
once for both fields the process of field rendering is not quite twice as long
as with frame rendering on a single frame render. I only use field rendering
when there is alot of high speed movement. It definitly is smoother.
Don – In my case the confusion is due to being a total neophyte and not owning
a tape deck. I can render to fields here and look at the frame and see that
there are lines slicing my image up and the "second half" is in not where it
"ought" to be, but I cannot see that the tape deck waits till 2 fields are
rendered before it fires up. Now that you've told us, I know it. But I'm
*still* ignorant because I have no frame (no pun intended) of reference for
this stuff.
DT
>>but I cannot see that the tape deck waits till 2 fields are rendered before
it fires up. Now that you've told us, I know it. But I'm *still* ignorant
because I have no frame (no pun intended) of reference for this stuff.>>
Sure you can see it. When you save the tga's to disk you won't see the idiot
lite for your hard drive come on until after the second field rendering when it
saves the completed frame. Now be sure to rander a simple animation that
renders without the swapdisk or swapdisk will confuse your idiot light
monitoring of this type.
Thanks Don. I completely understand how it works and the difference between
fields and frames both from the vtr and 3ds view point. I was merely (as
nicely as possible) questioning how it was explained because there was some
mis-information. Hopefully it wasn't more confusing for anybody. Your right it
is a very simple process!
L.
Mike, see my reply to David's message (50559). Yes, you can run the test by
just creating two images (TGA's, GIF's, whatever). When you put the image up in
the screen through the FAST board, you will notice heavy flickering as the
fields are divided (assuming you have an interlaced NTSC monitor hooked up).
Yeah, I did that and see what you mean — although my poor old brain
still doesn't quite understand it. And, yes again, the animation I did
was "better" — I'm a little worried still that, even with a frame accurate
VTR, I won't get the perfect results I'm looking for, for my animation,
although it had much less tearing with the field rendering, was still
quite jerky — hopefully that's just the results of trying to do single
frame with less than accurate equipment. I'd hate to think I'm going
to spend upwards of 5K for something that won't give me that smooth
look I've seen in other animations (envy, envy).
You will get a "smooth look". What you have right now is a VCR that's acurate
only to about 4 frames. It will sometimes hit the right frame, other a couple
of frames later. I had an EVO 9650 for a couple of weeks. It took me about 5
minutes to hook the thing up and an hour later I had a "perfectly" smooth 150
frames animation (and that includes some software "adjustments" in the ADI
driver).
Mike, here is a simple illustration of Frame vs. Field rendering.
Let assume that we are rendering a quare of the size 5 pixel that moves from
left to right at the rate of 20 pixel per frame.
Frame Rendering:
Frame 1 Frame 2
00000 00000
11111 11111
00000 00000
11111 11111
00000 00000
Field Rendering:
Frame 1 Frame 2
00000 00000
11111 11111
00000 00000
11111 11111
00000 00000
The 0's are pixels on the odd field and 1's are pixels on the even fields. As
you can see in the case of frame rendering you will get a "squared" square for
each frame but in the latter your square is no longer a square but it has even
fields line shifted ten pixels to the right (20 pixel/frame = 10 pixel/field.)
After you render in field mode your TGA (or TIFF or any image format) will look
just like that and you won't miss anything wherether you render to file or
directly to VTR. If you try to display this image as a still frame it will
blink like crazy due to the interlace scanning of your video monitor but not to
worry, it will look real good after you record all of your frames to tape and
play it back at 30 frame/sec.
When should we turn on the field rendering? Almost always, if you are rendering
anything with motion (no matter how fast or slow) this option should be on for
the final rendering. Because of the interlace scanning on the video monitor,
frame rendering will introduce a probing effect no matter how slow to motion is
( unless it is less than or equal to 1 pixel per frame!!!) Our eyes are much
more sensitive than we thought. Try to render the simple BOUNCE.3DS example
file that comes with 3DS both in FRAME and FIELD mode and record both of them
back to back you will see the FIELD rendering animation is much smoother.
Have fun!!!
Tien Nguyen.
Tien,
very good explanation of the process! Congratulations.
Tien – One of *my* earlier confusions came from not knowing that the fields
created an "in-between". I had assumed that frames one and two were interlaced,
which is not the case.
David T
Gus, PMJI. I'll try your (Greg's) experiment to "get" the field mode/frame mode
difference. What I guess I also don't understand is how fields/frames impacts
on various pieces of equipment in real-time and/or single-frame output… In
the case of the frames-only VistaPro output, would one need to "manually" go
into each frame and interlace the images (hopefully in some macro/batch mode)
to simulate field mode or split each frame into two frames of even and odd
lines? If one were using a setup like the Bandit is supposed to be, you would
render in field mode, right? If you're going to tape would you render to fields
no matter *what* means you're using to get onto the tape?… I'm *so*
confuserized!!
David Taffet
David:
The Bandit actually plays back at 60 images per second, every other line
being an image, whick equates exactly to our standard interlaced field mode
of recording!
So you can record off it in real (reel?) time.
Greg Pyros
Any idea when the bandit will be available, and whre I might get one?
–Nat'n
Nathan:
>> Any idea when the bandit will be available, and where I might get one?
The Bandit has been shipping for a few months with RAM playback (32 megs,
which is around 25 seconds), the SCSI disk version should bs shipping within
a month (hopefully they'll be able to show that version at Siggraph).
Where? Us, for one! Since we are writing the ADI drivers for it, we
probably know it better than anyone except the company itself, and sometimes
I wonder about them, too! <g>
Greg Pyros
>> and sometimes I wonder about them, too! <g>
Ain't that the truth?! <g>
So, Greg. Does a frame rendered to fields *simulate* the way a TV signal is
standardly done, in that two "images" are sent (well not sent, but shown,
maybe) 30 times per second rather than 60 one-half images shown? (Did that make
sense?) OR is that really the standard way it's done, 30 interlaced images?
D {questions, questions, questions – Daddy, why is there air?} T
PMJI, but I'm getting confused by all the confusion. <g> I just wanted to
suggest that, if you've got AniPro, try rendering two flics of the same
keyframer animation–one in frame mode, and the other in field mode. Flics look
terrible in field mode, but you can load the two up and compare the difference,
frame-by-frame (if you'll pardon the use of the word "frame.") If you want to
get really fancy, render the two flics in 320×200, and then boot AniPro in
640×400 and composite them next to each other.
– Jack
PMJI, but I am finding this message thread quite interesting, being a novice to
VTR rendering. It never ceases to amaze me at how valuable the forums on
Compuserve are! I am now trying your recommendations to an animation to see
the difference between field and frame rendering. Interesting!
Being new to the area of VTR animation recording, I was wondering if there are
any other "pointers" that you experts can give to a VTR novice to achieve the
best results possible (3DS.SET file settings, configurations, etc.). Though
I'm a "not ready for prime-time player", I certainly want to get the best
quality I can while I'm "in training".
Any input would be appreciated. Thanks!
Denise
I'm not sure there's a "gestalt" recommendation for the best results, because
everyone's needs are different. The best bet is to keep listening in, as you
are now.
By the way, if any sysops are watching, this thread would be a good one to save
and put in the libraries.
– Jack
>>good one to save and put in the libraries<<
A definite agreement on that sentiment.
DT
Jack – Not to toot my own horn, but I just answered a message from Greg Pyros
with what I think is a very clear description of how/why fields do what they
do, related to the way a real camera works. I think that ought to be included
in the library file. Sysops?
David T
Thanks, Jack. Part of my confusion has been cleared up by this discussion, but,
as I mentioed to Don Landis, I have no tape deck, so, while I can (and have)
seen the frame after rendering to fields, I have no tape deck (and have not yet
doen the service bureau thing), so have little grasp of what these mean to the
*way animations look after they're on the tape*. I think we're getting it,
albeit slowly.
David Taffet
David:
Yes. YES! _YES_! Good description!
If you take a video on your camcorder of an object moving quickly, or off
the TV, and can do a full FRAME pause (some equipment will only do a field
hold, so be careful!) you will see the exact same effect that 3DS creates!
Greg Pyros
>>Yes. YES! _YES_! Good description!<<
Whud I say? Whud I SAY?!?!