Ryan-M

The pixelation through the windows in your first two images look similar to an issue that we addressed in the 26.2 release. I believe you can still get it to happen, but my understanding is that it will only happen if your plan is very far from the origin so that might be something to check. In your last image with the water, it looks like poor denoising (on the water itself). X16 sometimes struggles to remove noise on transparent (refractive) surfaces. We expect this to be improved in X17.

You are not the only one and we have contacted AMD about this. For now, rolling back to an earlier driver is the appropriate solution to the problem.

We have reproduced this on specific laptops with switchable graphics. The only way we have found to work around it is to disable the Intel card on the machine. The safest way to do this is via the HP Omen Gaming Hub software. Steps may vary depending on your specific machine, but I've attached images illustrating the process that works on the machine that we have. Specifically, you want to switch from the Hybrid GPU mode to the Discrete GPU mode.

In the context of ray tracing, we have seen performance scale approximately linearly with core count when comparing the same tier of hardware. A 12-core M2 will be about half as fast as a 24-core M2. A 12-core M3 will be about half as fast as a 24-core M3. There is a fairly significant jump from M2 to M3 (for example, a 12-core M3 is more than twice as fast as a 12-core M2) due to the introduction of dedicated ray tracing hardware. The most powerful M2 Studio probably isn't going to perform better than the most powerful M3 MacBook Pro when it comes to ray tracing. I can't speak as much to non-rendering performance as we don't really have similar benchmarks. It is comparatively simple to benchmark ray tracing performance in Chief. Outside of that, there are so many unique operations with different performance characteristics that it would be difficult to quantify in the same way.

Yes. This is good to know, we don't have that card in-house.

I believe the original benchmarks were Nashville, Kitchen 1 at 1400x860 (don't ask me why, we were profiling the Mac at the time and I'm pretty sure this was the resolution I got by default on an MBP). Please bear in mind that the numbers Trent posted were from a specific build relatively early on in X16 and that exact samples/sec in the current version may have changed somewhat since then.

In my recent benchmarking, a desktop 4070 was about twice as fast as a desktop 3070, and a desktop 4090 was about 2.2x faster than the 4070. This was tested in a specific plan at a specific resolution so results may vary a bit, but in general I would say that a 40-series is a significant improvement over the 30-series.

This is cool, thanks for sharing. Adding more variety to the grass tool (and expanding it to other types of similar foliage) is something we've talked about a lot, and these are good examples of what it could do.

It causes the view to stop rendering when it reaches the specified number of Max Export Samples. In X15 the view will denoise at this point. If it's left unchecked the view will continue to render indefinitely.

So, this is basically a bug. The way that we apply lighting to surfaces viewed through a glass (or any refractive) material is different than the way we apply lighting to surfaces that are directly visible. In X13 - X15 there is a fixed limit on the number of lights that we apply to these kinds of surfaces. This means that some of those lights inside of the cabinet may not actually produce light on the surfaces visible through the cabinet glass. I can certainly understand that this is confusing and not the ideal behavior. This is unlikely to be problem in newer versions of Chief.

My best guess based on what you've described is that your machine is overheating. Chief really shouldn't be able to generate a BSOD even if it wanted to. It's unlikely we'll be able to diagnose a problem with Chief here.

If you're talking about CPU ray tracing, then reference plan geometry won't display. If you're talking about ray traced PBR then it should display. To get it to show up in a CPU ray trace you could export the reference plan as a symbol (e.g. via 3DS export) and import it into the plan you want to ray trace from. This assumes you want your reference geometry to show up with materials. If you want it rendered in a different technique (like Glass House) then I'm not sure you can do that with CPU ray tracing.

This is in regards to CPU Ray Tracing. It doesn't sound to me like that is what the original poster is trying to do, but they can correct me if I'm wrong. I will update my post, though, as you're right that there is a valid reason in X14 to use Rosetta (though I still wouldn't recommend it unless you're doing CPU Ray Traces). Thanks for pointing this out. This doesn't apply to X15, where we have fixed the problem that this was working around in X14.

It should not be necessary to use Rosetta for X15, and I would encourage you to contact tech support before trying to solve this in that way as running with Rosetta will negatively impact performance. There was an issue with the CPU Ray Tracer executable in X14, but I believe that has been fixed in X15 and it wouldn't have anything to do with opening objects or creating camera views. We have an abundance of M1 laptops and a few M2 laptops in-house that we don't have issues with, so I'm not sure what to suggest at this point except that contacting tech support is your best bet. Edit: As @VHamptom has pointed out, you may need to use Rosetta in X14 you're using CPU Ray Tracing. This is fixed in X15.

As of X13 we do use Metal. We also run natively on ARM as of X14. Ray tracing is independent of both of these things. Mac ray tracing is something we regularly evaluate. Here is why it hasn't happened yet: When it comes to GPU code for non-ray tracing functionality, we're able to author it such that it "just works" on both platforms. This doesn't apply to ray tracing. Without going into too much detail, this is a considerable technical problem that doesn't have a great solution right now. There is no hardware acceleration for ray tracing on any existing Apple hardware. "Hardware acceleration" means dedicated hardware for tracing rays, e.g. the kind of hardware present in NVIDIA RTX and AMD RX 6xxx GPU's. This doesn't mean it's impossible to perform ray tracing on Apple hardware, but it does mean it will do so much more slowly than other hardware. The two major takeaways here are: Right now, the performance we would be able to get on this hardware makes it very difficult to justify the implementation and maintenance cost (which is very high). Even if the hardware becomes available tomorrow, we wouldn’t be able to flip a switch and make it work on the Mac. There’s substantial effort involved to get Chief to the point that it can leverage said hardware, and this would involve the planning and budgeting of engineering time well in advance. Here is an article that compares M1 GPU ray tracing performance against various CPU's and GPU's. The short of it is that the M1 is between 30x and 40x slower than an RTX 2070 (mid-range first-generation NVIDIA card). Granted, this is the base M1 model. If we assume the M1 Max is in fact 4x faster than an M1 as seems to be the claim from Apple, then it's still upwards of 10x slower (at tracing rays) than a mid-range PC GPU from 2018. Modern ray tracing-capable cards have improved in ray tracing performance comparably to the M1 Max improvement over M1, so we're still looking at a 30-40x performance difference between a modern Mac and a modern PC. This is a topic that we internally discuss routinely. It's a complex business decision, not something we're withholding for arbitrary reasons. The equation changes over time, and we’ll continue to evaluate where we’re at as new technology becomes available and our PBR implementation evolves.