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

In T100164#1399261, @Omar Emara (OmarSquircleArt) wrote:

Looks like normals just need to be normalized.

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:

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:

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.

I just recompiled and GPU subdivision in weight paint mode / show wire still looks glitchy:

Awesome! Thanks for the fix.

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).

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.

The fix is literally a one-liner https://developer.blender.org/D15014

This also doesn't work in 3.0.1 and 3.1.2. Looks like it never worked.

Same goes for Optix + CPU and CUDA + CPU as well.
Currently the CPU seems to rather slow the whole rendering instead of accelerating it.

https://developer.blender.org/rB439f86ac89bdd649aa9ccfe258c5f80474788449 fixed the lags once and for all :)

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)

@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:

Uh, sorry. Did a quick search but didn't find it. Good that it's already been reported :)

Yes it happens with factory-startup, too.

I was just about to submit a bug report but found this task here.

@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?

Just a quick heads up on this:

Can not confirm this on Linux and latest master

Sounds a lot like a problem with "Persistent Data" on:

Quick update: This "bug" seems to be fixed by rBbdd74e1e9338b18e4f80458f284d0c6a4d100f30
Maybe someone can confirm and close this report. Thanks. :)

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 :)

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...

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.

I can also reproduce it with 2.93.6 official build.

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.

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.

In T92985#1251794, @Steffen Dünner (SteffenD) wrote:

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.

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.

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,

In T92859#1251152, @Jacques Lucke (JacquesLucke) wrote:

@Steffen Dünner (SteffenD), not sure if an empty Geometry Nodes modifier can cause the same underlying issue. Please create a separate report for that.

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.