NVIDIA Release RTX Powered Godot Fork

Tomcat

kuligs2 but still no raytracing with his build.

Ray tracing is enabled elsewhere:

Cleaning Up The Rendering

There are a group of settings in the World Environment->Raytracing section, a set of packed params:

https://gamefromscratch.com/nvidia-release-rtx-powered-godot-fork/

Hmm… looks like I'm out of luck… until I get a newer GPU. Even though “RTX” is in the name of my GPU.

Задать pathtracing_enabled
  WARNING: servers\rendering\renderer_rd\forward_clustered\render_forward_clustered.cpp:5414 - Raytracing not supported on this device.

kuligs2

Tomcat like i said i dont have any parameter or any option named Raytracing anywhere in godot.. even when using the precompiled .zip

Where do i need to enable it?

JohnLogostini

Tomcat Take a look at the post I just made hopefully this helps. As far as I know, any RTX GPU should be capable of running Path-Tracing, even if it’s slow. Additionally, the Pascal generation can also run Path-Tracing, so the 10-series cards, such as the 1080 Ti, should support it as well. I haven’t personally tested this, but I believe it works though performance will be very slow.

Tomcat

kuligs2 Where do i need to enable it?

Pathtracing

kuligs2

Tomcat pathtracing is not raytracing

Tomcat

kuligs2 pathtracing is not raytracing

Well, it's hard to argue with that.

Have you tried turning it on?

kuligs2

Tomcat still no raytracing

looks like garbage with path tracing

it constantly tries to resolve but never finishes..

these are max values you can input

I still dont understand why on RTX 4070SUPER there is no raytracing option but on some RTX3060 someone else here posted - has.

What am i doing wrong?
Drivers are up to date, updated yesterday.. im using windows11, the most noob OS out there for this to work.. and it does not 🙁...

JohnLogostini

kuligs2

Hey, sorry for the confusion I can clarify many of your problems. Hopefully this helps:

1.You appear to have compiled the proper build now, so I will skip over that.

Be sure that you copied the contents of the bin folder from the Streamline SDK into your Godot bin folder.
This implementation in Godot uses Path-Tracing, not Ray-Tracing. They are technically very similar, but the primary distinction is: with Ray-Tracing, the rays come from the camera, which is not how light works in the real world; with Path-Tracing, the light comes from the actual light sources. In this implementation, light is also simulated slightly differently and more accurately.
When the first version of this branch was released at GDC, the menu said “Raytracing,” but that was incorrect and has been renamed to “Pathtracing.” This is the correct category, and the settings were also given updated labels and dropdowns.
Verify that your project is running on Vulkan, not DirectX (which is the default on Windows), since this only works on Vulkan.
Verify that your project is running in Forward+. I don’t know if this is strictly required, but I believe it loads all of the Vulkan tools necessary for Path-Tracing.
In your project settings, under 3D Scaling, set the filter to DLSS. This is currently required to use the Ray Reconstruction denoiser.
You can max out the settings, and that will improve quality, but since the performance cost is so high, I recommend for now using 1 Sample Per Pixel and 3 Bounces with denoising enabled. This is just a starting point for experimentation, but it’s what I’ve used in all of my demos.

Tomcat

JohnLogostini

Verify that your project is running on Vulkan
…

In your project settings, under 3D Scaling, set the filter to DLSS.

Yeah, when it's like that, it works. The only issue is with the color.

RTX:

Here's how it should look:

kuligs2

JohnLogostini Thanks for the clarification, but:

I did this the streamline sdk copy over, into my bin folder - same result only pathtracing,
I also am using your compiled version from google drive you linked previously, and it seems it has all the dll files needed??

3/4. OK now this was confusing because when it was called raytracing there were more options to choose from, unlike pathtracing panel that has only 4 options to tweak.

Is this correct?

Is this correct?

Now this is what was missing

default

Enabled

Also many presets fail.. this works

In the end the 7. point is what i was missing to enable, wish them devs would explain what needs to be enabled where..

And can confirm its a huge performace cost.. my scene has like FPS spikes and is lagging even tho it reports 55fps.. it should be 60 fps..

But i dont see them artifacts i did without it on my meshes.

Here is without pathtracing.. something broke.. idk why my char is black.. but the walls seem glitching as before (from my project post)

Ok thanks for the help.

JohnLogostini

kuligs2 I will try to make a guide soon so things are a bit more obvious, but glad you got it all sorted out.

Tomcat

How does this work with shaders, anyway? Take, for example, a tree and its shadow. If the wind effect is implemented physically, it makes sense that the shadow would move correctly along with the mesh. But if the wind effect is created using shaders, will the shadow remain stationary?

https://godotforums.org/d/32248-create-trees-with-wind-effect

JohnLogostini

Tomcat I am not entirely sure. I haven’t messed with vertex offset yet, but I can ask NVIDIA if that’s in the plans. I know updating a BVH based on vertex offset is a massive task, so I am not certain.

Tomcat

JohnLogostini I haven’t messed with vertex offset yet, but I can ask NVIDIA if that’s in the plans.

It would be interesting to hear their opinion.

I know updating a BVH based on vertex offset is a massive task, so I am not certain.

Here’s how I see it. “Realistic” physics simulation places a heavy load on the system. Using shaders significantly reduces performance requirements. But in this situation, shader-based shadow calculations can “eat up” all the benefits of using shaders, and in terms of hardware requirements, it won’t matter whether it’s physics calculations or multi-pass shader processing. Well, something like that, as a rough estimate. Am I wrong?

I’m interested in this because I want my project to run on low-end computers. Specifically in this situation, perhaps we could try applying a shader to the shadow (if possible) so that it looks, at a distance, as if the shadow sways along with the tree — that is, a solution outside the scope of ray tracing.

At the same time, though, I’d like owners of high-end computers to get good graphics. I’m not quite sure how to resolve this dilemma yet. Perhaps there will be two versions of the game.

JohnLogostini

Tomcat Hey, sorry I didn’t get back to you on this.

So the NVIDIA dev is out of town for a week, so there will be more updates soon. But yes, this is in the works.

JohnLogostini

Got a new demo today. This one is more realistic it’s the Remastered Sponza scene that I have ported natively to Godot and configured to work with Path-Tracing. Not only that, but I have spent a substantial amount of time making the Rasterized version also look decent, so this is more of a fair comparison of Path-Tracing vs. Rasterization in terms of quality.

You can download the demo from the GitHub link below, which is a repository of demos. Currently, this only includes Sponza, but I will have more demos soon.

Project Link: https://github.com/johnlogostini/NVGWGD_Demos

Tomcat

JohnLogostini Project Link: https://github.com/johnlogostini/NVGWGD_Demos

For this project, it is necessary to download NVGWGD_Sponza (2.63 GB) separately. Then, SM_Ivy_Leaves.tres (313 MB) must also be downloaded, as it is not downloaded with the main file. Furthermore, it is not loaded when the project is opened. Attempting to manually load it into an open Godot project consistently causes the program to crash.

JohnLogostini

Tomcat
This sounds like a submodule and LFS problem. To fix it, be sure to clone the repository with submodules using: git@github.com:johnlogostini/NVGWGD_Demos.git --recurse-submodules This will pull everything.

However, if you’ve already cloned the repository, navigate into the repository folder and run git submodule update --init --recursive This will download everything.

The reason I use submodules is because:

I would hit GitHub’s file size limit if I used one large repository, and
Each demo is licensed differently, so separating them avoids any confusion around licenses.

If by chance you’re also having issues with Large File Storage (LFS), be sure to download and install it from the official page: https://git-lfs.com/

This should be installed by default with the Git installer on Linux and Windows, but if you disabled it or don’t have it installed, be sure to download it.

This is required because the Ivy asset is too large to commit directly to GitHub, so I used LFS. I may split the mesh in the future to avoid this, but I didn’t want to modify the demo in any major way.

Tomcat

JohnLogostini This sounds like a submodule and LFS problem.

I downloaded it separately, thinking it would be enough to just add it to the project. But apparently something is missing. For now, I’ll just watch with interest. Until the developers figure out the moving grids, it’s more of a entertainment than a practical application.

JohnLogostini

Tomcat This is a Git problem, not a Godot problem. I’d highly suggest setting up LFS and cloning recursively. There’s also a chance you don’t have SSH keys set up with GitHub, which I’d recommend doing if the submodule is an SSH URL and not HTTPS, the clone will fail. Here’s how to set those up if needed.

Tomcat

JohnLogostini This is a Git problem, not a Godot problem.

I doubt that, since the errors I get when opening a project are minor but vary each time. I’ve already had trouble opening large files in Godot. Perhaps Godot isn’t quite ready for working with large projects yet.

There’s also a chance you don’t have SSH keys set up with GitHub

I use GitLab.

« Previous Page Next Page »