Design decisions for Camera v2

[SCLDGit]

Hey all,

Just came back to this project for a peek and noticed a lot of great changes and improvements over previous versions.

One thing I'm not grasping are the changes to the Camera class. I'm curious to hear some of the decision-making processes.

My main questions relate to the move away from specifying width and height (which I'd imagine would be the main workflow known by and preferred by artists and other folks with experience in rendering) to relying on width and aspect ratio. I'm also curious what the practical effects are from simply starting at 0,0 (top left) and incrementing based on dimensions vs. the move to calculating a virtual viewport and pixel delta offsets.

Truth be told, I'm still going through In One Weekend, so perhaps these changes make more sense further down the road, but regardless, I'd love to hear some thoughts on why these decisions were made.

Cheers!

[hollasch]

Specifying width and height means that if you want to alter your render resolution (quite common when rendering preliminary low-resolution test images), the old model required that you change one dimension and the solve for the other dimension to get the same aspect ratio. The new model just requires you to change one dimension and be done.

The change to pixel sampling kernels breaks from the hard-coded simple box-filtering model (modeling pixels as little non-overlapping squares) so that you can experiment with arbitrary kernels like circles that may or may not overlap, or even things like sinc filters.

Most design thoughts can be found by going through the related issues.

[SCLDGit]

Why not derive the aspect ratio directly from the width and height? Seems like it would also get rid of the need to calculate and store a separate "real" aspect ratio for the viewport. Are there cases where they would differ?

[hollasch]

You can certainly do it that way. I'd say to go with that approach if you prefer.