[Bf-funboard] OSA/MBlur..Odd/Even Upper/Lower fields... sky/premult/key

[Ton Roosendaal]

Hi,

Let's not expand the scope of what we can do for 2.30.
Especially questioning terms we use in Blender for over 5 years is not  
useful in the context of the current UI project.

We only should remove now:

- bad consistancy (to what is standard in Blender)
- or very confusing wording we get complaints on a lot

Further take into account that all documentation about Blender should  
remain usable at some level. We are producing a 2.3 guide in parallel  
to the release itself, I hope this remains manageable.

Blender improvements won't stop after 2.3 of course. My proposal would  
be look at all wording in Blender after that. We also have the UI  
translation stuff still pending though...

Further:
- of course we should have motion blur with more samples!
- Fie/Ima = when you use an animated Image-Texture, it is the number of  
fields rendered before it loads the next Image as a Texture.
   Set it at '1' to have one (texture)Image per field rendered.
   This has nothing to do with Image-Textures that have fields.

-Ton-




On Sunday, Oct 5, 2003, at 19:35 Europe/Amsterdam, Luke Wenke wrote:

> OSA/MBlur
> I think OSA and Mblur should be arbitrary and independent... at the  
> moment
> mblur is limited to 16.... when I have a lot of movement I want to  
> increase
> that.... and what I end up doing is using the animation buttons to slow
> things down (and create extra time for more Mblur)... the IKA skeletons
> don't seem to go at the altered speed though. And sometimes I want to  
> have
> mblur set high, but osa set low... e.g. to smooth the envmaps a little
> (without osa, they're based on one sample per frame).
> And maybe OSA should be called "AA" (anti-aliasing) instead since I  
> think
> that is more widespread and well-understood.
>
> Fields
> I've been working with fields a lot and from what I've read, odd and  
> even
> fields are very ambiguous. The standard thing these days is to call it
> "upper field first" (or upper) or "lower field first" (lower). As far  
> as I
> can recall, in blender, the even output (default) is equal to lower  
> field
> first, and odd output is upper field first. The reason why odd and  
> even is
> arbitrary (and varies from program/device to program/device) is  
> because it
> depends on how you number the fields. If you number the top field 0,  
> then
> that field is even. If you number it 1, then that field is odd. As far  
> as
> the input movies go for textures, StField has no tooltip at all. I  
> think it
> reverses the fields and when it is enabled it is lower/even and when  
> it is
> disabled it is upper/odd.... I'll probably recheck that sometime. I  
> think
> Fie/Ima is wrong ("Number of fields per rendered frame"). e.g. I've  
> got a
> movie with fields loaded, which has about 1800 frames. I've set the  
> frame in
> blender to 700 and when Fie/Ima is 2 (default) the current frame is  
> 700.
> (usually... blender seems pretty buggy in that area)
>
> (Remember that Blender's animation frame is 700)
> Fie/Ima Current Frame
> 1           1399        (2/1 * 700)
> 2           700          (2/2 * 700)
> 3           467          (2/3 * 700)
> 4           350          (2/4 * 700)
> 5           280          (2/5 * 700)
> 6           234          (2/6 * 700)
> 7           200          (2/7 * 700)
>
> In the last example, blender's frame was at 700, but the current frame  
> in
> the input video is only 200. It was set to 7 "fields per rendered  
> frame"....
> Actually there are 200 pairs of input fields per 700 output frames....  
> or
> 7/4 output frames per input field, or 7/2 output frames per input  
> frame.
> To fix this, it could be replaced by this:
> Fie/Ima Current Frame                     Img/Frame (rendered images  
> per
> frame) or Img/Field
> 1           1399        (2/1 * 700)         0.5
> 1
> 2           700          (2/2 * 700)         1
> 2
> 3           467          (2/3 * 700)         1.5
> 3
> 4           350          (2/4 * 700)         2
> 4
> 5           280          (2/5 * 700)         2.5
> 5
> 6           234          (2/6 * 700)         3
> 6
> 7           200          (2/7 * 700)         3.5
> 7
> (Basically I'm saying the description is backwards, but it would  
> probably be
> more normal to be Img/Frame rather than Img/Field so you can easily  
> see the
> change in framerate... e.g. 3 Img/Frame means the output is 3 times  
> slower
> than the input)
>
> sky/premult/key
> I think "key" should be renamed to the standard name "straight". The  
> tooltip
> could mention "(unmatted)" at the end. And the tooltip for premult  
> could
> mention "(matted)". Sky could be renamed to "show sky". The tooltips  
> for
> premult and key sort of imply that something is happening to the alpha
> channel... but actually I think the alpha channel is identical in both
> cases... it is just the rgb rendered image that changes. In the  
> "straight"
> one, the colours are unaltered. In the "premultiplied" one the colours  
> are
> multiplied by the alpha channel.
>
> - Luke.
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard@blender.org
> http://www.blender.org/mailman/listinfo/bf-funboard
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton@blender.org  
http://www.blender.org