I followed this tutorial, and now I have some grass, and I can control the wind noise, direction great -

but it's a square, I would like to be able to draw where I want the grass, or have some other form of control over where there is grass and where there isn't. How do I go about it?

Thanks for your help in advance.

    Sellith At the beginning of the tutorial a mesh is created in Blender that serves as a surface to grow the grass from. Just create a differently shaped mesh instead.

      xyz Thanks, I can see how that can solve the problem in a way - but what I'm worried about with this approach is that that means I gotta make a seperate mesh in blender that matches the shape of my patch of grass each time I need a new patch of grass on my terrain, is there a more practical solution where I can draw the grass onto the terrain (or even draw a mesh?) or maybe some type of mask or is this solution more practical than I'm expecting? Appreciate the help.

        Sellith You can spawn instances based on a texture or make a tool to draw them. You should be able to find tutorials on how to do either.

        Sellith don't use a multimeshinstance3D, and that tutorial is bad.
        multimeshinstance3D should not be used, it is there, it is part of particle systems and can be used to do some nice things like groups of fish.
        but it makes no sense for something that doesn't move, like grass.

        1 - multimeshinstance3D sends a transform to the gpu for each instance of the mesh, and when your mesh is 4 vertices it is a waste of resources and will even slow down the scene.
        2 - these transforms make sense if the object must move every frame, like with particles. using it for grass is bad.
        3 - multimeshintance3D doesn't make use of culling, so it will lead to a loss of performance, specially in big open scenes like these.

        what you have to do is:
        create your terrain in blender
        create the grass that goes over the terrain, and put it all in a single big mesh, or one mesh for each patch of grass (if the scene is massive).
        for animating the grass, use a vertex shader on the grass material.

        advantages:

        • you are sending a single mesh, that even with a lot of stuff will still be smaller than something like a character.
        • because it doesn't move it can be stored in the gpu as static, which is faster.
        • you get complete control over the grass, and can add all the variations you want, you are not limited to a single mesh duplicated multiple times.
        • modern gpus are good at rendering high polycount, you won't get a problem with performance.
        • culling if using multiple patches of grass on a massive terrain.
        • fewer nodes, easier setup.

        Sellith I gotta make a seperate mesh in blender that matches the shape of my patch of grass each time I need a new patch of grass on my terrain, is there a more practical solution where I can draw the grass onto the terrain (or even draw a mesh?) or maybe some type of mask or is this solution more practical than I'm expecting? Appreciate the help.

        godot, as far as i'm aware, doesn't have mesh batching as of yet, which would be what drawing grass on a terrain in editor would need. multimeshinstance3D is not it, it is designed wrong and misunderstood by people who seek quick, shallow ease of use of the engine.

        • xyz replied to this.

          Jesusemora Multimesh is one draw call. Godot even fuses multiple MeshInstance3D nodes into one draw call if there's an opportunity (i.e. when the drawn mesh resource is the same). Where do you get your info from?



            xyz that is instancing. I'm talking about static batching.
            instancing is rendering the same mesh multiple times. godot does this as explained by @Calinou
            does godot support static batching or gpu instancing
            but it doesn't always happen, it is limited by culling and LOD.

            static batching on the other hand is per material
            static batching explained

            and I just can't imagine it exists in godot, since all meshinstances can be moved at any point, there is no way to set them to "static".

            there's also this:
            is there 3d batching in godot 3x?

            I found this from 3.5, but it's for 2D:
            https://docs.godotengine.org/en/3.5/tutorials/performance/batching.html
            apparently godot 4 must have it too because it was being added to compat in 4.4

            discussion that went nowhere from 2020:
            https://github.com/godotengine/godot-proposals/issues/2049
            they abandoned the idea of static batching in favor of instancing (called dynamic batching), because "vulkan draw calls are cheap".

            • xyz replied to this.

              Jesusemora Not sure static batching could beat instancing for foliage on modern hardware. Plus instancing is much more flexible for runtime manipulation.

                xyz instancing only makes sense with objects that have high polycount and objects that need to be updated every frame.
                foliage does not move and is not high enough to justify instancing.

                for now, combining the foliage in blender is the best solution, because it turns into a 20k model instead of hundreds of 40 poly meshes.
                wind can still be done through a vertex shader, reacting to the player can be done with a vertex shader. maybe not rotating or doing an animation, but that should be done on a few plants that the player will get close to, not with all the plants.

                • xyz replied to this.

                  Jesusemora There's no Blender if you generate level layouts dynamically at runtime. It also makes total sense to instance instead of batch if profiler says it performs well on target hardware. Much less hassle and you can paremetrize the density and transformations. All this makes instancing much more flexible for many use cases.

                  You can also fuse meshes at runtime from instances after you've made the all the adjustments, if you can't live without static batch or your target hardware is not happy with the instanced draw call.

                  Vertex shader is a no brainer for standard stuff (sway, interaction...) in any case.