PDA

View Full Version : luminous surfaces and antialiasing



nikfaulkner
12-31-2010, 04:39 AM
hey there,

i'm trying to remember an old trick to force lightwave to antialias (adaptive sampling) edges of 100% luminous surfaces. cant for the lfe of me remember how to do it. without it these surfaces have jagged edges

anybody know what i'm talking about?

n.

UltraViolet
12-31-2010, 11:53 AM
Interesting question, I always wondered WHY in the world LW have problem with this in the first place ??? :stumped:

nikfaulkner
12-31-2010, 11:58 AM
Hmmm. Thinking about it, it may have been the "limit dynamic range" option that fixed it. Have to try when I'm not just about to head out partying :) happy new year all !!!

XswampyX
12-31-2010, 12:15 PM
Edge transparency for full on 3D objects, or set up a uv map for the poly lights transparency channel and fade it on the edges.

Sensei
12-31-2010, 12:18 PM
Interesting question, I always wondered WHY in the world LW have problem with this in the first place ??? :stumped:

Luminous polygons, especially those with >100%, are exceeding 0.0... 1.0 range.

f.e. 5000% is 5.0 in floating point, so when it's anti-aliased (blended) together with 0.0, average is (0+5)/2=2.5, which is still higher than 1.0 - it's later converted to 255,255,255 in integer 24 bit RGB. And you have complete black in one pixel 0,0,0 and 255,255,255 in next..

nikfaulkner
12-31-2010, 12:20 PM
thanks sensei. so my theory about the "limit dynamic range" may work?

Sensei
12-31-2010, 12:21 PM
thanks sensei. so my theory about the "limit dynamic range" may work?

Of course.

erikals
01-01-2011, 09:16 PM
but not always...

(if so, render 2x size instead without AA (or little AA if moblur is used) then scale down)

jwiede
01-03-2011, 12:31 PM
Hmm, aren't the jaggies really occurring because too little AA is being used to give a smooth ramp for the luminous polys' edges? Wouldn't broader AA produce a smoother ramp, such that the normal "final output" gamma adjustment wouldn't yield jaggies?

I'm not sure I see how forcing "limit HDR" in these situations actually helps. Won't that just clamp the light values, thereby introducing a new, different set of issues (because the scene was adjusted for 5.0 light output yet rendered with only 1.0 light output)? Seems like "limit HDR" (in this case) just effectively moves the jaggies into the darker areas, instead of the bright ones. When he has to increase brightness in post to adjust for that, won't they just reappear elsewhere?

erikals
01-03-2011, 12:35 PM
...not sure how it works, but no, sometimes there is no other way than the trick in post #8

Matt
01-03-2011, 05:29 PM
Hmm, aren't the jaggies really occurring because too little AA is being used to give a smooth ramp for the luminous polys' edges? Wouldn't broader AA produce a smoother ramp, such that the normal "final output" gamma adjustment wouldn't yield jaggies?

I'm not sure I see how forcing "limit HDR" in these situations actually helps. Won't that just clamp the light values, thereby introducing a new, different set of issues (because the scene was adjusted for 5.0 light output yet rendered with only 1.0 light output)? Seems like "limit HDR" (in this case) just effectively moves the jaggies into the darker areas, instead of the bright ones. When he has to increase brightness in post to adjust for that, won't they just reappear elsewhere?

What Sensei said is why.

UltraViolet
01-03-2011, 05:40 PM
That's all dandy, Matt, but how come that in all these years of existance of this very problem that there is no any kind of automated native solution for it.

Is this problem actually unsolvable ? :stumped:

Dodgy
01-03-2011, 06:30 PM
It's like sensei says, you're trying to display pixels which even when AA'd are out of range within 255,255,255 colour space. You don't want it to do more than this normally if you're going to export to HDR formats, as the result will be wrong. If you're not using those formats, then Limit Dynamic Range gives you the result you want. That's the AUTOMATED solution.

Matt
01-03-2011, 11:38 PM
That's all dandy, Matt, but how come that in all these years of existance of this very problem that there is no any kind of automated native solution for it.

Is this problem actually unsolvable ? :stumped:

Until you're using a monitor that can display the full range of a linear image, then yes, it will always be the case. As for automating it, well, the only way is to have Limit Dynamic Range on by default, but then, those who work in linear space will not be happy.

Basically, as Dodgy has just said.

jwiede
01-04-2011, 03:48 AM
What Sensei said is why.

I'm not questioning Sensei's explanation of why it happens. I'm questioning whether turning on "Limit HDR" (hereafter "LDR") really helps in such situations, or just moves the problem around.

If the scene was designed such that the light needed to be set to 5.0 in the first place, turning on LDR will darken the image (clamping the light to 1.0). While this allows a smoother ramp for the AA'd pixels of the luminous poly itself, it also cuts down on the total light provided. Presumably that downwards shift will need to be corrected at some point (post?).

Darkening the entire image just triggers the typical low-light LDR banding problems. Normal LDR low-light banding might be able to "hide" in the dark areas, but since the 5.0->1.0 light output shift from turning on LDR must then be corrected by a brightness adjustment in post, any banding in dark areas will become accentuated. Seems like turning on LDR in such cases just trades bright jaggies for dark banding.

If the user has to do post work on the image anyway, a better workaround might be to generate a separate buffer for the luminous poly (making it unseen by camera in the main image buffer), apply a weak glow or blur effect to the luminous poly output image, then comp it into the main image. That'd allow them to retain HDR lighting values, but still give "soft" edges to the luminous poly at "final gamma" -- presuming they have post sw to do so.

Sensei
01-04-2011, 05:46 AM
Luminous polygons are really not guilty.
In fact any buffer type can emit light to GI scene. Because for GI, it's not fact of adjusting Luminosity is important, but final color exceeding 1.0,1.0,1.0 range (or lower than 0,0,0 in which case light will be removed from scene).
Special buffers for luminous data won't have sense.

Try by yourself - make node Constant > Vector 5,5,5 then plug to Diffuse Shading, turn on GI. or Constant > Scalar 5, plug to Diffuse or whatever else input..
This will have exactly the same effect as using Luminosity 500%..
So, special treating of luminosity have no sense.

What will help is just special trigger in AA settings in Camera Properties, mimicking Limit HDRI toggle. But working inside of AA routine, instead of all stored buffers.

jwiede
01-04-2011, 02:13 PM
What will help is just special trigger in AA settings in Camera Properties, mimicking Limit HDRI toggle. But working inside of AA routine, instead of all stored buffers.
I'm not convinced this issue is severe enough to merit dev work. Any decent compositor app could do the exact same thing quickly and easily given the render is properly split out into the necessary buffers. Is this issue really worth spending developer time to fix?

If there's any culprit here, I think it may be Newtek's "setting" 1.0/1.0/1.0 as a fairly weak output level for a luminous poly. If we didn't have to use values greater than 1.0 so frequently, this problem would be far less common. I think a more efficient solution might be to reset the arbitrary channel ranges so that 1.0 represents significantly brighter output.

DonJMyers
02-28-2011, 03:56 PM
Limit dynamic range button didn't work for me. Neither did upping the gamma of the original image and reducing the luminosity. :(

DonJMyers
02-28-2011, 04:13 PM
I experimented and found that if I changed the background color in Photoshop to exactly medium grey they alpha channel was much less affected.

toby
06-05-2011, 09:04 PM
If there's any culprit here, I think it may be Newtek's "setting" 1.0/1.0/1.0 as a fairly weak output level for a luminous poly. If we didn't have to use values greater than 1.0 so frequently, this problem would be far less common. I think a more efficient solution might be to reset the arbitrary channel ranges so that 1.0 represents significantly brighter output.
Calling a value '1.0' when it's really 10.0 won't help you at all. The limiting factor is *hardware*, the display. LW is capable of rendering values that displays don't support, and it should be.

The answer to this problem is education. As stated before, you *cannot* have values well above 1.0 that are visibly anti-aliased to values in the darker ranges, on todays' displays. There is absolutely nothing that Newtek, or Mental Ray, or Vray or Brazil or any other render developer can do about it, short of changing the values in your image. If they do that internally, automatically, it will undoubtedly change values that someone doesn't want changed, so they give you options like Limit Dynamic Range.

Limit Dynamic Range doesn't clamp light or luminance values, it clamps the rendered output, so the change in lighting is less dramatic than you think. Professionals usually won't use this option anyway, since it throws away potentially useful data.

Another option is to not render your lighting polygons visible to camera. Use substitute polygons with luminance values below 1.0.

You could also use polygons with low values but increase the GI intensity above 100%, but that can cause problems if cg lights are also being used. (bounced cg light will be higher than the original source)

What I prefer to do is the same thing that a real camera does; values above a certain point will bloom on the film. Use Bloom or Corona, or do it in your compositing app, and that gives you a smooth, realistic result.

Greenlaw
06-05-2011, 09:36 PM
This may help: set Oversample to 0.3 (make sure that's 0.3 and not 0.03.) This softens the object edges a little and prevents regions with high-contrast from going too jaggy. I'm not sure why this value isn't the default setting because it essentially mimics what used to be 'hardcoded' into the Lightwave renderer and it tends to produce the most pleasing aa edges. FWIW, this is the setting we always use at work.

Hope this helps.

G.