User Details
- User Since
- May 24 2016, 1:39 PM (323 w, 6 d)
Fri, Aug 5
Thu, Aug 4
Oh, and maybe it would help to update your drivers. 472.84 is quite old, I had some trouble before with mismatching drivers / Optix version. Caused all kinds of strange render bugs.
I cannot reproduce the NaN on this system:
Eevee seems to render another scene (with non-changing vertex counts / topology) fine without garbling the shading.
And another quick addition:
The Alembics and USDs with normalized normals render fine BUT as soon as I switch on motion blur another problem occurs which I reported a few days ago: https://developer.blender.org/T100134
Wed, Aug 3
Just gave animated UVs and normals a try by animating the UVs and normals of a simple grid in Blender, exporting it to Alembic and re-importing it. They both work.
Abcinfo for the animated normals looks very similar to the one coming from Houdini. I wonder why only the one coming from Blender has proper animated normals:
Tue, Aug 2
Even if I set the velocity attribute to 0,0,0 for all points the faceting is there...
If I remove the named velocity attribute all is smooth but of course no motion blur shows up.
When rendering a motion vector pass and using the Compositor all looks fine BTW:
Mon, Aug 1
Fri, Jul 22
Sure... the current geometry is super simple (a cube with an intrusion) but it should work to show the difference.
Very interesting and important topic here.
Tue, Jul 19
Jun 30 2022
Jun 21 2022
Jun 20 2022
I just recompiled and GPU subdivision in weight paint mode / show wire still looks glitchy:
Jun 7 2022
Awesome! Thanks for the fix.
Jun 6 2022
If you load this 8-bit JPEG into the Compositor (with Filmic sRGB as color space), you're getting values up to 16.x again.
Super awesome, Brecht. Thanks!
Ah cool. I didn't know this (as I always enable the Node Wrangler).
Jun 5 2022
The "image sequence" node in 3.x doesn't even have a "Relative Path" option any more. So that "solves" this problem :(
This goes for Shader Editor and the Compositor by the way.
May 24 2022
The fix is literally a one-liner https://developer.blender.org/D15014
May 20 2022
This also doesn't work in 3.0.1 and 3.1.2. Looks like it never worked.
May 11 2022
Same goes for Optix + CPU and CUDA + CPU as well.
Currently the CPU seems to rather slow the whole rendering instead of accelerating it.
May 10 2022
https://developer.blender.org/rB439f86ac89bdd649aa9ccfe258c5f80474788449 fixed the lags once and for all :)
May 9 2022
I don't know. In a default layout try dragging the horizontal separator between the Outliner and the Properties up and down and compare it's responsiveness to dragging the vertical separator between e.g. the Outliner and the 3D View left and right.
If you switch the 3D View to e.g. a Shader Editor, everything is smooth again.
I get the same fps dropping as before (and opposed to 3.0.1 where there is no fps dropping)
Apr 27 2022
@Kévin Dietrich (kevindietrich) Thanks for confirming this. The extra padding because of the motion blur sounds very plausible.
As I said, I can live with upping the ray bounces for transparency if this fixes the issue.
Quick addition: After some experimentation I found that I can get rid of the artefacts by upping the "Transparent Max Bounces" value to something like 16 instead of 8:
Mar 25 2022
Mar 23 2022
Mar 17 2022
Uh, sorry. Did a quick search but didn't find it. Good that it's already been reported :)
Mar 16 2022
Mar 10 2022
Mar 4 2022
Mar 3 2022
Mar 2 2022
Yes it happens with factory-startup, too.
Feb 28 2022
I was just about to submit a bug report but found this task here.
Feb 25 2022
Feb 22 2022
@Juan Gea (juang3d) You are of course right. I never actually build hard surface stuff from SubDs that's why I didn't bother rendering my example ;)
But the rest is still true: Custom normals and SubDs aren't best friends. Still funny why the GPU viewport shows this result.
In my experience OpenSubdiv (or subdivision surfaces in general) don't use custom normals because the algorithm itself is responsible for generating its normals on the limit surface. If you want a perfect cube, use creases.
The results are different in 3.2 master depending on whether GPU subdivision is used or not. GPU subdivision shows the faceting (coming from the fact that the mesh has custom split normals and is set to flat shading, I guess that GPU subdivision doesn't handle this case correctly?) while non GPU renders smoothly.
I just gave some point clouds with velocity vectors coming from different source software a try (in Blender 2.93, 3.01 final and in 3.2 master) and never could get motion vectors to import. I also tried animated point clouds with static and changing point counts and a (particle) point cloud exported from Blender that successfully exports its motion vectors to an Alembic but doesn't load them back in. They're actually there, I confirmed it in 3rd party software.
So apart from a patch by @Kévin Dietrich (kevindietrich) I think Blender never supported velocity on points / vertices?
While trying to reproduce the problems I noticed that there's quite a combination of things that can influence and break the shading:
- There are custom split normals on the geometry
- They are set to flat shading (which should ignore custom normals IIRC?)
- "Auto Smooth" is on so that custom split normals are even used
- Custom Normals are used in the SubD modifier
- Creases are used in the SubD modifier
The Alembic contains only points. AFAIK velocities / attributes on points are not yet supported in Alembic import?
Feb 21 2022
Just a quick heads up on this:
Feb 18 2022
Feb 17 2022
Feb 8 2022
Can not confirm this on Linux and latest master
Feb 3 2022
Sounds a lot like a problem with "Persistent Data" on:
Jan 28 2022
Quick update: This "bug" seems to be fixed by rBbdd74e1e9338b18e4f80458f284d0c6a4d100f30
Maybe someone can confirm and close this report. Thanks. :)
Jan 18 2022
I'm pretty sure it is. I could easily reproduce with a compile of master one commit before the one of @Brecht Van Lommel (brecht) but now all looks solid (fingers crossed). Thanks for closing this report.
Yesterday @Brecht Van Lommel (brecht) committed a VDB related crash fix ( rBb776c46d2f67dffd36e2a68a1152c0f0d7bef7e6 ) and it seems it fixed this bug report, too.
With a master build before his commit Blender still stalls but now I can no longer reproduce it.
Maybe @Richard Antalik (ISS) or @Bastien Montagne (mont29) can also give it another try as you were able to confirm my reported bug back then. And hopefully close this report afterwards :)
Jan 17 2022
Jan 11 2022
Jan 10 2022
Jan 4 2022
Jan 3 2022
Dec 22 2021
Dec 15 2021
Dec 7 2021
Dec 6 2021
Sorry for the late reply but I had no access to my laptop / workstation. I'm not a Linux pro (yet?) and I'm always installing CUDA + the nVidia driver coming with it. So I didn't dare to install 495.44 yet. ;)
Thanks for investigating this.
I noticed that the versions of Blender that failed were my own compiles where I accidentally forgot to switch back to Optix 7.3 after installing 7.4 and doing some test compiles (that compiled without a problem).
Now that I'm using 7.3 again it works properly with both drivers I mentioned. I decided staying with 470 drivers though, as the later ones tend to crash Houdini and have some other quirks...
Dec 3 2021
OK, I think I found the problem: It's the nVidia driver 495.*
I went back to 470.82.01 and all is shiny again. No more artefacts. I didn't even know that GPU drivers can cause something like that 8)
I'm not able to reproduce it on Windows / Optix / latest studio drivers. But I can reproduce it on Linux / Optix / 495.29.05 drivers. Both with latest Build Bot builds.
Dec 2 2021
I can also reproduce it with 2.93.6 official build.
Dec 1 2021
Small addition. Here's a viewport render (with subsamples) of the 3 cubes above. You can clearly see that only the rightmost cube falls smoothly. The two on the left (RBD cache and constrained) always accelerate / decelerate during a frame.
Nov 30 2021
Nov 26 2021
Nov 19 2021
Nov 17 2021
Nov 16 2021
Thanks for investigating.
At first I thought it had something to do with the experimental "Full Frame Compositing", but it happens with "Tiled" as well.
Nov 15 2021
Nov 10 2021
Just in case this helps: Doing a factory reset gets rid of the problem. In my case I had to completely erase my 3.1 user folder. Just using "File > Defaults > Load Factory Settings" didn't help for me.
Nov 9 2021
Thanks for the explanation.
Would it be somehow possible (without breaking too many things) to treat objects with completely muted / disabled GN modifiers like objects without any GN modifiers at all? This would already make a simple workaround in my current project a lot easier than it currently is. I could just disable the GN modifiers during the animation phase and switch them back on whenever I render the scene,
I was about to post a similar report and found this one. In my case the massive slowdown happens with a "Set Material Index" node.