2 Point Perspective Rant and Poll

unhandled

#1

Hi RMA,

The 2 Point Perspective mode in V5 for me is half-cooked, to say the least. It’s nice it has been implemented and it was one of my top wishes since Rhino 4 version, and I was very excited to see it coming to V5. In Rhino 5 Beta phase I was trying to communicate some issues but it must have been ‘lost in translation’; if it worked better I would use it very often but sadly I don’t use it at all now. Here is a bit more why:

The ‘2 Point Perspective’ mode is used mostly in architectural / interior design to make viewing the space more ‘human-like’ and eliminate or minimize the 3rd point perspective distortion. So it is not really a ‘working mode’, meaning I don’t think many users would actually model anything with that projection (anyone correct me if I am wrong). The most common use for me would be: once I have my perspective view setup and saved, I turn on/off the 2 point perspective/lens shift correction to evaluate the same view without the distortion. This is currently impossible with Rhino.

Currently once I change the projection from Perspective to 2 Point Perspective, the camera jumps to level with the target position; also, the lens length is changing! The values reported in the view properties are then not consistent either. On top of that, why on earth it is not possible to move the camera target up and down (Ctrl+Alt+RMB), only side to side? I can do it (very crudely) by moving the camera edit points… I tried scripting/macro-ing the camera to stay in the same place between the Perspective/2 PointPerspective switch but had little luck since it all behaves in not-consistent/unpredictable way.

What we need is:

  • when switching between Perspective / 2 Point Perspective modes, no camera parameters changing except for the lens shift correction (most importantly, camera stays at the exact same point)
  • ability to change the target up/down position with Ctrl+Alt+RMB
  • Ideally, there would be an additional parameter of the view properties for 2 Point Perspective that would be the % of lens shift, where 100% would be completely straight/vertical, less than 100% would allow for the views to have some correction but keeping a bit of 3rd point perspective. > 100% optional, don’t think that would be ever useful.

Here is what happens currently in Rhino:
<img src="/uploads/default/original/3X/3/d/3d6bb7d6463237d574ce74fcbfe8a1bf289d5624.jpg" width="690"height=“200”>

And how it would ideally work:


Please, consider giving some more love to this mode to make it actually usable!

–jarek


Bug : RS : unable to set Target independently of Camera in 2PointPerspective projection
(Dale Lear) #2

Hi Jarek,

Thanks for the suggestions. They are reasonable and I’ve added a bug so we can get these problems fixed.

http://mcneel.myjetbrains.com/youtrack/issue/RH-32178

– Dale Lear


#3

This is a fantastic suggestion … with excellent visuals. Like it / thumbs up / etc.


#4

Hi @dalelear,

Is there any chance some of the 2PP improvements will get implemented in V6?
If not the more extensive scope, the ability to not ‘lock’ up/down look and the camera and target not ‘jumping’ to the same level would be very helpful make the mode actually useful in real work.

If I was to count the time spend last year over distorting the 3D screencaptures to fix 2 point perspective in Photoshop it would probably add up to a few days just doing that! If 2PP was working properly none of that would be neccessary…

thanks,

–jarek


#5

Hi Everyone,

I am really curious if anyone is successfully and extensively using the 2 Point Perspective mode in their workflow. I guess this is mainly used by architects / interior designers / set designers. As I mentioned this seemed to me like a ‘must have’ in these fields but the few hiccups the way it is implemented (changing camera position and lens on projection switch and limited ‘look around’ ability) are preventing me from using it completely.

Appreciate any feedback.

–jarek


#6

Hi Jarek

I tried to move the target without changing the camera direction by this simple test …
( I thought that might do the job )

import scriptcontext
import rhinoscriptsyntax as rs
import Rhino

def main():
  update = rs.GetBoolean( 
      'CameraDirection', ( ( 'Update', 'No', 'Yes' ) ), ( False ) ) [ 0 ]
  view = Rhino.RhinoDoc.ActiveDoc.Views.ActiveView
  vport = view.ActiveViewport
  target = vport.CameraTarget
  target.Z += 500
  vport.SetCameraTarget( target, update )
  view.Redraw()

main()

… but was unable to make it work.
With the updateCameraLocation flag set to False, nothing seems to happen in the viewport …

Maybe I did something wrong or misunderstood what SetCameraTarget() does …

Regards


(David Cockey) #7

Looks like what is needed is equivalent to a view camera front lens shift. The camera axis could be off the center of the view.


#8

Hi Emilio,

Thanks for testing. It does not work with RhinoScript either. Or by typing the values in Properties. Or even most of the time by dragging the camera points. I am checking with Dale if this is something that can be fixed for now on Scripting side before the main behavior is corrected:

I don’t think you did anything wrong, there is a problem with how the 2PP mode is implemented and I am trying to have it adressed.

Best,

–jarek


#9

Hi David,

Yes, the front lens shift equivalent is what the 2PP mode is about. The problem is how it is currently implemented making it impossible to be precise while setting the values or even manipulating the camera.


#10

Some more thoughts and clarifications on the 2PP implementation and the above request. I remember back in Usenet NG days and Rhino 5 WIP / beta I was bringing up the very same issue and did not follow through enough so now for past 5 years I am kicking myself for not being clear and/or persistent enough. @Pascal, this time I want to make sure you guys are seeing this.

We didn’t get any ‘yeah, I actually use 2PP’ replies to the usability question above which may confirm the guess that most users don’t effectively use 2PP mode as is. I imagine that developing this additional projection mode was a lot of effort for RMA, including the math behind it, all under-the-hood connections and dependencies, UI and even enhancing scripting methods to address the 3rd mode. All of that effort is not utilized unless additional small UI fixes are done. For now with this feature you can be like many other companies and list 2PP in Rhino as a feature that is available where in fact it only looks good ‘on paper’ and not in real work cases that should make use of it.

Let me explain some more: is seems obvious: architects (generalizing) need 2PointPerspecive mode in their work. But why and how exactly is it useful? This is not a ‘modeling work’ mode, as I mentioned above I don’t think anyone would actually model anything in 2PP. It is also not ‘any view angle’ mode.
The 2 Point Perspective is only useful when evaluating the 3D space from human eye-level perspective. This is how our brains work - they process the Z direction and to some degree make it all look ‘straight’. So being at eye-level with the 2PP mode provides the best possible 2D equivalent of the 3D real-world perception of the space, the best possible '2D immersion". This is basically the best way to evaluate the architectural space ‘feel’, proportions, geometry, etc. Unfortunately with the current limitation of 2PP in Rhino it is almost impossible to use the mode for its main purpose.

The simple request: “Free the Taget”. Let the user look up and down in 2PP mode, not only sideways. Let the Properties panel Target Z value, scripting methods and dragging camera target allow for looking up and down in that mode without changing the camera location; Keep the camera exactly in the same place when switching between projection modes. Please note: currently the ONLY way to change the camera vs target levels (equivalent of looking up and down) is by RMB-Drag view rotate, which always moves the camera therefore we lose the eye-level experience.
All the match and most of UI is there already. Please take it all the way there in Rhino 6!. Can’t wait another X years for this fix to happen.

–jarek


(Pascal Golay) #11

Hi Jarek - thanks, I added the request part of your comments directly to the bug track item.

-Pascal


#12

Thanks Pascal. (for ‘fun’, I was trying to find the original V5 WIP posts in old newsgroup archive but I can’t find the old NG online anymore…).


(Pascal Golay) #13

That shows how ancient the discussion is… prehistoric.

-Pascal


#14

Hi Emilio,

I found a way to get the effect of moving camera target up and down that works with TwoPointPerspective mode via scripting. Most of the scripting methods fail, but oddly - one does the trick: Rhino.RotateView().
it needs to be followed by setting the camera position back to one from before the rotation, but the result is as if we moved the target of the camera.

(interestingly Rhino.RotateCamera() should not need the workaround but in TwoPointPerspective it fails to keep the verticals straight…).

Here is a sample code snippet and a script with crude UI for moving the target up and down.

c = Rhino.ViewCamera()
Rhino.EnableRedraw False
Call Rhino.RotateView(, 3,1)
Call Rhino.ViewCamera(, c)
Rhino.EnableRedraw True

MoveTargetUpDown.rvb (1.0 KB)

–jarek


Bug : RS : unable to set Target independently of Camera in 2PointPerspective projection
#15

Hi Jarek

Very interesting !
Thanks for sharing.

… Still trying to understand how that woks …
Looking at rhinoscripsyntax code, it seems that the Target should move when setting the camera location, but it doesn’t …
Hmmm … I think I’m a little too much confused … no problem :wink:

Glad to have learnt another useful Rhino trick :slight_smile:

Thank you, regards


#16

Hi Emilio - that was the original point of my post - in many cases TwoPointPerspective mode is limited and behaves unpredictable. One of my main pains is difficulty with keeping camera in place and looking up or down, either via mouse or commands and scripts. I was looking for a workaround for a while and the above is the only one I know of that finally works. All other RS methods that try do modify Target position would have no effect, which must be a part of the general way the TwoPP is currently implemented.

cheers!

–jarek