- User Since
- Dec 26 2010, 3:06 PM (613 w, 3 d)
Nov 4 2021
One important observation: The issue does not arise when the offscreen is fed with a different view- and/or projection matrix each time.
Before the rebase, commenting out viewport->depth_tx = depth; in https://developer.blender.org/diffusion/B/browse/master/source/blender/gpu/intern/gpu_viewport.c$210 would result in the drawing of one frame without visual artifacts and a subsequent crash. After the rebase, the crash does not happen anymore but the result seems to have the artifacts as well.
I have created a new revision of https://developer.blender.org/rBd03b26edbdc3a9fe87fde44bd8db8c4a67a36757 that is rebased to 3.1 trunk:
I rebased the patch to 3.1 trunk: https://developer.blender.org/D13104
Sep 10 2021
@Christian Stolze (regcs) had the idea to enforce RV3D_NAVIGATING for all offscreen rendering by adding
rv3d->rflag |= RV3D_NAVIGATING;
to .../editors/space_view3d/view3d_draw.c right after line 1647.
Sep 9 2021
Sep 6 2021
I have created a short video that shows all the quirks that come up when applying this patch to the current master:
Aug 5 2021
Jun 29 2021
Jun 21 2021
Jun 19 2021
Jun 18 2021
Created a fix for this by exposing the color management option in the Python API while defaulting to false (the current behavior): https://developer.blender.org/D11645
The defaulting to false is now also visible in the doc.
do_color_management is now a keyword-only argument and optional, defaulting to false. Thus no changes need to be done to existing addons.
Apr 30 2021
Apr 21 2021
Jan 5 2021
Jan 2 2021
Dec 17 2020
I can confirm.
Oct 21 2020
May 22 2020
Mar 29 2020
I think I have an example file here that has the same issue but in an extreme form, hope it helps with hunting down the bug.
Mar 20 2020
Mar 16 2020
I can confirm the original issue in blender-2.83-f06a6e92bc5e-linux64.
I can confirm that increasing the transparent bounces fixes the glitches and that the OPs first problem was indeed Z-fighting.
The empty space feature might be something that needs to be exposed on the Mantaflow side? Assigned to @Sebastián Barschkis (sebbas) for now.
I can confirm as well - the results are completely different with and without adaptive domain even though they should be identical.
Confirmed. There is absolutely no smoke when turning on "Dissolve". But it returns when enabling "Slow".
Jan 19 2020
I can confirm that a surface thickness of >0.0 circumvents the bug.
Dec 31 2019
I can confirm in 2019-12-27 the initial velocity is ignored for liquids at the moment
Nov 26 2019
Nov 21 2019
Nov 15 2019
Nov 14 2019
Nov 4 2019
Nov 3 2019
Oct 8 2019
Sep 22 2019
I found another issue - here the fluid is has an offset to both the inflow and the collision object. The domain has been changed in edit mode:
Sep 11 2019
What influence does the parameter for Real World Size have? I have created a demo file with a 10cm domain and a simple drop and the result looks like a huge splash (file is attached):
Sep 10 2019
Sep 9 2019
Thanks to adaptive domain this is now feature complete compared to the old system, yay! Thank you for the hard work over all those years.
Aug 20 2019
Jul 31 2019
Jul 30 2019
Jul 28 2019
Jul 9 2019
Remove hard limit and comments on that, increase soft limit.
Remove both the hard limit and the comments on said limit.
Jul 1 2019
What is the status of this patch? It seems super useful for the visualization folk...
Jun 28 2019
Jun 22 2019
May 8 2019
Apr 18 2019
This is no longer needed thanks to https://developer.blender.org/rB5cfeba72f117b7dc6d6eba22e3f203fc3f574429
Apr 17 2019
It seems like the issue this patch is addressing has been fixed in master, partially due to
Apr 16 2019
Mar 30 2019
@Porteries Tristan (panzergame) I tried your version with 2.8 but it does not work :(
Feb 20 2019
Dec 10 2018
Sep 24 2018
May 24 2018
Apr 11 2018
Oh, it works fine in 2.79b - this can be closed :)
Mar 8 2018
Mar 7 2018
Since 2.8 is on it's way how about committing this to the 2.8 branch? I would be very pleased to have smoke colors provided linear in Cycles.
Feb 18 2018
Feb 17 2018
Feb 1 2018
While I appreciate that this node will load grids automatically I would also like to have a seperate node to load density grids because the current way of using the attribute input is kinda sub-par. Usually I end up doing further operations on the density before feeding it into the volume nodes.
Btw: There are many types of grids to support, for example image sequences/slices like the ones you get from CT or MRT scans. Loading those is possible in Blender internal and it is really useful.