## How can this noise be cured?

Clarisse related tips and tricks

### Re: How can this noise be cured?

Hi Refik,

if you use the Alembic tree (faster method), you cannot use the "Primitive Center" option. You will have to stick to "Random" distribution, toggle on "Use Density" and play with the Density value. This method is not precise but will work for far away trees (more flexible too as you can increase or decrease the density).

Hope this helps - I apologize for the confusion
Greg

gjennings

Posts: 150
Joined: Sun Feb 28, 2016 5:53 am

### Re: How can this noise be cured?

Thanks gjennings!

In general, this is all too complicated. There are too many unnecessary movements over ordinary trees. I'm already afraid to imagine how this can manifest itself in other similar situations (where a complex multiple geometry is).

We often create our animated trees in SpeedTree (sending them to Alembic) - and naturally we do not have to look for different solutions to such simple problems - they simply do not arise)

We just import these alembics into the redshift and do not have any similar problems with this ..) And this applies to any such heavy geometry.

I just look deeper into this problem, you have already explained to me from what it is happening (it's not in the trees if you do not take this particular case) - and I understand that this will be a big problem for us unfortunately ..

Now I'm just afraid to use Clarisse in big serious projects (but I really want to)

But in any case, thank you all for having dealt with me together on this. I hope that in due course developers will find a solution how to optimize this, and I'm looking forward to it )
Refik

Posts: 23
Joined: Mon May 14, 2018 3:01 pm

### Re: How can this noise be cured?

Still wonder what the problem is ..
By nature all pathtracer/unbiased engines introduce noise at first..
Redshift is using biased calculation like VRay which can solve many of the noise issues (but does have a other problems)

I would try to work with a different light setup, does the env light only act as primary source or do you have some sunlight as main shadowcaster ?

I could also think of the HDRI not having a very clear area of high EV stops ..it should have at least 16 or more EV's to cause a nice shadow
Try a parallel light and see if that noise still happens
Also try change the offset ray parameter..maybe some very close mesh elements act as flicker ..depending on the scene scale

Have you identified the primary aov that contains the flickering ?
There are still options but I would have to debug the scene myself ...
mdkai

Posts: 231
Joined: Tue Oct 07, 2014 7:24 pm

### Re: How can this noise be cured?

Good time !

Partly I figured this out - only the installation of very high parameters of AA and IBL samples can help. Yes, and the sun is also used (LightPhysicalDistant). Hdri also uses a high EV range (equal to 16), they are used in other render engines - with this, everything is fine.

Scenes can be sent only in the form of an array of trees and the main surface - what they stand for (without different maps such as diffusion)
Refik

Posts: 23
Joined: Mon May 14, 2018 3:01 pm

### Re: How can this noise be cured?

I think it shows a bit how pathtracer in general work ..clarisse is a bit special because it decouples the AA value with the overall sampling of all sampling attributes by default.
This means that the AA samples would affect geometric events in the pathtracer like DOF and motionblur as well as the edges of course. But not light, texture or surface sampling.

This speeds up a lot compared to other pathtracer renderengines like Arnold where the AA samples will be the final multiplier for all values thus can be slower.
You can however have that same behaviour if the oversampling value is not zero (which it is by default )
In that case all values will be multiplied by the AA samples and result in slower but also cleaner render

So there really would be no need for high AA samples unless you render DOF or Motionblur directly

You can always just increase the multiplier for the lightsampling which can result in cleaner sampling but not to intense for the overall render time.

The ray bias is a value that can help if surfaces are too close together an cause the common z-fighting or flicker

Very small numbers or very large ones can cause it,but this is scale dependend ..is your scene actual real world scale ?
By raising the value of the bias you can terminate the next ray that bounces of the surface if a specific distance is not met.
Though clarisse offers a extremely wide range of precision this could still help if tiny leafs are too close together and prevent flickering...

Feel free to post any scene if you can for others to have a look at and verify issues of all sorts. Of course only if that does not violate any NDA or licence
mdkai

Posts: 231
Joined: Tue Oct 07, 2014 7:24 pm

Previous