Godot-docs: Generating Dynamic Geometry

[clayjohn]

I am going to write a series of tutorials on generating geometry dynamically. It will introduce the reader to the ArrayMesh resource, the MeshDataTool, and the SurfaceTool. It will cover generating geometry, modifying existing geometry (without shaders) and saving generated geometry to disk for later use.

I plan on the tutorials being a 3-part series under the "Creating Content" section.

[clayjohn]

My tentative plan is to split this into four parts.

Part 1: introduction

• introduces the reader to meshes conceptually, including how they are stored (as an array containing arrays of vertices, normals, uvs, indices, etc.)
• provides a high-level overview of how Godot handles rendering meshes (e.g. using MeshInstance, MultiMeshInstance, shaders etc.)
• basic introduction to each part, explain benefits and limitations of each technique

Part 2: ArrayMesh

• walks the user through generating a sphere procedurally with an ArrayMesh
• introduces the reader to saving meshes with the ResourceSaver

Part 3: MeshDataTool

• introduces the user to the MeshDataTool by creating an undulating sphere with OpenSimplexNoise
• high level description of MeshDataTool specific concepts (faces, edges)

Part 4: SurfaceTool and ImmediateGeometry

• walk user through creating OpenSimplexNoise terrain
• show off ability to index and generate normals automatically
• same example using immediate geometry
• discussion of benefits of surfacetool vs immediategeometry

[hidemat]

Hi. Please let me know if I shouldn't be posting here. I just wanted to suggest adding c# equivalents of the code. Taking into consideration that C# runs faster than GDscript, generating a huge terrain mesh might go smoother on C#.

[clayjohn]

Great suggestion! I would definitely do it if I knew any C#. Can I ping you once I have some sections with code in them to translate?

For simple things GDScript is fine because the heavy lifting is done by the engine in C++. For complex stuff I actually prefer using C++ with GDNative. But it would be very helpful to have GDScript and C# code in the tutorial for user reference. I imagine most users will be using one of the two.

[asheraryam]

Recently I've been working with all of these and I'd be curious in the performance details of each even though I have a good amount of collected info by now.

I found that ImmediateGeometry is the least performant, and after that I used SurfaceTool but currently I am writing PoolVector Arrays directly to create an ArrayMesh, but I am still not sure what is the best course of action between the last two.

What is the purpose of SurfaceTool if the same thing can be done with ArrayMesh? And which would be a better choice when the data is being recreated every frame (such as for animation).

(I have the array mesh generation happen in a separate thread so there is a slight lag but it is acceptable for my purposes).

[clayjohn]

There is some high level information already in #2375 check it and and leave some feedback if you can!

ArrayMesh is your fastest option. It is new in version 3+. SurfaceTool provides a nice immediatemode api without being as slow as immediate geometry. Plus it has helper functions to calculate normals/tangents/etc. There is a thread in the main github page talking about deprecating surfacetool in favour of the arraymesh though.

[hidemat]

Yes I would be happy to contribute. Ping me for sure. If I don't reply you can always send me an e-mail at [email protected].

[fire]

It's a lot easier to use surface tool rather than array mesh.

I wrote several importer prototypes including the final Assimp FBX one. It wouldn't be good to deprecate Surface Tool.

[asheraryam]

@fire I've seen your work and you're no doubt more experienced than me in this, so I'd like to ask what features does the surface tool that make it easier to use?

(I've been able to move all my code from using Surface Tool to Array mesh by simply changing the methods calls to surface tool to instead push to the array mesh poolvectorarrays -- vertices, normals, colors, and all).

[fire]

Surface tool allows you to bundle all the changes per each vertex.

It is arguably easier to do that than creating a 9 array array of the various types and making the vertex data align. Also there is some problems with the surface tool, it doesn't handle blend shapes.

I've done the work several ways, so it feels like add_vertex() is easier. At least it's more foolproof :D. It also has some functions [to] index the mesh and calculate normals / tangents of the mesh.

It's probably less performant, but it's in the editor import side.. To be honest, that code should be an ArrayMesh because load times can be long for the Nvidia test models with an entire scene.

https://developer.nvidia.com/orca

[clayjohn]

@hidemat I know its been a few months, but the tutorial is now ready for final review and for C# tabs to be added. It would be great if you are still willing to add them as I am not familiar with C#!!!

[hidemat]

Yes. I'm willing. Where do I start?

[clayjohn]

You will want to clone my PR you can do so with:

git fetch upstream pull/2375/head:procedural_geometry
git checkout procedural_geometry

Then you can make the changes in the relevant files (all found in tutorials/3d/procedural_geometry)

Code tabs are set up using

.. tabs::
 .. code-tab:: gdscript GDScript

  # GDScript code here

 .. code-tab:: csharp

  // C# code here

When you are done, you can push to your local fork and make a PR to my procedural_geometry branch in my fork of the engine.

Alternatively, if that process is too confusing, you can wait until the tutorials are merged and then add the C# code in another PR afterwards.

[hidemat]

Ok thanks.
Forgive me I'm a bit of a git noob, I'm running a windows 10 machine and have successfully installed git, and created a directory to store the files, but when I run this command:
git fetch upstream pull/2375/head:procedural_geometry
I get this error:
fatal: 'upstream' does not appear to be a git repository fatal: Could not read from remote repository.
Am I missing a step before I run this command?

[clayjohn]

Yes. You need to clone the repository first and establish a remote. Described here http://docs.godotengine.org/en/latest/community/contributing/pr_workflow.html

My apologies, I assumed you were familiar with the standard PR process already.

[hidemat]

No problem. Thanks for the info. I'll get to it.

[hidemat]

Hey @clayjohn, I can't seem to find the files that are in , but I found some in . Are these the ones I should modify?

[clayjohn]

Ah yes. Sorry, I moved them after I sent the above message.

[issacasimov]

Hidemat (or anyone) would it be possible to pastebin an example working code on basic c#/mono code for surfacetool? I've tried in the past but using outdated examples and just not getting it right(apologies for the lack of patience)

[hidemat]

Hi @issacasimov unfortunately I can't say that I can as I'm merely helping clay with the c# snippets. I still need to write them, and after that they have to be approved so, be patient please.

[hidemat]

Hey @clayjohn, do you have an rst workflow you could recommend? I'm trying to set it up so I can code on 1 side of the screen and preview on the other.

[clayjohn]

I usually just write everything up in vim and then once I am happy with everything I build the docs and check to see that everything is in the right place. It's not an elegant workflow but it works for me. Sorry I can't suggest anything more helpful.

[hidemat]

ok, thanks. Guess that's what I'll do too :).

[Calinou]

@hidemat Live reloading can be achieved using two separate tools:

• One that watches for file changes in the source directory and calls make html on changes. I personally use watchexec for this:

watchexec make html

• One that starts a local Web server and reloads the page automatically when files change. This also makes search functional in Firefox, as hosting a local Web server will avoid errors related to the browser's security policy. I use Browsersync for this:

browsersync _build/html --watch

This isn't perfect (the page will appear to reload multiple times on every change), but it's a start.

PS: Both example commands must be run from the root godot-docs project directory.

[clayjohn]

@hidemat I think what we should do is get the tutorial merged right away and then get your C# stuff merged afterwards as a separate PR. That way we can get the tutorial out as soon as possible and you can have the PR under your name exclusively. That way you'll have the little contributor badge beside your name too. :)

[hidemat]

@clayjohn Ok. Sorry I haven't done this yet. Been busy at work, and I'm still trying to master other aspects of the engine to feel capable of writing code for tutorials. Once I fully grasp how to work with meshes in GDscript I will get back to this in a separate PR. Thanks for your hard work, Clay.

[clayjohn]

@hidemat Don't apologize! I'm looking forward to what you come up with!

[Calinou]

What's the status on this?

[NathanLovato]

Hey @clayjohn, are you still working on this?

[clayjohn]

The tutorials themselves are done https://docs.godotengine.org/en/latest/tutorials/content/procedural_geometry/index.html

This issue was left open as hidemat was working on a C# version. But this can be closed as we aren't opening issues for C# versions for other tutorials.