@lichtwerk I can't find the relevant thread in the chat, sorry. As for including the fix or not: Hm, yeah, good question. On the one hand, it does change the output, but on the other hand, the…
Hi @LukasStockner, I understand that this was deliberate, but can you explain why? What's the use case where someone would want flat washed-out shading that's inconsistent with EEVEE?
Normal…
Yes, I also agree that going with sd->N
is correct here. It's unfortunate, but well, non-physical tricks only get you so far. Arguably we have this issue with some other features as well (such as the classic "object is visible to diffuse/glossy rays, but not shadow rays" topic), but normal maps in particular feel like something so basic that they need to just work without any MIS-relayed traps.
Can't reproduce this in 3.3, 3.6 or 4.1, so I'll assume that it's fixed for now. If someone can still reproduce this, feel free to reopen.
As of 4.1, there now is an option to disable the normal correction, so I think we can close this.
Can't reproduce this in 3.3, 3.6 or 4.1, so I'll assume that it's fixed for now. If someone can still reproduce this, feel free to reopen.
For the record: This is/was not a bug, the normal correction was deliberately added and is working as intended.
For cases where it is not desired, 4.1 now has a "Bump Map Correction" option in…
Can't reproduce this in 3.3, 3.6 or 4.1, so I'll assume that it's fixed for now (3.x got a big shadowcatcher rework, so it would make sense). If someone can still reproduce this, feel free to reopen.
I'm pretty sure that this is a similar issue as in #70114, the suggested fix there also fixes this.
I'm pretty sure that this is the same issue as in #70114, the suggested fix there also fixes this.
I think I found the issue here:
After the first view syncs the data into Cycles, it calls BlenderSync::free_data_after_sync
, which frees the object caches (and therefore also the particle…