Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

This demo is very GPU-intensive. #9

Open
Capewearer opened this issue Feb 19, 2024 · 2 comments
Open

This demo is very GPU-intensive. #9

Capewearer opened this issue Feb 19, 2024 · 2 comments

Comments

@Capewearer
Copy link

Capewearer commented Feb 19, 2024

Unfortunately, I have very weak videocard (AMD R7 260X), that is able to work properly in decade-old AAA and AA games such as Crysis series, Bulletstorm, The Talos Principle. But when I run demo, it gets less than 20 FPS (so I am getting disappointed). I have unfaithful experience with Godot engine and searching a room to optimize it. Your demo is impressive in esthetical means, but some things could be better. Let’s list them!

  1. I don’t know if GPU particles are vertex-lit. I saw only two shaders in project directory. Because dust particles are simply points, not complex shapes, it would be reasonable to lit them in vertex style. It would be also nice to use CPUParticles3D to offload the GPU.
  2. Using multimeshes for ferns instead of mesh instances would be better, because it would lessen draw calls. It seems like there’s 3 draw calls for ferns.
  3. Occlusion culling in Godot 4 is achieved with Occluderinstance node. At least in editor it adds up to 9 frames per second (in-editor performance of scene is minimum 150 FPS, but that's because of ultra-low screen resolution and lack of realtime lighting). But this feature seems to be buggy, if you calculate occlusion buffers with baking, not manually placing them.
  4. I saw that normal maps for hammock are very high-definition. Maybe you could sacrifice diversity of texture for small tiled 32*32 normal map texture to achieve repeating patters of fabric knots.
  5. Wide light panels use 3 or 4 omnilights. Isn't that a bit too much? Is it possible to apply emissive material in Godot 4 to increase efficiency? Or using spotlight with projector texture in shape of rectangle?
  6. The terrain mesh has "inner" and "outer" part. The outer one is too wide and should be cut into several chunks, because it rarely gets culled in shadow atlas, so it leads to great overdraw due to its large size.
  7. What the polycount of scene?
    Everything was tested on Godot v4.2.1.
@Calinou
Copy link

Calinou commented Aug 21, 2024

I don’t know if GPU particles are vertex-lit.

This can't be done until godotengine/godot#43093 is implemented, although particles could be made unshaded for now as a mitigation.

Using multimeshes for ferns instead of mesh instances would be better, because it would lessen draw calls. It seems like there’s 3 draw calls for ferns.

Forward+ performs automatic instancing of MeshInstances if they use the same mesh or material, so using MultiMeshInstance might not prove as beneficial as you'd think in many cases. If the entire vegetation is already drawn with 3 draw calls only, that means it's working pretty well 🙂

Occlusion culling in Godot 4 is achieved with Occluderinstance node. At least in editor it adds up to 9 frames per second (in-editor performance of scene is minimum 150 FPS, but that's because of ultra-low screen resolution and lack of realtime lighting). But this feature seems to be buggy, if you calculate occlusion buffers with baking, not manually placing them.

Occlusion culling should work much better in 4.3 now that samples are jittered across frames. This means objects should no longer be incorrectly culled through thin gaps.

Wide light panels use 3 or 4 omnilights. Isn't that a bit too much? Is it possible to apply emissive material in Godot 4 to increase efficiency? Or using spotlight with projector texture in shape of rectangle?

Forward+ uses clustered lighting, so lights without shadows generally are cheaper than you'd expect. However, OmniLights with shadows are still relatively expensive, so their usage should be kept to a minimum.

Emissive materials can be baked in the lightmap, but only if their mesh has UV2 generated. Otherwise, they won't contribute emissive lighting to the lightmap.

Light projectors can also be used, but they require enabling shadows to be drawn due to how they're implemented.

What the polycount of scene?

Enable View Information in the Perspective menu in the top-left corner of the 3D editor viewport. This shows the primitive count for the current camera view (note that this metric currently includes the editor gizmos and grid).

@Capewearer
Copy link
Author

By the way, reducing shadow map size up to 512 Mb for Directional and other lights helps very well. It seems that videocard allocates much more than it can handle, so it causes framerate issues. And reducing shadow atlas doesn't even affect the final image!
I confirmed that Occlusion culling now works correctly. It's good now.
Polycount is suprisingly low. It would be okay if it was more than million, but it's not.
My another assumption is that there are many transparent materials that are too much expensive. Like whole tree texture is very big atlas with translucency. That definitely may hurt from pixel shader cost (But I'm not sure, I'm not graphics programmer).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants