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

Documentation contains a contradiction about ImmediateMesh use case #9915

Open
Lenda0210 opened this issue Sep 6, 2024 · 1 comment
Open
Labels
area:manual Issues and PRs related to the Manual/Tutorials section of the documentation bug

Comments

@Lenda0210
Copy link

Your Godot version:
4.3
Issue description:
The following sentences seems to contradict each other:

"Generating complex geometry (several thousand vertices) with this tool is inefficient, even if it's done only once. Instead, it is designed to generate simple geometry that changes every frame."
[...]
"If you only generate a surface once, the ImmediateMesh is just as efficient as any other kind of mesh as the generated mesh is cached and reused."

URL to the documentation page:
https://docs.godotengine.org/en/stable/tutorials/3d/procedural_geometry/immediatemesh.html

@Lenda0210 Lenda0210 added the bug label Sep 6, 2024
@skyace65 skyace65 added the area:manual Issues and PRs related to the Manual/Tutorials section of the documentation label Sep 8, 2024
@smix8
Copy link
Contributor

smix8 commented Sep 19, 2024

There are different stages of "efficiency" that this blocks are referring to that should be explained more clearly.

A CREATED mesh by the ImmediateMesh is just a normal mesh so neither good or bad for performance, just default compared to any other mesh created with the same properties.

The CREATION of a very large mesh with the ImmediateMesh is memory bloat because an ImmediateMesh uses internal local vectors as they work faster for regular procedual mesh making. The reason they are faster is because they are not copy-on-write and also keep memory forever occupied so when you update the mesh again next frame the memory is already available to work on.

A "normal" static mesh throws its data directly at the GPU and frees the CPU memory so when changing this mesh type all the time it needs to allocate new memory all the time and all its data arrays are copy-on-write vectors which makes the mesh creation very slow in comparison.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:manual Issues and PRs related to the Manual/Tutorials section of the documentation bug
Projects
None yet
Development

No branches or pull requests

4 participants
@skyace65 @smix8 @Lenda0210 and others