- User Since
- Jan 13 2019, 6:00 AM (174 w, 4 d)
Mon, May 16
Fri, May 13
Sorry, I was being a moron. Didn't know about this so assumed I was in the render properties panel 💩
Thu, May 12
Mon, May 9
yes, seems to be fine now thanks.
Mon, May 2
If anyone is having this issue. For the time being here's a script you can use to automatically add the workaround to all principled nodes with SSS fed from another node:
@Ethan-Hall (Ethan1080) Could you chase this one up? Also the ammendments you made to the task description seem to be quite cryptic compared to the original description of the problem.
Sat, Apr 30
Fri, Apr 29
and if the original is marked as fake user, then the copy gets a fake user, but the original loses it's fake user and shows 0 users instead:
here's what mine looks like after choosing the full copy option:
Hi Germano. Perhaps it's related to the file originally being created in an earlier version of Blender. I've attached a cut down version of the file. open the 'comp master' scene and then choose the full copy option. A zero should appear next to the original 'comp master' indicating it has no users and will be deleted on file open.
Thu, Apr 28
Mon, Apr 25
Thanks. Perhaps this also shed some light on the other bug report you looked at regarding the peristent data being partially lost when going full screen. Perhaps render.render is being called each time full screen is entered/left.
Sat, Apr 23
you can close this down for now if you like. I'm still getting different noise even with adaptive disabled, but it might be to do with the use of handlers in my addon (even though nothing is done other than file management). I won't have chance to test for a few weeks, so I'll re-open a new one at some point.
Fri, Apr 22
You can do this by using a scale node set to render size, reduce the render size and increase the backdrop size. This keeps the image the same size but lowers the resolution (making anything upstream of the scale node calculate much faster).
Thu, Apr 21
Thanks for checking. I can't share this file, but I'll upload a simple test file asap.
Apr 8 2022
Thanks. I'm not sure individual light passes per light group would solve the issue because it would still require an unfeasible number of denoise nodes, particularly if you have 10 light groups for example, as you'd need 90 denoise nodes to achieve multipass denoising. Perhaps if the light groups could be represented by unique colour in the upper range of the dynamic range (colours chosen based on what's not already present in the actual render data), they could be denoised as part of the image and then extracted afterwards. That way you'd only need a maximum of 9 denoise nodes for full multipass denoising. Not sure how do-able that is though.
Apr 4 2022
Would it be possible to have these light groups embedded in the individual passes (diffdir, diffind, diffcol), and then seperate them afterwards? If the denoise node could also be updated to preserve the (modified) group id data, then we could still do multipass denoising and separate afterwards. At the moment if they only live on their individual combined passes, then they're not too useful because render times will need to be dramatically increased if multipass denoising isn't possible. Denoising them all individually isn't ideal because if you have 20 light groups you'd need 20 denoise nodes, and the result would still be inferior to denoising on a pass level (dir, ind)
@Brecht Van Lommel (brecht) I've pm'd you on blender.chat.
Hi @Brecht Van Lommel (brecht) , sorry I can't provide the specific scene I used, but any of the Blender demo scenes that have a moderate pre-render calculation time will demonstrate the issue.
Apr 1 2022
same occurs in 3.2 daily from yesterday.
Mar 31 2022
ah ok. I just thought if you only removed the shadow catcher from the DiffDir, then we could still have indirect lighting and reflection. The only issue was the shadow catchers diffuse colour showing up on the diffDir pass (making the shadow catcher visible when combining the image).
@Philipp Oeser (lichtwerk) I've just checked in 3.2 and although the shadow catcher's diffuse colour have been removed from the DiffDir pass (allowing it to work), it's also been unncecessarily removed from the DiffInd and gloss passes, resulting in loss of indirect lighting and reflection. Ideally these should have been left alone, as now all the GI etc has been lost. These can be left alone because they render black where there's no data anyway.
ah ok, sorry, I thought the bug fixes were applied to all daily's. I'll check now. It shouldn't have affected the indirect passes hopefully, as they are already black where there's no indirect lighting data.
@Philipp Oeser (lichtwerk) could you re-open this?
Hi The shadow catcher's diffuse colour is still being written to the diffuse direct pass in today's daily build of 3.1.1:
Mar 29 2022
This bug only seems to affect shaders that create both the volume and the transmission using the same material output node:
I've also checked the blender source code to see if the properties call another function via an update parameter, but they don't.
Mar 28 2022
i've tried update_tag(), resetting the frame to the current frame. Not having any luck at all.
This only appears to affect viewport rendering. Final renders seem to use the correct value regardless of how it was set.
Mar 24 2022
thanks @Brecht Van Lommel (brecht) much appreciated. Did you discard the diffuse direct only and keep the indirect pass for the shadow catcher? Indirect could be kept as that renders black already where there's no indirect light. Would be nice to keep the indirect light if possible as that's included in the alpha
thanks. I'm pretty sure it's a bug as I'm quite skilled in this area (been doing it for 20 years), but perhaps there is some Blender specific thing that I'm missing.
Thanks @Philipp Oeser (lichtwerk) I'm pretty desperate on this one as someone just asked for refund because of it. So hopefully it is just something I'm doing wrong.
This doesn't appear to be a user issue. I think the shadow catcher objects need to show as black in the diffuse direct and indirect passes (where there is no indirect lighting), this way the alpha will leave just the shadow and indirect lighting.
or is it just a case of the plane needing to be black?
@Brecht Van Lommel (brecht) this still isn't producing the correct result, sorry I've never used the shadow catcher when rebuilding from passes. Perhaps I'm doing something wrong?
ah never mind, you just disable the pass. Thanks.
@Brecht Van Lommel (brecht) Where is this option please?
Mar 21 2022
beat me to it.
ah, close it down, I've just realised I had: layout.active = snode.show_backdrop in the panel class. Sorry.
Here's a stripped down addon. To reproduce, install the addon, then open the classroom benchmark scene (keeping the 'keep ui' option enabled). Go the the compositor and then click on the turbo tab to open the addons panel. It's greyed out. Make sure you're using blender 3.1.
Did you try an addon that creates a panel in the compositor? I'm not sure if there are any to be honest. If not I can write an addon to send you. Let me know. Oh, did you use the classroom scene for your tests?
Mar 13 2022
Mar 10 2022
I'm probably not getting my point across very well. Addon developers should modify addons to meet api changes, but if it's a versioning issue such as this that's not addressed in blenders versioning checks, it means they effectively have to build addons that will work with files from every version of blender. It's an unrealistic proposition to trudge through every blend data convention change and then develop multiple functions to cater for them all. In this case one function to rename socket identifiers to the current standard will save a huge amount of effort and unfathomable bugs for countless developers I'd imagine.
Mar 9 2022
Perhaps someone could update the benchmark scenes you provide as a lesser than ideal alternative?
It's a shame because it would have no negative consequences beyond what's expected with versioning changes (backward compatibility), and would immediately get a ton of addons working no doubt. I was talking to someone the other day who's still trapped on an old version of blender because the addon developers haven't updated their addons.
@Hans Goudey (HooglyBoogly) Isn't the purpose of the versioning checks to ensure old files work with new standards? What potential issues do you see?
Mar 8 2022
@Germano Cavalcante (mano-wii) thanks. That commit seems only related to custom passes. This report is entirely about the built in passes. So custom passes should remain untouched by suggested versioning renaming.
Just to confirm, if you open the classroom benchmark scene, and run the code I gave above, you should be able to see the issue 👍
Hi, I'm not sure of the blender version in which this change occurred, but the issue is there in the benchmark classroom scene. Yes, as mentioned in the report, I'm referring to the render layers node, EEVEE wasn't about at the time and the Blender Render engine is no longer in Blender, so yes I'm referring to Cycles 👍 Sorry I thought this was obvious, particularly as I mentioned this is apparent in the classroom benchmark scene which uses cycles.
Mar 6 2022
First samples are immediate if you cancel the render and then restart without maximizing the screen. But if you cancel and maximize the screen, then you get the delay/partial scene recalculation. Not sure if the might help you locate the cause?
Mar 5 2022
try zooming in on the image editor after refreshing.
Feb 25 2022
could you also try with a blend file you created in 2.93 and then resaved in 3.1? As your behaviour was slightly different (you were getting the delay but not the rebuilding text...although that may have been because you let the render complete?)
Hi Philip, you're getting the same problem as me as far as I can tell. You don't have to let it complete rendering by the way. Just hit f12, wait for the first sample, then press escape. press f12 again and it'll start straight away. Now go full screen and back, and you'll get that long pause at the beginning again (where it appears to be recalculating the scene without notifying in the image editor.
Thanks for testing. I've just checked in factory settings for 3.1 and today's 3.2. It's the same erratic behaviour when changing to full screen and back. When changing to and from full screen the bug seems to fluctuate between partially recalculating some of the scene and recalculating it all as you can see here:
also happens intermittently at other resolutions. I think it's probably to do with system resources? Maybe it could be avoided by processing each node sequentially rather than parallel (I'm assuming it's parallel based on the issue).
Feb 22 2022
it's not a massive problem to be honest if you want to close it down. It still gets saved out during animation, it's just annoying if the user has rendered a still image and then wants to manually save the image from the image editor with the meta data. I imagine it would be a quick fix to not discard it from the image editor when updating non related image blocks though....I'll leave it with you 👍
Just found the cause. If you refresh any image datablock, even though the image editor is showing the render result, the meta data gets removed for some reason. In full screen I guess for some reason the meta data doesn't get lost when an image data block is refreshed/reloaded etc.
I'm the dev, but the code functions identically in full screen as it does when not, so if it were addon related, it should fail to keep the meta data in both instances.
Feb 21 2022
oh, and that also seems to destroy persistent data. Unless that's always discarded when changing scene?
I've just noticed also that changing from one scene to another will overwrite the currently selected render slot with the new scenes compositor output.
Feb 20 2022
close down if you want 👍
Feb 18 2022
ah actually, i'm using turbo tools, which replaces the render layer node with the cached render which was saved out to multilayer exr via output file in the post render handler. So I guess the file output node discards the meta data........but why does it get saved into the exr when in full screen...hmm.
Feb 16 2022
@Pratik Borhade (PratikPB2123) ah I see, for some reason when I downloaded today's daily it gave me the build from the 12th. Will try again 👍
@Philipp Oeser (lichtwerk) looks like the commits you mentioned above have caused a new bug:
Feb 15 2022
Feb 14 2022
this happens on my machine also windows 10, gtx 1070 driver versino
mistake. Needed to make each cloth a collisions object
Feb 12 2022
Hi, are you still waiting further information from me?
Feb 11 2022
its important because you need to be able to see the text info regarding render samples whilst still being able to see the render result unobscured by wires.
thanks. Should definitely not be visible, as indicate in the tooltip (I could have sworn this was not an issue in 2.8 (must have been mistaken):
happens on cpu and gpu, border is not necessary, Can't be reproduced in a file created with 3.1.
Just checked in 3.1 and yes, the issue now appears to have been resolved:
Feb 8 2022
Just a thought, could the geometry node modifier have it's own inbuilt logic so that when the modifier stack updates, it can see if an update is necessary based on the hash of modifiers before it and their parameter value? I was able to do this in the compositor to achieve real time interaction and caching during playback without referring to the depsgraph (because of the shortcomings you mentioned). Then the only thing to check would be any new or updated attributes to see if they're in use by the tree, if they contribute to the outcome of the tree, and if they've actually changed (based on the hash). If not, maybe the geometry node code itself could update/write the attributes without executing the whole tree needlessly?