OTOY Forums

I am used to fstops as well, but I say leave it as is.

It's not hard to get used to, it's actually easier to track simple numerical values, and since it's not linked to exposure and we judge the "right" DOF by eye anyway why would it matter what the "actual" fstop is? We just go with whatever looks good in the end.

b

simmsimaging wrote: We just go with whatever looks good in the end.

That's the main idea always. Im taking photos too, and with all due respect I hated to learn those things with stops dofs, focuses. Just to make good picture, so I prefer simple way too.

radiance wrote:these are all user preferences

I don't see it that way.

Fact 1: Photography is the most popular hobby in the world. (How many people do you know who have no camera?)

Fact 2: Most people who know what an aperture is know it from photography.

I think you're letting your physics geek nature dominate your common sense. (This from a fellow physics geek.)

i think having a system where the user simply can increase and decrease the depth of field in realtime, while seeing the result is also easier than having to give them camera controls...

I'm not suggesting you make it work like a camera. I'm just saying the scale of the slider should go from 1 to 64, linearly, instead of 0.01 to 100, logarithmically.

Those of us who know what an aperture is and what an f number is can then happily apply our existing knowledge to your program. Those who have no idea about any of this aren't likely to care either way; it's a comparison of two arbitrary scales, as far as they're concerned.

i have certain things in mind for the future with regards to the nodegraph and it's use that will make these things very difficult to integrate

I'm not suggesting that anything change under the hood. This is just a UI issue. Every time the user changes the value of the slider, it should get translated, under the hood, to the same value scheme you have now. None of your existing math changes. This just transforms the underlying mathematics into a form more likely to be familiar to your users.

that's all good, but sometimes it's handy to be able to supply a range much higher or lower than a normal camera, for special effects, experiments, or simply users who have loaded a scene in the wrong dimensions and need to reload the whole thing just because the slider does'nt go high enough

Radiance

tangent wrote: I don't see why you need an ISO setting, either. In real-world photography, we have that control because it affects grain in film and noise in digital imagers, but what value does it have in computer renderings, where the imager is perfect? It doesn't change the film response setting. Is it redundant with respect to exposure, too? It seems so. If I double ISO and halve exposure, I can't see a difference in the image.

If this is, as you say, a redundant feature with no effect to the grainyness of the final image as in real film, either one (ISO or exposure) should be removed... UNTIL animation comes into play, which surely will in the future, in which case exposure will definetely play a distinctive role in the final image (motion blur), and hence ISO will be needed too, of course. As a photographer you will surely appreciate being able to take stills with motion blur in Octane, even if animation is not your thing. I bet refractivesoftware put those two in anticipation to this With that said, and since animation will be a feature in the future, I would keep both settings.

EDIT: grammar & conclusion

Hi guys,

I'm currently putting all my focus in developing beta2.1 which will fix most issues reported and provide, finally, fast rendering of caustics and scenes with no fireflies/hot pixels, with MLT, and simple OBJ based animation, and better camera control/behaviour.

that's my current priority, then it's the big beta3 with advanced file import and animation.

after that we can focus on small tweaks like these

Radiance

radiance wrote:Hi guys,

I'm currently putting all my focus in developing beta2.1 which will fix most issues reported and provide, finally, fast rendering of caustics and scenes with no fireflies/hot pixels, with MLT, and simple OBJ based animation, and better camera control/behaviour.

that's my current priority, then it's the big beta3 with advanced file import and animation.

after that we can focus on small tweaks like these

Radiance

Oh man I cant wait to put my hands on it

radiance wrote:Hi guys,

I'm currently putting all my focus in developing beta2.1 which will fix most issues reported and provide, finally, fast rendering of caustics and scenes with no fireflies/hot pixels, with MLT, and simple OBJ based animation, and better camera control/behaviour.

that's my current priority, then it's the big beta3 with advanced file import and animation.

after that we can focus on small tweaks like these

Radiance

Can you confirm for the camera control : lens shift - the most important for arch viz , in short perspective correction?

hi,

i'll add a shift lens option to our todo list for beta3, otherwise 2.1 won't be out soon, if we keep adding requests to it.

Radiance

Sorry I miss the answer. Thanks , I'll be waiting for this for sure..

Another question not related to upcoming beta but generally it's about more explanation about the futures in cameras, and specific : Realistic**, what its behind this ? Realistic based on point and shoot cameras or (D-)SLR cameras for settings and adjusting parameters or just glare/bloom?