before this only active scene would be rendered with border.
When do_render_fields_blur_3d() is finished, it'll modify
render's display rect so it'll correspond bordered render
result placed on black backgrund. Actual border is stored
nowhere, which makes it only way to re-calculate disprect
for all other renders used in compo based on source. Not
so big deal actually.
Also needed to modify Cycles a bit, because before this
patch it used border settings from scene being rendered.
Now made it so render data is passing to external engines.
Using a property inside RenderEngine structure for this.
Not best ever design for passing render data, but this
would prevent API breakage. So now external engines could
access engine.render to access active rendering settings.
Reviewed by Brecht, thanks!
Now one no longer needs to match the sensor dimensions with the render dimensions manually.
IMPORTANT NOTE: if you were using AUTO before with mismathing sensor aspect ratio (comparing to the render dimensions)
this will change your render! We can doversion this, but apart from Tube project I don't know if anyone else
is using this yet (part due to this bug and the only recently fixed 3dview preview aspect ratio).
That should help more artists to take advantage of this fantastic Blender feature.
It still helps to know the parameters of kwnown cameras/lens though.
For example:
Nikon DX2S with a 10.5mm fisheye can be set with:
Render resolution: 4288 x 2848
Sensor 23.7 x 15.70 (15.70 can be ommitted if AUTO is used as fit method)
Note: some cameras render different sizes according to the recording mode.
For example, a Red Scarlet in 5k (@12 fps) can render a full circular fisheye with a sigma 4.5 lens.
The same camera in the 30fps recording mode renders 4k in a cropped circular image.
So it's not only the resolution that changes, but the actual sensor been used.
So just keep in mind that the more information you have from the camera/lens you want to emulate the better.
Bug found at/patch written as a follow up of the BlenderPRO2012, patch reviewed by Brecht Van Lommel
Patch by Yasuhiro Fujii, thanks!
Original issue was that in vases viewport's lens are different from default
value switching between perspective and orthographic projections will change
viewplane a lot, which is disorienting and annoying.
This makes it possible to do a border render inside a viewport even
when not looking through the camera.
Render border could be defined by Ctrl-B shortcut (works for both
camera render border and viewport render border).
Camera render border could still be defined using Shift-B (so no
muscule memory would be broken). Currently used a special flag of
operator to do this, otherwise you'll need to either two operators
with different poll callback or it could go into conflict with a
border zoom,
Border render of a viewport could be enabled/disabled in View
panel using "Render Border" option.
still look a bit strange since the viewport can't actually render such panorama views,
so the opengl drawn scene behind the border render will not match up.
For sample images see:
http://www.dalaifelinto.com/?p=399 (equisolid)
http://www.dalaifelinto.com/?p=389 (equidistant)
The 'use_panorama' option is now part of a new Camera type: 'Panorama'.
Created two other panorama cameras:
- Equisolid: most of lens in the market simulate this lens - e.g. Nikon, Canon, ...)
this works as a real lens up to an extent. The final result takes the
sensor dimensions into account also.
.:. to simulate a Nikon DX2S with a 10.5mm lens do:
sensor: 23.7 x 15.7
fisheye lens: 10.5
fisheye fov: 180
render dimensions: 4288 x 2848
- Equidistant: this is not a real lens model. Although the old equidistant lens simulate
this lens. The result is always as a circular fisheye that takes the whole sensor
(in other words, it doesn't take the sensor into consideration).
This is perfect for fulldomes ;)
For the UI we have 10 to 360 as soft values and 10 to 3600 as hard values (because we can).
Reference material:
http://www.hdrlabs.com/tutorials/downloads_files/HDRI%20for%20CGI.pdfhttp://www.bobatkins.com/photography/technical/field_of_view.html
Note, this is not a real simulation of the light path through the lens.
The ideal solution would be this:
https://graphics.stanford.edu/wikis/cs348b-11/Assignment3http://www.graphics.stanford.edu/papers/camera/
Thanks Brecht for the fix, suggestions and code review.
Kudos for the dome community for keeping me stimulated on the topic since 2009 ;)
Patch partly implemented during lab time at VisGraf, IMPA - Rio de Janeiro.
Most of the changes are related to adding support for motion data throughout
the code. There's some code for actual camera/object motion blur raytracing
but it's unfinished (it badly slows down the raytracing kernel even when the
option is turned off), so that code it disabled still.
Motion vector export from Blender tries to avoid computing derived meshes
when the mesh does not have a deforming modifier, and it also won't store
motion vectors for every vertex if only the object or camera is moving.
environment map, by enabling the Panorama option in the camera.
http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Camera#Panorama
The focal length or sensor settings are not used, the UI can be tweaked still to
communicate this, also panorama should probably become a proper camera type like
perspective or ortho.
* Passes renamed to samples
* Camera lens radius renamed to aperature size/blades/rotation
* Glass and fresnel nodes input is now index of refraction
* Glossy and velvet fresnel socket removed
* Mix/add closure node renamed to mix/add shader node
* Blend weight node added for shader mixing weights
There is some version patching code for reading existing files, but it's not
perfect, so shaders may work a bit different.
