Latest path tracer testing

[Peter Milner]

I ran this one over night (15 hours and 2000 passes) and noticed a couple of issues.

1. If you look closely you'll see that the whole image is covered in little black dots.

2. The monitors are set as area lights and colour by object. They are on a seperate lighting channel but no matter how high I increase the level of the channel in the editor, the decal remains at the same brightness. The light given off though does increase illuminating the surrounding objects.

 

Peter

 

[Roy Hirshkowitz]

Ok-- the problem with the monitors is that the area light source wasn't properly aimed. By default, these point straight down. Once you go through the aiming procedure you get (mostly) correct results. Hint: if you want to aim these in place, draw a line from the midpoint of the screen, perpendicular to the screen in the direction you want the light to go. Use the end of this line to snap to during the Aim Light < procedure. Here's what I get after about 1/2 hour-- first just the monitor channel:

Then with all four channels:

There is still a small problem in your case with using a box as the screen. Since the surface area of the light source is important when calculating the brightness of the surface, the use of a box will more than double the surface area (halving the brightness.) Use a 3dface instead for best results.

[Peter Milner]

Thanks Roy. I did have a 3D face with a directed light at first but when I encountered the previous problem of the decal not showing when the screen was angled back, I changed it to a box and then forgot to point the light as well.
Sorry to make you do all the hard work for my mistakes.
Just the reflection thing to sort out now.

Peter

[Eric B]

Well that prompts 2 questions from me;

1) Am I to assume that the images in the monitors are HDR images then?

2) Since the majority of the problems appear to come from how the model is being set up and not so much how the AR5 nXt program is running wouldn't it be better to tweak and adjust the manner a User inputs an illuminated decal?

In other words, if an object has a decal image that is not HDR couldn't AR5 nXt understand that and make a behind the scenes adjustment to the object definition unseen by the User?

If there is some monkey business that is needed to use common graphic file types to make this illuminated decal work how about make the uncommon HDR image type the exception? Make it such that the monkey needs to work on the HDR decal and not on the every-day image file.

a) If object has a decal is the decal an illuminating surface?
b) If a = true is the decal not an HDR image type?
c) if a and b = true then convert the image so that it renders properly

It just feels like you are making many more Users and many more file types jump through unnecessary hoops to make this process render logically when it is the HDR image that is the exception.

[Roy Hirshkowitz]

Nope-- his monitors are standard RGB decals and did not require any tweaking (AFAIK). For most applications this isn't too horrible. (In fact, at the moment, nXt only has HDRI sky light and only spherical projections.)

Well calibrated HDRIs would be much better for this type of application-- RGB images, while not too bad for describing reflectivity-- are truly garbage in terms of describing emissivity. (HDRI images are probably lousy at describing reflectivity, BTW)

Problem is everyone's got a lot of RGB, a tiny amount of HDRI, and an even smaller amount of well-calibrated HDRI.

Coincidentally, Scott and I were just discussing this issue this morning. I may try a few things next week.

[Eric B]

Roy -- I do not see it as a problem that most Users have RGB and only a tiny number of HDRI. This is just how things are. Now, if there was some easy way to create/edit/use HDRI files that would help.

Looking into having RGB or CMYK images as the base decal type and HDRI as the exception when combined with illumination just makes the act of using the program easier - glad to hear that I was thinking along the same lines as both of you.