Thanks for replying. Using a preview surface, yes. See attached image – shows a snippet of the usda specifying subdivision of catmul clark. Note the Reality Composer Pro screen – the object is jagged. (Whereas if I render the same asset in Houdini Karma w/ subdivision on, it is smooth – so the topology is clean.)

If I understand the problem here, what you want to do is multiply the position value by some constant to scale the noise. You can try values like 0.25 or 2.0 etc to start, and observe the effect they have. something like [Time ] + [position * constant] > noise position. likely what's happening is that the noise frequency is not scaled correctly for your geometry so every vertex appears to move the same amount.

I've been really burning a lot of time on this as well. I've tried sort groups, but they're not viable because the ordering isn't always going to be the same if the user is moving around in the space. To add some detail to the issue, I've noticed this is most pronounced when multiple objects with transparency are layered on one another. In other words, if you have a single tree imposter (a flat plane with a tree textured onto it and an opacity map) it will overlay onto a background properly. However, if there's a second tree imposter, and the two objects overlap visually, RealityKit will eventually skip drawing one of them rather than drawing all transparent objects.

Hmm, well possible update on this in typical Rubber Ducky fashion. Possibly due to the fact that as I've been iterating on this particular project I've ended up with a RCP Package inside a RCP Package. I wonder if this recursiveness results in a memory leak in realitytool? I'm building up the scene piece by piece in a new file to see if this indeed fixes the problem.

Curious to see if the depth group answer solved this issue for you?

Any Metal engineers at Apple want to take this question? Right now I'm hard-coding my compute shader texture map sizes, but would prefer not to use such a fragile approach. Second and most important is – how can we handle foviation when it comes to compute shaders? Like, typically you use threadID etc to look up the 'pixel' in the corresponding map. Are there utility functions / data we can use with Compute shaders to figure out which pixel a threadID should map to in a foviated situation?

Has anyone gotten a black magic eGPU to work on Big Sur? I’m in a similar situation. Upgraded because Octane X required Big Sur. Now none of my main graphics apps work — photoshop, Houdini. They all just have blank windows. The only solution I’ve seen is reverting back to Catalina, which is both arduous and would mean giving up on apps like Octane that require the newest version of Metal. eGPU works in Unreal Engine and Octane, so I’m not sure why it’s busted all the other apps I rely on that I mentioned above. If it were just one of them, it would seem to be an issue on their end — but this is causing the same issue of blank windows across the board, which leads me to the conclusion that this is a Big Sur problem.