With so many render options in Rhino it’s time that we finally have a selectable camera object for use in rendering. Because I want:
-ability to tie a rendering to a camera (no more accidental wrong viewport renderings)
-multiple camera settings in one scene (to get per camera focus points, exposure and dof settings in Vray)
-no more accidental camera moves due to navigation in perspective or forgetting to save a camera view.
-per camera horizontal and vertical shift (technical camera) (make those architects happy)
-per camera output resolution settings.
-ability to keep my perspective view ‘free’ for modeling and investigation of the scene.
As far as I can tell, your points #1, #3 and #6 are the same - and all are already taken care of in Rhino with named views:
Now I understand that a 3rd party renderer may not be supporting this, but it’s perfectly supportable using our SDK and I believe we even supply helper functions to make it easy, and provide the ability to “borrow” the UI.
It sounds to me that #5 (output resolution) could be part of a Snapshot - at the moment, we don’t save that stuff and it seems like an oversight to me. Snapshots should really fully take over from Named Views anyway.
I haven’t had anyone ask for horizontal / vertical shift…maybe I could get more details?
And #2 just sounds like Named Views…exactly what they do…but it would obviously take Vray to support them. I believe we save DOF settings on the named view - 3rd parties can also add any settings they like using user data (we did that in Brazil, for example).
that would be nice, and I would love to use it, but last time I used it, it caused a lot of trouble in my files, so I hope NamedViews can stay.
As for horizontal/vertical shift, see this example. In this case I rendered the view much wider and cut of the right part of it. So basically it comes down to shifting the camera sensor relative to the lens
You can lock a render to a view. Don’t remember the command right now, but you no longer destroy your renders by accidental cam moves. Unfortunatelly, that’s only possible in Interactive at the moment. Also per-camera, or rather per-view settings (DoF, shifts and FoVs) are something we currently work on. Similar feature will also exist in VfSk soon.
NamedViews and Snapshots are also supported in V-Ray batch render (snapshots for the current file only because of SDK restrictions).
For convinience, you may need those in Rhino directly, but V-Ray either does, or will have all of them soom
ok, but will this be supported for normal rendering soon as well then? I think all you need to add is the ability to tie V-Ray to a named view and store the settings of camera settings in a table linked to named views (or snapshots for that matter).
so does that mean we can expect sensor shifts both horizontal and vertical? That would be really welcome. This not only comes in handy for the look I posted above: Sometimes after a rendering has been made, during composition you notice that you had wished a bit more room at one or more sides of the rendering, but you want camera location /direction/resolution to stay the same. In other words, we need a ‘crop’ outside the area of the camera sensor.
@andy I just checked out Snapshots and was pleased to see that it works a lot better than before but I’ll make a new thread for this, since there are some issues I’d like to point out.
Having named views from the host app inside AE is not a bad idea. I’ll sync with the Sketchup team and check their opinion. We’ll definitelly take the more generic solution
true, but it’s a little different than what would be ideal. Current implementation is more like vertical perspective correction. When sensor shift would be enabled, this vertical lens correction isn’t strictly necessary anymore, we can keep the camera Z and target Z at the same height and solve the rest by shifting the sensor relative to the lens. For best experience though this should be integrated into the camera view otherwise it’s difficult to see what you will end up getting without doing a preview render.
see also:
on that page you see a very clear drawing.
I’m calling it sensor shift, on that page it is called lens shift as the lens is moved up and down while the sensor stays in place. The effect is the same.
@andy is this feasible to build into Rhino you think?
interesting… the offset values are a bit vague though how they relate to the end result, I need to figure that out. The horizontal shift is what I need to render the example I posted earlier this thread. Thanks for pointing this out! quick test:
it seems this is already hooked up to snapshots !
hopefully you can find a way to lock the render to a chosen snapshot view
@andy For me if the light bug gets solved and if we get the option to hide new objects from existing snapshots by default, I have pretty much the solution I was looking for.
this is a tricky one because it depends on your reference. I’m working out a script that does this, assuming that your walls are oriented along the X and Y plane. Optionally I could add a way for the user to pick a reference plane.
I’d like to have a better camera in Rhino too (i don’t mind if it’s a real object or just a named view), what i miss:
Camera not related to the viewport aspect ratio (Fixed 36mm x 24mm is very limited)
1a. Ability to change film size
1b. The Safe frame should be always visible in the viewport
1c. Camera Matching is quite impossible with those limitations (also having a completely new tool for this task would also be very nice)
Horizontal/Vertical tilt and/or shift lens.
More settings like Camera Clip (near/far); Zoom; FOV;
Physical values like ISO, Shutter speed, f-stop, and/or EV.
Composition Guides (Thirds, Centred, Golden Ratio, etc.)
I found HERE that in Vray for Max there are: Horizontal and Vertical Tilt (perspective corrections) and Horizontal and Vertical Shift (to offset the lens).
The offset value is a fraction of the current view:
For example, a value of 0.5 will offset the camera one-half of the current image width to the left.
