PDA

View Full Version : This has got to be a render bug.



Snosrap
02-06-2018, 09:27 PM
Ok, there has been a lot of buzz about 2018 PBR and noise and fireflies. And I get it, but this has got to be a bug. There is no reason there should be random white fireflies on very matte surfaces as shown in the attached render. I'm rendering @5K and VPR does not reveal these issues prior to rendering.

Render @ 25% of 4992 x 4992
139981


Render @ 100% showing clearly the issue.
139982

Sure I can PS these out, but there is no way AS should miss these pixels.
139983

What's going on?
Was the noise filter a late addition as a band aid to help correct the issue with the render engine?

Sensei
02-06-2018, 11:37 PM
Programmers/electricians method of detecting cause: disable feature one by one, until wrong effect disappears.
Start from disabling Adaptive AA, disabling GI, disabling multi-threading, Polygon Intersection Mode, etc. etc.

After you will identify source, you will have to prepare test scene for NT developers..

CaptainMarlowe
02-07-2018, 01:06 AM
You can also check the polygon intersection mode. There can be artefacts between tiles if set on fastest. You should get a try with watertight and double precision, it can help.
https://docs.lightwave3d.com/plugins/servlet/mobile?contentId=1855527#content/view/1860271

UnCommonGrafx
02-07-2018, 03:37 AM
Check your scene for a light in front of the camera.
That is to say, does a light cross the camera's plane, is the camera looking through a light?

This is a theory I'm working on about some of the fireflies: if your camera goes through a light, fireflies are created.
You can vary this by making the light bigger, and thus less fireflies. To that end, some of the fireflies can be somewhat controlled.

Or so show my tests.
Robert

aperezg
02-07-2018, 05:26 AM
I saw that in surfaces that have Principal BSDF material.
I think is the specular option, I will check later.


Edit.
I checked, but I'm not sure, sometimes appear and others times disappear

MarcusM
02-07-2018, 06:42 AM
I make simple test I think this hot pixels might be reflections of another reflections of light and something more in BSDF.
Scene with one distant light, 16 AA

Standars shader, no GI:
139991

Principled BSDF, with GI, reflection and recurion sampling on 1:
139989

Principled BSDF, with GI, reflection and recurion sampling on 4:
139990

Snosrap
02-07-2018, 07:08 AM
Programmers/electricians method of detecting cause: disable feature one by one, until wrong effect disappears.
Start from disabling Adaptive AA, disabling GI, disabling multi-threading, Polygon Intersection Mode, etc. etc.

I don't have time for that. :) I've bugged this with NT.


You can also check the polygon intersection mode. There can be artefacts between tiles if set on fastest. You should get a try with watertight and double precision, it can help.
https://docs.lightwave3d.com/plugins/servlet/mobile?contentId=1855527#content/view/1860271

Yeah I looked at that but I though that was just where polygons come together. This is one big polygon therefore the tiles are not intersecting any.


Check your scene for a light in front of the camera.
That is to say, does a light cross the camera's plane, is the camera looking through a light?

This is a theory I'm working on about some of the fireflies: if your camera goes through a light, fireflies are created.
You can vary this by making the light bigger, and thus less fireflies. To that end, some of the fireflies can be somewhat controlled.

Or so show my tests.
Robert

Yes I do have lights in front of the camera. But that is a huge advantage of 3D graphics! :)

For now I'll fix this in post. :(

Snosrap
02-07-2018, 07:12 AM
I make simple test I think this hot pixels might be reflections of another reflections of light and something more in BSDF.
Scene with one distant light, 16 AA

Standars shader, no GI:
139991

Principled BSDF, with GI, reflection and recurion sampling on 1:
139989

Principled BSDF, with GI, reflection and recurion sampling on 4:
139990

In my early testing with similar scene I did notice hot spots that looked like errors but on closer inspection they were very small reflections of other spec hits. (Which was cool!) What I'm dealing with here I think is a rendering artifact - error. And if AS is looking at adjacent pixels it should clean this pixel up IMO.

MarcusM
02-08-2018, 02:30 AM
...And if AS is looking at adjacent pixels it should clean this pixel up IMO.
After few tests in LW 2018 and LW 2015.3 it is clear to me this is fault of new shaders/renderer.
In standard material specular reflections are pixelated, in BSDF hot pixels are in stnage places.

In 2015.3 specular reflections are smooth and nice:
140014

Snosrap
02-08-2018, 07:51 AM
After few tests in LW 2018 and LW 2015.3 it is clear to me this is fault of new shaders/renderer.

I agree! In my case how can a bright white 1 pixel hotspot ever be generated in a tan matte wood finish?

Axis3d
02-08-2018, 08:07 AM
In standard material specular reflections are pixelated, in BSDF hot pixels are in stnage places.

140014

When I first started rendering reflective surfaces, I noticed that reflections that were image maps looked pixelated. If you go into the Image Editor > Source Tab > make sure Use MipMaps is checked. If not you will get pixelated image reflections.

I have not noticed that ray-traced reflections look pixelated, though.

MarcusM
02-08-2018, 09:19 AM
When I first started rendering reflective surfaces, I noticed that reflections that were image maps looked pixelated. If you go into the Image Editor > Source Tab > make sure Use MipMaps is checked. If not you will get pixelated image reflections.

I have not noticed that ray-traced reflections look pixelated, though.

I have done exteremly simple examples showing problems. Good to look better on them... Your last quote is not full and can be misleading.

Maybe in Snorsap case this have connection with mip maps.

aperezg
02-08-2018, 10:09 AM
After made some test.
I can't find how fix it.

The white pixels continue existing.
140018

In standard materials like version 2015.3 the white pixel disappear.
140020

In BSDF material appear.
140021

Myagi
02-08-2018, 11:22 AM
In BSDF material appear.

If you render the exact same scene again (maybe as a limited region of only the floor inside the original image size), are the white pixels in the exact same locations or do they change?

MichaelT
02-08-2018, 12:35 PM
Those fireflies (as they are called) are typically caused by caustics, or "hot" pixels. (It has many names :) )
You can control it with limiting the dynamic range to some degree.

RebelHill have made a good video about it here: https://www.youtube.com/watch?v=I5wC8xRrDBA

MarcusM
02-08-2018, 01:50 PM
Increasing Reflection Samples to very high value (16,32) solving hot pixel problem in BSDF materials, but multiply render time.

MichaelT
02-08-2018, 02:13 PM
I wonder if we should begin sending in scenes (or something that reproduces the same issue) to the bug report. Maybe that would help lifting this issue? Because when so many people are having the same issue, it really doesn't matter if we are doing it wrong. Either they need to explain it better, or they have a real issue they need to address for the next patch.

aperezg
02-08-2018, 02:35 PM
I Found the same bug in LW 2018 docs. By the way.
Principled BSDF page.

140026140027140028140029

https://docs.lightwave3d.com/display/LW2018/Principled+BSDF

jwiede
02-08-2018, 03:57 PM
or they have a real issue they need to address for the next patch.

These are happening so often that they're a "real issue" regardless.

Forcing users to repetitively build a nodal HDR limit filter most times ray-traced reflection is enabled is just bad UX. Further, if it's the same filtering required over and over, it shouldn't be nodal at all, coding and compiling it directly into the engine will be MUCH more efficient (both in render perf, and in UX workflow efficiency).

As a short-term workaround, requiring users (briefly) to build such filters nodally is "tolerable". It is not an acceptable lasting solution.

Snosrap
02-08-2018, 08:03 PM
I Found the same bug in LW 2018 docs. By the way.
Principled BSDF page.

140026140027140028140029

https://docs.lightwave3d.com/display/LW2018/Principled+BSDF

Yeah - I noticed that too. :) Thing is, everything else looks so damn good were it not for these darn hot spots!

lardbros
02-09-2018, 02:40 AM
There seems to be some bad advice floating around.
Turning mipmaps on may smooth out pixelated reflections, but it's not the cause of it.
The reason you'd have pixelated reflections is because your MIS resolution is too low. Turning that up in your environment light will get rid of any pixelation in reflections.
If you're not using an environment light, then check the same setting in the GI tab. The MIS should be equal to the backdrop image resolution. For rougher surfaces you can reduce the resolution of your MIS accordingly.

As for the fireflies, it does seem to be an issue with many PBR renderers... And hoping that a similar solution as Arnold can be put in somehow. I think Arnold clamps all secondary reflections and refraction rays. Unfortunately it can lead to slightly more dull looking and unrealistic renders.

gerardstrada
02-09-2018, 02:54 PM
Just in case, there's a way to go from here

https://s18.postimg.org/hqvgad2bt/AASC-unclipped.jpg

to here

https://s15.postimg.org/9dhy9w0fv/AASC-softclipped.jpg

without clamping any dynamic range. I proposed this simple method with DP FNE here:

http://forums.newtek.com/showthread.php?71751-Extra-Buffer-nodes&p=1510469&viewfull=1#post1510469

They could implement something like that as a checkbox (just like Limit Dynamic Range option) affecting final render and internal buffers ...or provide better SDK support for Denis' node pixel filter :)

As for the mipmaps, there's a couple of interesting methods from Hery:

https://graphics.pixar.com/library/BumpRoughness/

notice there's an implementation with Open Shader Language code there.

and Dupuy:

https://hal.inria.fr/hal-00858220v1/document
http://blog.selfshadow.com/publications/s2014-shading-course/dupuy/s2014_pbs_leadr_slides.pdf

also with an implementation code:

https://github.com/jdupuy/dj_brdf



Gerardo

lardbros
02-10-2018, 08:30 AM
As usual, great post there Gerardo!

Do you ever log feature requests with all of these bits of information?
If not, I really wish you could :D

You clearly have a very deep understanding of rendering and how to fix things, but it would be great if we could get some of this tech into LightWave natively!

gerardstrada
02-10-2018, 09:18 AM
Haven't updated to LW2018 yet but I'm sharing the idea and implementation just right there for anyone who want to take it. I won't charge for it, so if someone find it interesting, please go ahead! :D Guess they check forums from time to time for new ideas as well... for example, the way adaptive sampling threshold works now was taken from here:

http://forums.newtek.com/showthread.php?119485-Why-is-the-quot-Adaptive-Sampling-quot-pass-so-slow&p=1144504&viewfull=1#post1144504

I wouldn't be able to "prove the point" if we wouldn't have DP Filter Node Editor in the way it works up to v2015, so it's a useful way users can contribute with ideas. Though as you say, it would be great if these features could be implemented natively as well, render would be faster because less samples would be needed to get smoother results.



Gerardo

lardbros
02-10-2018, 09:38 AM
Did they take your idea for adaptive sampling and use that in 2015 or the new 2018 version?

I posted a feature request with your forum posts in, so maybe I'll do it again for this stuff? :) I hope you don't mind?

gerardstrada
02-10-2018, 09:51 AM
LW uses that way since v11.x up to last v2018. Nice thing they did was to link the threshold calculation to output space in CS panel, so threshold takes into account our output space.

So it was you?! it was a GREAT idea! :thumbsup: Sure! go ahead! hope they find it interesting :)



Gerardo

dyls_E
01-30-2019, 08:21 PM
LW2019 still does it.... sigh. that was the main thing i was hoping they would fix. there is a 'despike' option now, one method only works on stills and the other wrecks other parts of the render... super annoyed. looks like i will continue using 2015 whenever i have an animation job. I love everything else about 2018/2019 (well there a few bugs in the renderer still, but nothing compared to the 'spikes' ) but it's just wrecking all my renders and just don't know what to do.

RPSchmidt
01-31-2019, 07:32 AM
I don't have time for that. :) I've bugged this with NT.



Yeah I looked at that but I though that was just where polygons come together. This is one big polygon therefore the tiles are not intersecting any.



Yes I do have lights in front of the camera. But that is a huge advantage of 3D graphics! :)

For now I'll fix this in post. :(

What are your light samples set at?

It may just be a matter of bumping up your light samples a bit.

I do feel that this is an issue with the renderer; although to be fair, in other PBR-based 3d programs I use, I also get fireflies from time to time. Not usually to the extent I've seen with Lightwave and they are usually easier to solve.

Tim Parsons
01-31-2019, 04:22 PM
LW2019 still does it.... sigh. that was the main thing i was hoping they would fix. there is a 'despike' option now, one method only works on stills and the other wrecks other parts of the render... super annoyed. looks like i will continue using 2015 whenever i have an animation job. I love everything else about 2018/2019 (well there a few bugs in the renderer still, but nothing compared to the 'spikes' ) but it's just wrecking all my renders and just don't know what to do.

Despike does the trick for me. I haven't done any animations yet but for the stills I've created it works really well. The default setting doesn't do much, but 0.1 and 0.2 really work great.

jwiede
02-02-2019, 07:08 PM
Despike does the trick for me. I haven't done any animations yet but for the stills I've created it works really well. The default setting doesn't do much, but 0.1 and 0.2 really work great.

Is despike's filtering supposed to be "stable" for animation uses? It doesn't appear to be, at least in some quick testing. Anyone else tested this?