Considering they don't have enough manpower to compete with UE/Unity in raster, would it make sense going for full raytracing now?
That way, when next-next-gen hardware arrives in 2-3 years, they could be on the forefront of editors specialized in fully raytraced games.
I dont know how this makes sense.
Considering they have less manpower, they should make a more cutting edge renderer on unproven, unstable tech?
Full ray tracing is not going be any where near ubiquitous in 2-3 years, mark my words.
The idea is that since there are several years ahead until full raytracing hardware starts to appear, you could focus on that (and a single Vulkan renderer), reducing the manpower needed.
Meanwhile, commercial engines have to focus on current games, rasterization, raster + RT and the myriad of renderers and hardware they support.
Full raytracing is very possible sooner than we may think if approaches like DLSS 2 keep improving.
I thought you were saying they should focus on ray tracing instead of the Vulkan renderer. Saying they should build a vulkan renderer and a ray tracing renderer is a much different statement than what I was understanding, and sounds like a lot to ask for.
Additionally there's a ton of risk in betting on full ray tracing in several years. Given that they are a small team with a small community and small funding, they simply have to hedge there bets, and myself as a user am damn glad they are. Unity going guns blazing on new shit and having things be broken all the time is a huge reason why I switched to Godot in the first place.
A nice thing about godot is that it's code base is very easy to get your hands in to, so if Juan wants to focus on the big stable market with the raster renderer, the community can work on a ray tracing renderer. Juan is exposing an api called RenderingDevice in 4.0 that should enable the community to write their own renderers easier than from scratch.
Raytracing is an extension on Vulkan. I don't understand what you are trying to say. I am not talking about CPU raytracers.
> Additionally there's a ton of risk in betting on full ray tracing in several years.
They are not commercial, so the risk is minimal. That is why Godot is such a good place for that.
> Unity going guns blazing on new shit and having things be broken all the time is a huge reason why I switched to Godot in the first place.
That is true and it is why most games avoid updating Unity if possible. But I feel if Godot had so many features, it would have the same problem too (or worse, given less manpower).
> the community can work on a ray tracing renderer
Juan is the one with financial support. Most people cannot afford to take on a research-heavy, multi-year project on their own.
Nevertheless, RenderingDevice sounds great for research projects and academia!
Not technically wrong, but an incomplete picture. The way that engine renderers are organized right now does not lend them well to raytracing. The Vulkan extension we're talking about requires you to set up completely separate pipelines, use different kinds of dispatches, and different shaders. Very little is compatible, and most "ray-traced" are bodged in there in a weird way -- they're mostly used for single-bounce specular AA, as we only have a very small ray budget.
My original post was precisely about focusing on such a full RT renderer (via Vulkan). I am not an expert, so it may be a dumb idea, but it would be nice to have a FOSS production-quality renderer by the time full RT becomes a thing for more and more games.
I was a little dismayed. It seems like AAA games are also not making a huge amount of use of it either. Despite the RTX name I don't know if it's really ready for prime time, at all.
But yeah generally I agree, a game that is already doing AAA amounts of gemeometry and shading, that uses RTX to good effect, is going to need 2080ti in SLI to be still a bit slow.
DLSS 2 and similar techniques help a lot to reduce the number of rays needed. Perhaps by the time of RTX 4000 (what I meant as next-next-gen) we might be able to see full raytracing.