ajz3d

brians

jerry7
Same sample count in karma. But the Thin-Walled material has more noise.
What is the reason?

We assume...

• thin-walled = a thin object that can be viewed from both sides (eg a window)
  
• refractive = a "think" object which cannot have a viewpoint looking at a backface (eg a crystal ball)
  

Refractive objects have many more noise optimizations applied to them because of the manifold assumption (eg we reduce noise by clipping away lighting from backfaces etc...)

jerry7
How to reduce them?

What if you leave it as refractive (ie not thin walled), but set the IOR to 1?

jsmack
I dunno what's going on there, but there should be a few more categories in your tab menu.

fusion9
Whenever someone compare renders like these I just don't get it, what is the point you are trying to prove here?
That an almost 10 years old render-engine is faster than a not even 2 years old one?
Karma is a baby compared to how long RS has been around, plus Redshift sucked at retractions for a long time not sure why you aren't willing to give Karma the same patience. Should we compare Redshift 1 to current Karma XPU to see what happens?

I'm not saying that Karma shouldn't improve, it stills lacks a lot of common-place functionality but it's getting there and fast! also we should celebrate all the good things that's doing better than other render-engines, crypto mattes? incredibly fast to render, volumes? a breeze to setup and render, Volumetric lighting? a dream come true on how easy is it to use, Supporting USD features? better than anyone, I could go on...

mtucker
This usually happens because the edit LOP is higher up the LOP node chain, and when you change something in the Edit LOP, all the downstream LOP nodes also have to recook, resulting in slower interactivity. Do you still see this issue when the Edit LOP is the node with the display flag? A video (or better yet a hip file) could really help clarify the issue, since I have often used the Edit LOP and the performance is generally pretty good...