NVIDIA/AMD Raytracing - EEVEE Next method
We need an integration for NVIDIA raytracing ASAP. At the moment EEVEE raytracing has only screen space selectable as a method.
This is high priority, and would completely eliminate any Unreal export (for fast GI animations) or slower Cycles rendering.
Please vote this up, its long overdue.
11 Comments
I wouldn't call this high priority nor long overdue.
Blender have plenty of things on its to-do list, and finishing Eevee-next is the actual overdue since it was supposed to be published with v4.1 but had to be delayed.
This alone would be a massive step forward in fast ray traced rendering for Blender and let the devs take care of other important things for a while.
Yes it is LONG over due and important, nearly all engines and many software packages support AMD/Nvidia raytracing. This is a no brainer. Its now over 3 years since RTX is out and Eevee is behind with it. Implementing it is not the problem. Optix (aside full pathtracing) has a Raytracing GL mode so i dont see where the problem is. This how the Nvidia Omniverse and the AMD Vulkan renderer work, also how Unreal does the ray intersection. Its a shame that this was ignored so long, where even the Godot engine now has RT support. Laughable. While especially the SMALL artists need this that have weak GPUs. Not everyone has a 4090 for animation redering at full Cycles pathtracing. And thats where EEVEE shines at, at having no noise, because the RT pass is separate from the rasterizer, like Unreal. Try to render animations with cycles at low samples, good luck arriving in a temporal pixel soup.
I get that you consider this important and top priority, and that you are frustrated that Blender doesn't advance in 3D rendering at the pace you wish. There's nothing wrong about it. But spreading acerbic diatribes will not help.
Blender is a 3D creation suite ( source ), with many areas that need attention, each of which have many people waiting for it, like all the animation and rigging tools that have been left behind since 2009 until the beginning of the project Animation 2025 .
It isn't powered by multi-billion companies like Epic or Nvidia, the Blender Foundation is " a small team of developers who already have enough work to keep them busy for the next decade " ( source ), and isn't as focused of a software as a game engine or rendering APIs, it's both its strength because it's what makes it able to do a bit of everything, but it's also its weakness as it can't be the top-runner at anything.
Let's also not pretend that animation rendering is possible on neither Eevee nor Cycles without the best possible hardware of the time, people have been doing animation rendering on both render engines for years.
Yes thats the whole point, Blender IS the 3D software of the "poor" artists. Cycles was one of the first to support fast GPU pathtracing as was EEVEE to support PBR shading in the viewport. Why ? Because that is the whole point: To accelerate the machines of individuals that have low end GPUs. And thats the same case here: Using RT on top of EEVEE would accelerate things to the next limit for most tasks without having to always resort to Cycles to get one correct reflections, GI, etc.
Blenders case IS to support the speed of the small artist GPU. Otherwise anyone would buy 4090s for animation (cause thats what you need if you really want it in time with cycles and no artefacts). And Vulkan/DirectX/Metal RT is already here. It just needs to be implemented.
If I'm not wrong... nvdia's raytracing is also screespace. Even Lumen is screenspace
No, its not screen space, neither of them. Dude, go and document yourself before posting. OMG. RTX and AMD RT are full ray intersection engines capable of not only full GI but also refractions and reflections. Where were you the last 4 years ?
Relatime RTX outside of screen space its not full raytracing, its actually using radiance caching techniques which generate artifacts whch later are corrected with ai neural radiance cache algorithms. This might work for realtime game engines but might not be useful for rendering.
Now, just to make things clear, i will post whatever i want whenever i want and if this bothers you maybe you should reconsider getting involved in public discussions. And instead of spending your last 4 years wacthing nvidias youtube keynotes maybe you could have learned some manners.
Not true, its using full ray intersection with PATH tracing, not Radiance Cache! Read the papers. Yes you can post but you would save many a lot of time documenting yourself. Like here: developer.nvidia.com/rtx/path-tracing/ with AMD its the same: Its full path tracing on top of DirectX/Vulkan shading.
"The latest algorithm, Neural Radiance Cache (NRC), is an AI-powered solution that trains the radiance cache about a scene in real-time, handling fully dynamic scenes with reactive lighting and without the need to bake static lighting for geometry and materials beforehand. It uses AI acceleration to train the radiance cache in real time to offer improved performance and more accurate global illumination in highly demanding scenes."
"To offer scalability, NVIDIA introduced Spatial Hash Radiance Cache (SHaRC), a version that offers similar benefits as NRC without using a neural network. It is compatible with any DirectX or Vulkan ray tracing–capable GPU. It is a radiance cache that is built on a spatial hash data structure designed for a fast and scalable global illumination technique for path tracing."
Both quotes are taken from the same link you provided... sigh
Again, without this techniques and others such as DLSS, RTX will have the same performance issues as any other path tracer, that's why it's useful for video games but not necessarily for rendering. And there is no need to look into the documentation, just try it yourself, reflections in any realtime engine are never as good as in any old school ray trace engine.
Don't bother answering I won't be reading, I just replied for anyone who is actually interested in the issue and doesn't buy every Nvidia's marketing slogan
would be nice to see RT reflection support in-future because SSR and baked cubemaps have fundamental issues compared to SSGI which is "good enough".
That being said, it shouldn't take high-priority, as there'll likely be far more important things to implement into EEVEE Next after its released in 4.2 - plus the fact that the team have a lot of projects already.
SSGI is only good enough for still images, and even then its lacking. For animations its a joke and aside from special cases unusable (light reflections disappear from sight, etc.)