Just in case you ever wondered what the vertical shift number is about:
negative values tilt the image away from you (this means when a camera is pointing downward, you use negative values to get the verticals vertical again)
positive values tilt the image towards you (this means when a camera is pointing upward, you use positive values to get the verticals vertical again)
a shift value of 1 means a shift of 45 degrees (camera turned up 45 degrees). If you turn on the camera visibility and draw some lines, one from the camera to the target(1), one from the target to the projected camera point (2) and one from the projected camera point to the camera (3), you get a triangle. Now divide the length of line (3) by the length of line(2) and there you have it: the exact number to get your verticals vertical.
(somehow I have the feeling that this should be a very easy thing to automate)
Good information to know…I actually think that I might be able to put something together…I’ll see what I can do and let everyone know. Thats actually much simpler than I thought it would be
Well it didn’t take long. My process is a little different…but I think it gets the job done. This script doesn’t take any camera roll into account, so that might cause some inaccuracies. I could find a work around for this, but I’ll have to dig up an old script. Other than that, this should work…let me know if it doesn’t. Obviously this is just a first run through, so if there’s something else you’d like this to do let me know. I don’t think scripting support for vertical shift is added yet, so I’ll see if Joe can get it in there.
@ Micha
My guess would be yes. 20 mm does some massive damage to verticals, and in real life you’ll actually get vertical bending because of a lens that wide. Thats actually why extreme wide angle lenses are so expensive, because they actually shape the glass so that the amount of refraction changes and decreases the bending…BTW what you posted looks fine, but is just a little weird
Question…How important is it to have the script accept camera roll? I know architects are probably one of the least likely to have roll with their camera, so my idea is probably not important, but I just wanted to hear back from the crowd.
…to be honest, I’m not sure what would happen with vertical shift when there is roll. The way the script works is it actually takes the angle between vertical and the y axis of the plane of the camera. If the camera is rolled, then that won’t be the “most vertical” vector for the plane of the camera. Again, I’m not sure if this even matters. I don’t work with vertical shift that much, so don’t even know if this is an issue.
Only the 20mm issue, this could be nice, if this could be solved.
I have the feeling, your current formula is an approximation. I remember me at mathematic “… for small angles sin(..) or cos(..) was approximated by something without an angle function”. Maybe it’s here the same - for light shift effects you can use a calcuation without angle function, but for large shift effects it is needed. …
Pretty strange that it worked for me, because today it didn’t work anymore. Anyhow, I’ve taken a look into the script and found that the shift was not calculated correctly. My scripting knowledge is not so good, but I think it works now. At least, from a few tests it seems like it is working now. ;D
Well thats a different formula from what you told me before. I’ll do some tests and make some changes if need be…btw I found a way to calculate the shift with camera roll as well. Then changes to the script will be included in a release later this week.
I am curious how that looks with a rolled camera.
btw: I don’t think it is a different formula: like i mentioned in the beginning of this thread, the shift is the ratio of (length of vertical distance to target/length of horizontal distance to target), which effectively is Tan(alpha), where alpha is the camera angle.
Then thats probably why its slightly off then. The formula in the original script simply looked at the angle between the camera vertical and world vertical and divided that by 45. I guess its a little more complex than that.
As for the roll, I’m not sure how it should look, but the script basically takes the roll out of the camera and then does the shift calcs. As I said before, I don’t think anyone would use roll and vertical shift, but this is just for those who like to do things “differently”
Would be nice if this was included as a button in the camera dialog. A checkbox that says guess vertical shift. If it is on, then Vray will run the script behind the scenes and use the shift value for the camera that is active at the moment the render button is pressed…Joe are you listening?
