I'm surprised how difficult it is to find information on this particular scenario so please let me know what the easiest way is. I'd like to know what's the simplest GDScript example for offsetting the vertices of a CSG node along their normals, for instance on a CSGSphere3D for random terrain on a planet.

I only need a few basic rules to be followed: The script must iterate through all vertices, read the intensity of a 3D noise at that location, then move the vertice up or down based on noise value. Movement is done in the normal direction not on a fixed axis, so for a sphere it goes toward or away from its center. The script should modify geometry on the CSG node it's being ran on, it should be computed after children's geometry was merged into self and before self's geometry affects its parent. Obviously collisions should be recalculated, CSG nodes do this automatically so hopefully the script doesn't explicitly need to trigger it.

I won't use shader displacement as it doesn't affect collisions, I'd have gladly made a custom shader but with no way to make it collide it would result in ghost terrain. As I may have things such as tunnels or caves cutting through the terrain as well as objects merging with it, I explicitly want CSG for its extra flexibility, hopefully the same vertex functions can run on both CSG and standard meshes.

  • xyz replied to this.

    MirceaKitsune CSG objects (with exception of CSGMesh3D) don't maintain any vertex data. They represent implicit procedural solids. There are no vertices to displace there. They are just mathematically defined volumes (solids), primarily meant to be combined at runtime using boolean operations. That's why they are called Constructive Solid Geometry.

    Engine does turn them into mesh representation internally since that's the only way to render them. However, this mesh data is made "on the fly" and used only for rendering and possibly for automatic collider generation. It's not editable by the user because that wouldn't make sense in the context of constructive solids. As you already noted, the only displacement you can do is purely visual, in the vertex shader.

    It's likely that you're misusing CSG here. Go with regular meshes instead.

        xyz Aha, thanks for clarifying that. I thought CSG nodes internally convert to a standard mesh, and are just an added layer of modifying them with boolean operations first. They're a more different system than I realized.

        My question then would have been if we can intercept and modify CSG shapes before they're generated to mesh / collision. But you clarified that too, sounds like it's impossible. Unless scripting a custom CSG shape from scratch, is that supported?

        I could likely still use an answer to the same question but for standard geometry instead of CSG. Though in this scenario I'd rather go with a different setup and generate a view tesselated mesh: Might ask about the concept I had in mind with that later.

        • xyz replied to this.

            MirceaKitsune If you just want to displace vertices on a sphere, you don't need CSG. It'll only burden your system with unused CSG stuff, possibly hinder the performance compared to using a regular sphere mesh.

            Displacing a plain sphere mesh vertices is simple, so is generating a concave collider out of it. I don't see any reason to use CSG here.

                xyz True. I preferred CSG since then I could more easily dig tunnels through terrain or merge other objects with it, but that's not really important or a concrete plan. Still thinking how to achieve what I want the best way, will get back to it a bit later.

                • xyz replied to this.

                    MirceaKitsune I think you need to settle for a simpler system at first, something easily done with your current knowledge. Fully implement a prototype with that.

                    Judging from your N previous topics, you're constantly sabotaging what you do by trying to cram in complex features, and then switch to something else when it becomes apparent that it's too complex. Beware the feature creep 😃. Better to make a modest thing first, but do finish it. At least you'll have something fully functional to show for your efforts 😉

                        xyz Was thinking something among those lines 🙂 My goal for a while was to find a magic way to obtain something of very high quality but using simple means, there's always an obstacle and whenever one such way doesn't work out I'd look for another. I have a few simpler and more supported techniques in mind now... I actually managed to convert a marching cubes algorithm to GDScript which used to work in 4.0 beta, may as well use that since I had it in working order last time.

                        • xyz replied to this.

                            MirceaKitsune Just remember that you had problems implementing a simple character controller on a plain sphere. Doing it for a marching cube terrain might be way harder.