Hi there;

I've been playing with the physical sun/sky model that I can create at the OBJ level recently, and am interested in using it in Karma, but it doesn't seem like the sky map params get imported using the Scene Import nodes. I'm curious if there are plans afoot for an analogous physical sky model on the Solaris side of things in the future?

Thanks!

You're correct that we don't import the sky map into Solaris via Scene Import at present. It's a limitation we're aware of, but it's not something we've actively been working on.

Out of curiosity, would you be satisfied with a Solaris-only (i.e., completely decoupled from the OBJ setup) solution? Would you be satisfied with a Karma-only solution? Or is the link to the OBJ setup particularly important to you?

Hey there Rob;

Thank you for this! To answer your question, I'd be happy with either of the options you mention (Solaris-only and/or Karma-only).

My use case is for an arch-vis-like setup, in which I would like to specify an arbitrary time of day and have the environment light spilling in through my windows change accordingly. I'm trying very hard to stay in Solaris as much as I can, and am using Karma to render. Critically, I am interested in representing light as "physically plausible" as possible, which for me means that I consider the Intensity parameter on my lights to represent candelas/meter squared, though I don't think that's important for this particular question.

I discovered the sun/sky setup on the obj side, and it seemed like it might solve my need perfectly, but then discovered it doesn't work in Karma. My game plan at the moment is to start collecting IBLs over the course of several days, to achieve roughly the same end goal. I'm particularly interested in being able to roughly suggest "clear sunny" or "overcast", and had imagined I might be able to do some tricky lerping of the color and intensity of the sun-vs-sky setup to get something kinda-sorta close for this. I do not need to see the sky directly in most cases.

All this is more than I imagine you're interested in, but I offer it to describe what I'd like to do - I'm flexible about how I get there. I would like to avoid having to involve another renderer in the mix, though.

Thank you for that detailed feedback, it's very useful to know what solutions would/wouldn't be appropriate. I don't want to raise any false hopes that this will be addressed in the very short-term, but it does remain on the radar!

Hallo Im just here to ask if this is being worked on ?

NicTanghe
Hallo Im just here to ask if this is being worked on ?

We've been chatting about a new sun/sky light for Karma for a while. Part of this would include Scene Import being upgraded to provide a (hopefully reasonable) translation of the /obj version.

Hi @robp; this is nice to hear!

Since the time I first asked this question, I forged ahead with the solution I described above; I wanted to offer a description here in the event that whomever is developing this for Karma finds any of it interesting:

"Physical" to me indicates some ability to represent the sky in absolute - rather than relative/arbitrary/unknown - units. Physical brightness units (lumens, CD/m2, etc) necessitates a camera with physical properties, which is to say shutter/fstop/ISO parameters that do something meaningful with exposure in addition to depth of field and motion blur. It seems like *some* of the necessary bits and bobs to do this are laying around in Houdini, in various states of function (e.g. the Physical Lens shader worked, then didn't, then I found an Exposure parameter on the camera itself that kinda-sorta helped).

To tape all this together, I:

• Spent a month climbing onto the roof of my apartment every hour throughout the day to capture unoccluded IBLs of the sky, also measuring sky brightness with a light meter and noting the LUX value. I built a Python script that adjusts pixel values to absolute nits, roughly following the procedure outlined in this paper. [blog.selfshadow.com] Together, this collection of IBLs is my "physical sky", and I set time of day and overcastness by lerping.
  
• I have a scene file that places a grey card near the subject at which my USD camera is pointing, and renders it at 32-bit depth. This yields (most of the time) a very blown-out image that I then evaluate using Python, and algorithmically choose "autoexposure" values (shutter/fstop/ISO) based on models common to dSLRs like "shutter priority" or "aperture priority". I geeked hard over this part of it and I'm proud of it.
  
• I use these calculated values to set the various parameters on my USD camera. Because there's (currently) no notion of ISO, I create this attribute on my camera, then use it to drive an exposure compensation.
  
• I captured grain profiles from a Canon 5D, I select amongst these based on my calculated ISO and composite them into my image. This could easily be driven more artistically with a Grain COP node, but 1) I wanted to be as physically-based as possible and 2) I figured that Grain node isn't terribly sophisticated and doesn't try to mimic real physical grain.
  

I'm happy with the results I get [www.instagram.com], I wish my setup worked a little more like a real dSLR where 'autoexposure' can be calculated without needing a prerender, but to do this I need to actually evaluate my sky dome...with a Physical Sky light in Houdini, much of this math can be precalculated and solved without needing a grey card prerender.

I realize there's probably not a huge audience trying to do what I'm trying to do...there's also not many solutions for what I'm trying to do either. It's neat to me that I CAN do this in Houdini.

dhemberg
"Physical" to me indicates some ability to represent the sky in absolute - rather than relative/arbitrary/unknown - units. Physical brightness units (lumens, CD/m2, etc) necessitates a camera with physical properties, which is to say shutter/fstop/ISO parameters that do something meaningful with exposure in addition to depth of field and motion blur. It seems like *some* of the necessary bits and bobs to do this are laying around in Houdini, in various states of function (e.g. the Physical Lens shader worked, then didn't, then I found an Exposure parameter on the camera itself that kinda-sorta helped).

Physical can also be unitless. There are many physical properties that are unitless as they are ratios or other values where the units have canceled out. Light colors are unitless because they correspond to pixel values. In a real camera the pixel values depend on ISO speed. In CG, the ISO has been factored out leaving just exposure value. EV is a unitless value--it only has a physical value at a given ISO.

jsmack
Physical can also be unitless. There are many physical properties that are unitless as they are ratios or other values where the units have canceled out.

Of course I understand that; my intent wasn't to say "this is how it SHOULD be", and certainly not "this is the only way that is correct". I said I wanted to simulate the real world. I wanted to build a system that behaves the way I understand it to behave as a real-world photographer; I wanted knobs that behave the way the knobs on my real Canon 5d behaves. Of course I understand that in a different scenario these controls are wholly uninteresting.

It's fine if folks want to be disinterested in it - it's clear you aren't interested in it. There's no need for you to 'out pedantic' me here - I had a thing I wanted to make, I couldn't make it without building what I think are interesting tools, I wanted to share. That's it.

dhemberg

jsmack
Physical can also be unitless. There are many physical properties that are unitless as they are ratios or other values where the units have canceled out.

Of course I understand that; my intent wasn't to say "this is how it SHOULD be", and certainly not "this is the only way that is correct". I said I wanted to simulate the real world. I wanted to build a system that behaves the way I understand it to behave as a real-world photographer; I wanted knobs that behave the way the knobs on my real Canon 5d behaves. Of course I understand that in a different scenario these controls are wholly uninteresting.

It's fine if folks want to be disinterested in it - it's clear you aren't interested in it. There's no need for you to 'out pedantic' me here - I had a thing I wanted to make, I couldn't make it without building what I think are interesting tools, I wanted to share. That's it.

After reading the rest of your post, I get what you're after, and that you already knew that. I know many also want to model the scene using physical units. My point was that there's more than one meaning to 'physical' here. A physical sky is so because it's modeled physically--the intensity in this model just happens to be based on some nominal exposure value making it unitless.

I think what you're trying to do is neat and allows you to model some scenes that would be difficult without measured intensities such as combining indoor and outdoor lighting. A challenge you may face is that many renderers use importance sampling which is based on deviation in pixel values--which requires the render buffer to be properly exposed to work. Have you tried scaling the intensity of the image with the camera's exposure setting based on the computed exposure rather than as a post process? Or maybe that's why you're after the precomputed values for the physical sky.

a work around for me was to just use the Sky Environment Map COP as a texture for the solaris Dome light.

for example reference in the Texture parameter op:stage/cop2net2/skyenvmap1