PDA

View Full Version : MR Area Light Vs Maya Software Area Light - Possible Bug?


drossxyu
08-22-2007, 03:54 AM
The first picture is a regular Maya Software area light. The second picture is a MR area light set by converting a Maya Software area light via the Mental Ray--> Area Light --> Use light shape method. It's kept at default settings. In both images the area light is set in the exact same spot, which happens to be in view of the camera. Notice how the mental ray image clips the area where the area light is positioned. No matter how big or small the area light is positioned it clips the image as if the square extended out infinitely from all sides. This makes it impossible to position an area light unless it's off camera without getting this strange artifact. Is there a reason for this?

phix314
08-22-2007, 09:50 AM
That's pretty strange.

I've never had this happen, but then again I always start with a spot light and convert to an area light. Try that and see if it happens. I read something a while back that said mental ray doesn't support maya area lights, hence the conversion option. It has apparently been changed (I've gotten warnings at render time saying that m.r. can use native areas) but I like using spots->areas.

royterr
08-22-2007, 05:52 PM
That's pretty strange.

I've never had this happen, but then again I always start with a spot light and convert to an area light. Try that and see if it happens. I read something a while back that said mental ray doesn't support maya area lights, hence the conversion option.

true, but in 8.5, area lights are supported in MR, in fact you have a MR section in it.
it renders good but i have alsow incountered drossxyu's problem, the area light seems to strectch to infinity.....don't know what's going on here.

drossxyu
08-22-2007, 06:07 PM
So I tried the ol' pre-8.5 method of converting a spotlight into an MR area light and it seems to have resolved the problem. What's funny is the help file says :

"The method of using a spot light to create a mental ray area light requires higher sample levels and has known quality and performance issues. The recommended method of creating a mental ray area light is to use a Maya area light."

Right..

sixbysixx
08-22-2007, 06:12 PM
Try to attach a Physical Light as a Light Shader to the MR area light...

drossxyu
08-22-2007, 06:37 PM
It seems like you can't attach a light shader at all to an MR Area Light that's been converted from a Regular Maya Area Light. It allowed me to with a point light and a spotlight-->MR Area light. Perhaps this isn't the thread to ask in, but what is a MR physical light used for? Is there an advantage to using it?

-F

sixbysixx
08-22-2007, 06:48 PM
I still find all area lights still behave slightly funny, but it feels like a MR area light with a Physical Light shader behaves more physically correct than most, but then there's also this: http://forums.cgsociety.org/showthread.php?t=293775

The setup below is a normal Area Light with a Physical Light attached

http://farmhousepost.com/weblinks/Physical%20Light.jpg

sixbysixx
08-22-2007, 07:19 PM
One thing there is with the Physical Light that I'm actually very curious about - maybe somebody knows: If you have an Area Light with the Physical Light attached and this Area Light is very close to a surface I get lots of noise, even with very high sample rates (1500 in this example).

-Why is this?
-Is it a bug?
-Anyway to avoid this?

http://farmhousepost.com/weblinks/PhysicalLightBug.jpg

royterr
08-22-2007, 09:49 PM
i really don't like that workflow:

create a Maya area light then activate the MR section then attach a physiacl light then raise your left arm....It's just so confusing! Why not have a simple MR area light?

phix314
08-22-2007, 11:27 PM
I'm not sure when the high/low samples come into computation, but what I've found is if you have the high samples be about twice your low, it renders noiseless. When it decides to use the low sampling is beyond me. For most scenes the high samples never get above 30.

I use the physical_light shader for most "important" lights in the scene. The way it reacts is very nice. For some set-ups, like parti_volumes, physical_lights are necessary.

royterr
08-23-2007, 12:03 AM
I'm not sure when the high/low samples come into computation, but what I've found is if you have the high samples be about twice your low, it renders noiseless. When it decides to use the low sampling is beyond me. For most scenes the high samples never get above 30.
.

isn't the low samples, the samples of the secondary rays? i mean the softness of the shadows in a reflective mirror plane for exemple?

phix314
08-23-2007, 01:18 AM
No. If that was the case, then sixbysixx wouldn't be having his issues. I'm thinkin the low samples are for those rays closest to the light.

I remember hearing about them and why they exist but I can't recall what they said. :(

phix314
08-23-2007, 02:07 AM
So here's a few tests.

I have a simple scene. One spot coverted to MR area light and a supplemental GI-only light. Area light intensity 500, quadratic decay.

1- GI, FG, area light at 3/2 (hi/low).
2- ", area light at 10/2
3- ", area light at 10/5
4- ", area light at 10/10

Added physical_light shader, set color to 2200. Took off area light intensity (0). Remained at quadratic.

5- ", area light at 10/5.
6- ", area light at 10/5, no physical_light, added RT shadows.


http://sgphix.com/3d/lighting_tests.zip

Maya 8.5

sixbysixx
08-23-2007, 12:10 PM
Added physical_light shader, set color to 2200. Took off area light intensity (0). Remained at quadratic.



As soon as you attach a Physical Light shader these controls of the area Light (intensity, decay etc.) don't have any effect any more. It is fully controled by the physLightShader now.
If it would have been implemented in Maya properly they should be greyed out of course, but:rolleyes:...

The Low Samples of an area light only come into play in reflections and refractions - since in my scene I was only using default Lambert, they shouldn't have any effect at all.

floze
08-23-2007, 01:22 PM
@drossxyu: The effect you are experiencing is the simple lack of a 'Dropoff' value in the regular maya area light. The physical_light has implemented it, it's called 'Cosine Exponent' (a cos_exp value of 0.0 in fact means 1.0 btw., if you want a very low cos_exp turn it down to 0.001 or something). Other than that it all works as expected.

If you are using spot-area lights (without physical_light), simply raise the 'Dropoff'.

This has nothing to do with the size of the area light or something, it merely is the fact that maya software does not tell you about narrowing the cosine distibution of the area light, and you suppose it's the 'correct' way.

@sixbysixx: To completely avoid this you would have to leave the high/low samples at 1/1, and use a fixed sampling rate instead, i.e. set the min/max sample level in the render globals to like 2/2. But this is not necessary in most cases as the artifacts you are experiencing only occur at very extreme situations, when the area light is very close to your objects.

phix314
08-23-2007, 09:39 PM
As soon as you attach a Physical Light shader these controls of the area Light (intensity, decay etc.) don't have any effect any more. It is fully controled by the physLightShader now.
Right.



The Low Samples of an area light only come into play in reflections and refractions - since in my scene I was only using default Lambert, they shouldn't have any effect at all.

I would have to disagree here. It is obviously apparent that the low samples have an effect regardless. In both your and my scenes nothing was reflective and yet they still showed as being noisy.


@sixbysixx: To completely avoid this you would have to leave the high/low samples at 1/1, and use a fixed sampling rate instead, i.e. set the min/max sample level in the render globals to like 2/2. But this is not necessary in most cases as the artifacts you are experiencing only occur at very extreme situations, when the area light is very close to your objects.

Again, would have to disagree here. I haven't tested this, but the sampling would only marginally fix the noisy light samples, at least with what I've done in the past. Besides, this would crank up the render times due to the increased sample rate, moreso than if just the light was increased.

sixbysixx
08-24-2007, 11:48 AM
Right.

I would have to disagree here. It is obviously apparent that the low samples have an effect regardless. In both your and my scenes nothing was reflective and yet they still showed as being noisy.

But that's not down to the Low samples. Believe me, the low samples only come into play with reflections...



@sixbysixx: To completely avoid this you would have to leave the high/low samples at 1/1, and use a fixed sampling rate instead, i.e. set the min/max sample level in the render globals to like 2/2. But this is not necessary in most cases as the artifacts you are experiencing only occur at very extreme situations, when the area light is very close to your objects.

This is interesting - I'm not sure I understand what's going on here though.
Is this effect due to some funny overlaying of QMC patterns, like a moirť then?
When I leave the area light samples at 1, indeed the noise goes, but it's far from physically correct, since it only takes one sample, right?
I had an interieur job, where I had to hide lots of area lights in little crevasses and I was really struggling with this noise - now I know there are workarounds that I didn't know of then (I'm still new to the world of 3d), but workarounds are always annoying and shouldn't be necessary in the first place.
If I understand this right, it's a MR bug, no?
http://farmhousepost.com/weblinks/AreaLightAdaptiveSampling.jpghttp://farmhousepost.com/weblinks/AreaLightFixedSampling.jpg

floze
08-24-2007, 01:16 PM
No. If that was the case, then sixbysixx wouldn't be having his issues. I'm thinkin the low samples are for those rays closest to the light.
That's certainly not true. 'Low samples', and respectively 'low level' or 'high sample limit', depending on what maya version you are using, means:

"[...]the sum of the reflection and refraction trace depth at which area light sampling switches from high samples to low samples. 0 means that no switching takes place and high samples are always used."


This is interesting - I'm not sure I understand what's going on here though.
Is this effect due to some funny overlaying of QMC patterns, like a moirť then?
When I leave the area light samples at 1, indeed the noise goes, but it's far from physically correct, since it only takes one sample, right?
I had an interieur job, where I had to hide lots of area lights in little crevasses and I was really struggling with this noise - now I know there are workarounds that I didn't know of then (I'm still new to the world of 3d), but workarounds are always annoying and shouldn't be necessary in the first place.
If I understand this right, it's a MR bug, no?
http://farmhousepost.com/weblinks/AreaLightAdaptiveSampling.jpg[/img][img]http://farmhousepost.com/weblinks/AreaLightFixedSampling.jpg
This only seems to happen with the physical_light, doesnt it? I'd stick with the regular maya lights instead, the physical_light is quite out dated and does not add much functionality that would justice it's use.

sixbysixx
08-24-2007, 06:09 PM
This only seems to happen with the physical_light, doesnt it? I'd stick with the regular maya lights instead, the physical_light is quite out dated and does not add much functionality that would justice it's use.

Yes, only with the physical light. I now tried your approach with the Spotlight.

I made a little real world box and photographed it (also made an hdr (http://farmhousepost.com/weblinks/CornellPhoto2Exp.exr) from it to make sure I'm not being tricked by camera response curves).
http://farmhousepost.com/weblinks/Lightbox.jpg

Then tried to make the same thing in Maya - getting there, but still not happy:
-Switching on Area light 'visible' doesn't do anything?
-decay seems too strong - burnout (I know I can control this and get it closer by using the compression in the mia_exposure, but that's not really the point of this exercise)
-The corners stay a bit too dark - a problem I always run into with interior renders. If I set the FG setttings really high it improves, but it still stays a problem
-Rendertimes are very slow, because of the high sampling rate of the area light and I still see some noise...

http://farmhousepost.com/weblinks/SpotAreaLightFloze.jpg

If anybody would be willing to have a quick look at my scene (http://farmhousepost.com/weblinks/AreaLightTest.mb)
and could come up with what I did wrong I would really thankful!

royterr
08-24-2007, 06:44 PM
-The corners stay a bit too dark - a problem I always run into with interior renders. If I set the FG setttings really high it improves, but it still stays a problem


try to bevel your corners.

phix314
08-24-2007, 08:36 PM
Well sugar plums. I'm out ;)

Thanks for the play-by-play guys.

MasterZap
08-25-2007, 12:01 PM
-decay seems too strong - burnout (I know I can control this and get it closer by using the compression in the mia_exposure, but that's not really the point of this exercise)


Are you at least using a proper gamma correction? If not, you can just stop right now trying to match to a photo.

/Z

sixbysixx
08-28-2007, 09:54 AM
Are you at least using a proper gamma correction? If not, you can just stop right now trying to match to a photo.

/Z


well - I think I figured that one out, yes.

-32bit float Framebuffer Gamma 1
-gamma corrected the colour swatches to .455 (mia material rg)
-miaExpSimple lensShader set to zero compression and Gamma 1

MasterZap
08-28-2007, 10:10 AM
well - I think I figured that one out, yes.

-32bit float Framebuffer Gamma 1
-gamma corrected the colour swatches to .455 (mia material rg)
-miaExpSimple lensShader set to zero compression and Gamma 1

And where is the 2.2 gamma to properly display it on your sRGB computer screen?

/Z

sixbysixx
08-28-2007, 11:06 AM
And where is the 2.2 gamma to properly display it on your sRGB computer screen?

/Z

:blush::blush::blush: Zap, I'm really embarrassed now! :blush::blush::blush:
I assumed that Maya applies in the viewport the same Gamma correction to float renders (via the Preview Options) as Photoshop, but I never tested it! When I batch render (this is what I usually do anyway) it looks completely different in Photoshop:scream:

Is there any way that Maya can display the Gamma of float renders in the viewport the same way that Photoshop does it?
This another reason I guess why so many People are still struggling with the Gamma issue.

This is the result I'm getting now - a lot better and I think good enough for me:-)

Now if anybody has some ideas of how to get the same result in less rendertime, while still reducing the dark corners effect and why I can't see the area light shape: here's the Scene (http://farmhousepost.com/weblinks/AreaLightTest.mb).

Thanks again - Christoph;o)
http://farmhousepost.com/weblinks/AreaLightPhoto_vsRender.jpg

royterr
08-28-2007, 03:38 PM
And where is the 2.2 gamma to properly display it on your sRGB computer screen?

/Z

ZAP, i am a little confused here:

what's wrong in setting a default framebuffer gama of 1, a mia_expsimple gamma default of 2.2, a gamma correction 0.455 node ?

should we apply a gamma correction node to color slots also, even if they don't have textures assigned to them?

should we apply a gamma correction node to bump maps (witch are deasaturated RGB maps) ?

sixbysixx
08-28-2007, 03:54 PM
ZAP, i am a little confused here:

what's wrong in setting a default framebuffer gama of 1, a mia_expsimple gamma default of 2.2, a gamma correction 0.455 node ?

Sorry Royter, that was my mistake: That setting of yours is correct if you're rendering 8 bit or want to view your float renders in the Maya viewport with a correct gamma. But when rendering proper float for post production you want to produce linear renders, i.e. no gamma, so in that case you don't want to apply a gamma of 2.2 with the lens shader.
When opening these files in Photoshop, Photoshop will automatically apply a gamma of
2.2 in order to display these linear images correctly.


should we apply a gamma correction node to color slots also, even if they don't have textures assigned to them?

If it is important for you that the color swatches are correct as you see them in the GUI, then yes, hence the mia_material_rg, otherwise you can just keep matching by eye until your renders look right.


should we apply a gamma correction node to bump maps (witch are deasaturated RGB maps) ?
No - Unless you plug that bump map texture into a colour slot I guess...

Emil3d
08-28-2007, 05:01 PM
Sorry Royter, that was my mistake: That setting of yours is correct if you're rendering 8 bit or want to view your float renders in the Maya viewport with a correct gamma. But when rendering proper float for post production you want to produce linear renders, i.e. no gamma, so in that case you don't want to apply a gamma of 2.2 with the lens shader. ...If only a gamma is applied to a float image you can consider its result as non destructive even if it is no longer linear. The good thing about gamma correction is that it is based on a standard algorithm that is used consistently between different applications. This means that the gamma effect can be easily reversed in any program without image distraction by simply applying the opposite values like 2.2 and 0.45 provided you keep track of gamma applications on the image and if not you can always simply relay on your eyes (have in mind that the algorithm is based on the human perception which means by liking the result you are applying the correct gamma).

With other color correction controls like contrast, curves, levels etc, after certain number of repeated corrections, the possible range of the pixel values (historam) of your image will narrow resulting in a lesser and lesser color correction flexibility which is a destructive correction. Both x8 bit and x32 bit are affected in the same way but with x32 bit you have a much larger range that will take much more hits before serious destruction.

MasterZap
08-28-2007, 05:08 PM
ZAP, i am a little confused here:

what's wrong in setting a default framebuffer gama of 1, a mia_expsimple gamma default of 2.2, a gamma correction 0.455 node ?


Nothing!

But that's not what he said. He said mia_expsimple_gamma = 1

should we apply a gamma correction node to color slots also, even if they don't have textures assigned to them?

Well, that's what the mia_material_rg does. And since Maya doesn't apply any gamma to the color swatches, I would say "yes". In principle, display gamma should apply not only to the render display, but swatches, which (AFAIK) it doesn't in maya, hence the "_rg" trick.

should we apply a gamma correction node to bump maps (witch are deasaturated RGB maps) ? In most cases, No.

Bump maps you generally want interpreted as their numerical values, i.e. the "half value" should really be "half" so you want to retain that. Since it isn't "light" you don't want to compensate.

/Z

sixbysixx
08-28-2007, 07:38 PM
If only a gamma is applied to a float image you can consider its result as non destructive even if it is no longer linear. The good thing about gamma correction is that it is based on a standard algorithm that is used consistently between different applications. This means that the gamma effect can be easily reversed in any program without image distraction by simply applying the opposite values like 2.2

Are you sure it's non-destructive on float images?

Did you read this quote by floze from the other thread:

Hence you should not 'bake' the gamma correction into a floating point image. This is wrong, as (for mathematical reason) the quantization happens between the 0.0 and 1.0 RGB values - this draws the higher dynamic range pretty much useless.

Imagine the whole dynamic range of your rendering extends from 0.0 to 3.0 RGB (everything >1.0 being displayed as 'white'), if you apply a gamma correction with the lens shader on a floating point framebuffer, you only gamma correct (quantize) values between 0.0 and 1.0 - all colors greater than 1.0 will not be implied, and this makes any afterward tonemapping or whatever high dynamic range operation wrong.

And besides, such 'wrongly' quantized floating point images will be displayed 'wrongly' by the most HDRI viewers. Because there is no non-linear floating point, and gamma correction is expected to happen on the HDRI viewer.

I have to admit I never tested this and I don't quite understand why a lens shader would only affect values between 0 and 1 - I just took it for granted that floze usually knows his stuff rather well.

Emil3d
08-28-2007, 10:59 PM
@sixbysixx, He, he. Thatís so funny. After you quote it, now I remember that I actually read Floze explanation recently but I guess I quickly forget stuff that I canít fully comprehend:). And Iím still not sure what he was saying.

I based my statement on my understanding about the gamma curve which is based mostly on theory and some experience, but like yourself, I have never made dedicated tests to prove this to myself. I will make some tests tomorrow when I go back to my place since Iím currently away from Maya.

My understanding about the gamma curve is that on a graph it is a line that always goes from the lower left corner to the upper right corner. This means that clipping of values is impossible. At gamma of 1 the line is straight from corner to corner and at other numbers it simply becomes a spline curve below or above this line as if manipulated with one control point, but equalizing of originally different values is not possible. The values simply will get shifted from one place to another but never equalized with the neighboring values which from any point can be scaled back to its original straight line position without destruction.

This is how I understand it so far. Correct me if Iím wrong.

floze
08-28-2007, 11:12 PM
Are you sure it's non-destructive on float images?

Did you read this quote by floze from the other thread:



I have to admit I never tested this and I don't quite understand why a lens shader would only affect values between 0 and 1 - I just took it for granted that floze usually knows his stuff rather well.
Aside from the technical aspect, as I dont know how the mia_exposure actually works and I didnt test that yet either, it does not make sense at all to apply this non-linearity to a supposedly linear image.

Hmm after re-reading that thing with the >0.0 <1.0 I realize I might have had something different in mind.. of course it should be possible to apply the 1/2.2 correction to values greater than 1.0. Hence, if the mia_exposure does not imply clipping of values greater than 1.0, it might be possible indeed to use that with a floating point framebuffer, still it would not make any more sense.

royterr
08-29-2007, 02:21 AM
But when rendering proper float for post production you want to produce linear renders, i.e. no gamma, so in that case you don't want to apply a gamma of 2.2 with the lens shader.


then what value should i apply to the mia_exposure_simple gamma?

royterr
08-29-2007, 02:23 AM
Well, that's what the mia_material_rg does. And since Maya doesn't apply any gamma to the color swatches, I would say "yes". In principle, display gamma should apply not only to the render display, but swatches, which (AFAIK) it doesn't in maya, hence the "_rg" trick.
/Z

how do i apply the gamma correction node to the color swatch of the mia_material?

Gabba
08-29-2007, 06:45 AM
@royterr: like other connections in hypershade. Middle click con the gamma correction node, drag and drop on the mia material and then set it to diffuse or drag and drop directly on the diffuse component you want to apply in the attribute editor. When done, set the color you want and the properly gamma correction.
And for the question about the gamma correction on the mia_exposure... it depends on what workflow you want to follow.

sixbysixx
08-29-2007, 10:05 AM
then what value should i apply to the mia_exposure_simple gamma?


To keep things linear - 1!

Just be aware that they will not display properly in the Maya viewport then and remember: this is for float renders ONLY!

As for applying gamma to swatches, you can also use the mia_material_rg (http://forums.cgsociety.org/showthread.php?p=4473629&highlight=mia_material_rg#post4473629) by Sphere| - it allows you to automatically de-gamma textures AND swatches

@floze: It still would make sense to use the mia_gamma on float renders for testing purposes - the way I understand it, this is the only way to preview those renders correctly in the Maya Renderview, no? I wish there was a little gamma preview slider in the Maya Renderview, including full support for HDR viewing...

royterr
08-29-2007, 04:07 PM
To keep things linear - 1!

Just be aware that they will not display properly in the Maya viewport then and remember: this is for float renders ONLY!

As for applying gamma to swatches, you can also use the mia_material_rg (http://forums.cgsociety.org/showthread.php?p=4473629&highlight=mia_material_rg#post4473629) by Sphere| - it allows you to automatically de-gamma textures AND swatches



thanks for the info.
if i am using a frame buffer default gamma of 1, and a mia_exposure gamma of 1, then what value should i apply to my gamma correct nodes?

sixbysixx
08-29-2007, 04:26 PM
thanks for the info.
if i am using a frame buffer default gamma of 1, and a mia_exposure gamma of 1, then what value should i apply to my gamma correct nodes?

You have to de-gamma your textures - either by setting the framebuffer gamma to 0.45 or by applying a gamma node of 0.45 or by using the mia_material_rg and setting the gamma to 0.45.

If you set the framebuffer Gamma to .45, Maya will re-apply the gamma after the render for non-float and apply nothing for float renders (meaning they stay linear)

With a framebuffer gamma of 1 you will have to apply a gamma after the render for non-float, meaning: setting the mia_exposure gamma to 2.2. For float renders you set the mia_exp to 1 in order to leave the files linear, but be aware that they will not display with the correct gamma in the Maya Renderview in that case.

This implementation of Gamma workflow is pretty awkward and far from intuitive and the fact that this isn't even properly documented is... oh well - you get the idea....:scream:

royterr
08-29-2007, 06:54 PM
You have to de-gamma your textures - either by setting the framebuffer gamma to 0.45 or by applying a gamma node of 0.45 or by using the mia_material_rg and setting the gamma to 0.45.

If you set the framebuffer Gamma to .45, Maya will re-apply the gamma after the render for non-float and apply nothing for float renders (meaning they stay linear)

With a framebuffer gamma of 1 you will have to apply a gamma after the render for non-float, meaning: setting the mia_exposure gamma to 2.2. For float renders you set the mia_exp to 1 in order to leave the files linear, but be aware that they will not display with the correct gamma in the Maya Renderview in that case.

This implementation of Gamma workflow is pretty awkward and far from intuitive and the fact that this isn't even properly documented is... oh well - you get the idea....:scream:



the reason i asked my question is becose i have a big scene with a lot of materials, that i made before knowing the gamma issue, where i have a light setup with mia_physicalsky/sun.
Now, i dont want to change the lighting setup or the mia_exposure or buffer values becose it will take alot of time to tweak all the materials all over again again.
i only need to fix my textures. so is there away to do this without touching the seetings i mentioned?

as for the Gamma workflow, i really don't understand how Autodesk allow themselves to deliver an unfinished design.

sixbysixx
08-29-2007, 07:51 PM
the reason i asked my question is becose i have a big scene with a lot of materials, that i made before knowing the gamma issue, where i have a light setup with mia_physicalsky/sun.
Now, i dont want to change the lighting setup or the mia_exposure or buffer values becose it will take alot of time to tweak all the materials all over again again.
i only need to fix my textures. so is there away to do this without touching the seetings i mentioned?

as for the Gamma workflow, i really don't understand how Autodesk allow themselves to deliver an unfinished design.

If your setup is float FB Gamma 1 Mia Gamma 1, and you only want to correct the textures, then just attach a .45 gamma node to your textures and that's it...
If you're changing your framebuffer to byte or if you want to preview the test renders correctly in the viewport, then you should also set the mia_lens shader gamma to 2.2.

floze
09-05-2007, 02:19 PM
I just had a strange experience, and I'm afraid the mia_exposure_simple is clipping the values?! I wish MasterZap could shed some light on this.. :shrug:

dagon1978
09-05-2007, 03:23 PM
One thing there is with the Physical Light that I'm actually very curious about - maybe somebody knows: If you have an Area Light with the Physical Light attached and this Area Light is very close to a surface I get lots of noise, even with very high sample rates (1500 in this example).


to avoid this problem we need the skylight portal in maya, but, AFAIK, this shader is not included in maya 9 :banghead:

royterr
09-05-2007, 04:06 PM
to avoid this problem we need the skylight portal in maya, but, AFAIK, this shader is not included in maya 9 :banghead:

i wonder why it's included in max and not in maya???

MasterZap
09-05-2007, 04:58 PM
I just had a strange experience, and I'm afraid the mia_exposure_simple is clipping the values?! I wish MasterZap could shed some light on this.. :shrug:

If your compression is 0, there should be no clipping. If you REALLY want to make sure no clipping is going on, set the knee to 1,000,000,000 ;)

/Z

MasterZap
09-05-2007, 04:59 PM
to avoid this problem we need the skylight portal in maya, but, AFAIK, this shader is not included in maya 9 :banghead:

The architectural.dll that ships w. max and maya 2008 are for all practical purpouses the same. The only difference is the level of "UI bling" applied on top of the shaders.

/Z

dagon1978
09-05-2007, 05:37 PM
The architectural.dll that ships w. max and maya 2008 are for all practical purpouses the same. The only difference is the level of "UI bling" applied on top of the shaders.

/Z

hey zap! that's great! ;) glad to be wrong :scream:

elvis75k
09-13-2007, 09:29 AM
The architectural.dll that ships w. max and maya 2008 are for all practical purpouses the same. The only difference is the level of "UI bling" applied on top of the shaders.

/Z

Jee... Portal light doesn't work here (maya2008):


CreateAreaLight;
setAttr "areaLightShape4.areaLight" 1;
setAttr "areaLightShape4.areaVisible" 1;
connectAttr -force mia_portal_light1.message |areaLight4|areaLightShape4.miLightShader;

results: PHEN 0.10 error: Shader 'mia_portal_light': Light direction must be 0 0 z

I've already try to get it to work but no lucky.. what's wrong, how fix?
I also read about a new fg mode "FORCE" but i cannot find it in the UI,
can you help to figure it out?

Thanks a lot MasteZap.

lazzhar
09-13-2007, 05:03 PM
Jee... Portal light doesn't work here (maya2008):


CreateAreaLight;
setAttr "areaLightShape4.areaLight" 1;
setAttr "areaLightShape4.areaVisible" 1;
connectAttr -force mia_portal_light1.message |areaLight4|areaLightShape4.miLightShader;

results: PHEN 0.10 error: Shader 'mia_portal_light': Light direction must be 0 0 z

I've already try to get it to work but no lucky.. what's wrong, how fix?
I also read about a new fg mode "FORCE" but i cannot find it in the UI,
can you help to figure it out?

Thanks a lot MasteZap.


I dont have it but 2 days ago was showing here in the Maya/Max 2008 launch how to do it with an area light then attach something like a MR shader to it. It was working without any problem.

dagon1978
09-14-2007, 02:03 AM
it's working well here too ;)

elvis75k
09-14-2007, 08:36 AM
it's working well here too ;)

..then you don't see the 0 0 z error? Can you give me a scene or a step by step guide to
create a portal light? I've just assigned a portal light as a lightshader into squared arelight
(visible) light shader tab of the mr attributes (just like the method for the mr physical light).
It's true that if you rise up the intensity the light take effect, but in the mia architectural
manual he say that default values are used..

saluti

Edit: nevermind.. problem solved.

dagon1978
09-14-2007, 06:36 PM
here's some quick tests with the new skylight portal

here you can see the old area light artifacts on the window:

(old) area light 8 samples 34s
http://img441.imageshack.us/img441/8922/al8s34sgz2.jpg
physical AL 8 samples 36s
http://img441.imageshack.us/img441/1227/phys8s36syf4.jpg

here you can see the new skylight portal (note that the pattern is very different from the previous area lights)
skylight portal 8 samples 39s
http://img441.imageshack.us/img441/6858/skyp8s39swe4.jpg

the skylight portal is a little bit slower than the old-style AL

(old) area light 64 samples 1m 24s
http://img441.imageshack.us/img441/4070/al64s1m24sob4.jpg
physical AL 64 samples 1m 25s
http://img441.imageshack.us/img441/5241/phys64s1m25snt0.jpg

but as you can see the colors in render are much better (it's using the sky/sun color instead of just a RGB or kelvin temp)
skylight portal 64 samples 1m 45s
http://img441.imageshack.us/img441/2059/skyp64s1m45soz1.jpg

...and you can use much less rays without problems
skylight portal 32 samples 1m 04s
http://img209.imageshack.us/img209/347/skyp32s1m04sye6.jpg

dagon1978
09-14-2007, 06:37 PM
now with FG (with AO details):

(old) area light 64 samples 1m 29s
http://img441.imageshack.us/img441/2287/alfg64s1m29scx5.jpg
physical AL 64 samples 1m 32s
http://img441.imageshack.us/img441/5746/physfg64s1m32snx9.jpg
skylight portal 64 samples 1m 48s
http://img441.imageshack.us/img441/5752/skypfg64s1m48sil4.jpg
skylight portal 32 samples 1m 10s
http://img209.imageshack.us/img209/9917/skypfg32s1m10ssz0.jpg

and now GI:

without AO
http://img209.imageshack.us/img209/8050/skypgi132s1m08snoaopw2.jpg
with traditional AO
http://img209.imageshack.us/img209/700/skypgi132s1m08saoek7.jpg
with the new AO with color bleeding (great feature for architectural renderings! ;) )
http://img209.imageshack.us/img209/6912/skypgi132s1m08saobleedro9.jpg

great work Zap! :scream: :D

Wolfganng
09-14-2007, 07:23 PM
..then you don't see the 0 0 z error? Can you give me a scene or a step by step guide to
create a portal light? I've just assigned a portal light as a lightshader into squared arelight
(visible) light shader tab of the mr attributes (just like the method for the mr physical light).
It's true that if you rise up the intensity the light take effect, but in the mia architectural
manual he say that default values are used..

saluti

Edit: nevermind.. problem solved.

im having the exact same problem , getting the 0 0 z error. Any idea what causes it?

sixbysixx
09-14-2007, 08:05 PM
Nice series of tests Dagon :buttrock:- can't wait to get going with it!

These features sound really cool and useful and I guess they can seriously crunch rendertimes on interiors an awful lot...

digones
09-15-2007, 01:07 AM
I'm in love with the portal!! hehe


Hey dagon, have you tried to output multiple passes with the new mia_material_x yet?

cheers

visua
09-23-2007, 02:08 PM
Okey here's an issue that I just can't get my head around,
playin with Dagon's scene rendering out an .exr (32x4) with
batchrender. FB gamma 1 to keep things linear (prev conv tiles and prev tonemap
tiles set to off), opening the file in photoshop and setting the gamma to 2,2 and adjusting the exposure so everything looks nice.

And I get these weird aliasing-artefacts around the window/opening? I've tried just about
everything I could think of, and the render looks just fine in renderview but when I
batch to float that ugly aliasing is there once again. Maybe it has somethin to do with the alpha since I've yet haven't manage to get the pysical sky to show up in batch. But if that's the case it should just affect the spheres against the black bg and not that upper window frame? I'm clueless...

http://www.nicz.net/daExr.png

Olegr
09-26-2007, 01:17 PM
@drossxyu: The effect you are experiencing is the simple lack of a 'Dropoff' value in the regular maya area light. The physical_light has implemented it, it's called 'Cosine Exponent' (a cos_exp value of 0.0 in fact means 1.0 btw., if you want a very low cos_exp turn it down to 0.001 or something). Other than that it all works as expected.


Is there any way to get dropoff on the area light without having to use the physical_light shader?

CGTalk Moderation
09-26-2007, 01:17 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.