-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Properly document Mesh.surface_update_region #3787
Comments
After profiling. It turns out that the use of |
What other methods of changing geometry from a script on each frame are there? |
@doko-desuka You can use ImmediateGeometry (which is slow with hundreds of vertices or more) or shaders (which are the fastest way, but with no communication from the GPU to the CPU). |
Also see the procedural geometry tutorial which has a full discussion. |
@clayjohn thanks for the link. I can see that But there's no apparent way to update the arrays used by |
@doko-desuka The current way is to use add_surface_from_arrays the way it is done in the tutorial I linked.
|
@clayjohn understood, thanks! |
@doko-desuka Thanks for the link! That is a little different from what is being discussed here. What you have linked there is also how the Polygon2D node works. It doesn't involve meshes at all, it uses the VisualServer API to issue a canvas item command. Keep in mind, this issue only relates to updating ArrayMeshes dynamically using the |
@clayjohn Ah I see, thanks for the details. It would be interesting to test later on if a C# script has that same overhead problem from your comment above, about Since I'm interested in having a 2D deforming mesh, I'll see if I can compare this C# array method with that |
@doko-desuka I'd be very interested to hear about how it performs in C#. In C++ it is significantly faster to use |
Note to self (and others): I will come back to this after 4.0 releases. Currently this group of functions is not worth using from GDScript in 3.x. However, with the updates to GDScript in 4.0 and the changes to the rendering API, this documentation will be very helpful. In particular see godotengine/godot#47761 |
The documentation for surface_update_region() currently says not to use it because it can be quite dangerous. While that is true, it would be a lot less dangerous to use if we actually documented how it works. The benefit of
surface_update_region()
is that it updates the OpenGL vertex buffer array directly. This saves a lot of overhead in the VisualServer, plus you don't have to delete and re-allocate buffers every frame. Accordingly, it is the fastest way to update meshes dynamically, but it is very complex and it is easy to completely break your meshHere I will lay out plans for updating the documentation appropriately. This is more for me than anyone else.
First: update Mesh.surface_update_region() and the corresponding VisualServer Functions.
Next: Add a tutorial to the Procedural Geometry series using
Mesh.surface_update_region()
.Mesh.surface_update_region()
is the fastest way to have dynamic geometry. It is used internally by softbody meshes and Sprite3Ds. But it can be a real pain to work with. The tutorial will have to outline how to access the vertex buffer properly. As well as explain how each part of the buffer changes when mesh compression settings are used (since GDScript doesn't havehalf_float
's this section will only be useful for GDNative and maybe C#).Below is example code for the extreme basics.
The text was updated successfully, but these errors were encountered: