Thanks. I knew about the hat. I did not know about the horizontal alignment.
1 Like
so Mastodon is working 
They made some updates, and best is just compile latest GDExtension.
They’ve made some great updates recently; your best bet is to just compile the latest GDExtension.
Currently, I’m diving deeper into Terrain3D. They’ve implemented some really cool features, like Texel data and passing _control_maps directly into the process_material via the RenderingServer.
It is also included in the shader:
An interesting feature here is the auto_shader. Perhaps we could split the XYZ data and combine it with the color_map.
Have you looked into Terrain3D’s potential for improving collisions, using their existing RenderingServer → process_material pipeline?
3 Likes
Okay, let’s put this under the microscope:
uniform int texture_filter : hint_range(-1, 31) = -1; // Specify a texture ID or -1 for all
It is also interesting how this autoshading affects these particles; for manually painted grass, it just ignores it and won’t paint.
// Apply only to specified texture id, or -1 for all. Adjust blend values as needed
if (!auto && texture_filter >= 0 &&
((base != texture_filter && blend < 0.7) ||
(over != texture_filter && blend >= 0.3))) {
pos.y = 0. / 0.;
pos.xz = vec2(100000.0);
}
It would make more sense if multiple parameters could be passed to texture_filter, or if a color map could be used instead.
Additionally, I found the plugin to be quite fragile when it comes to saving data for some reason. Here is a video demonstrating the issue:
2 Likes
The control map is great but that type of particle grass is too graphically intensive - billboard or textured cross quad grass is much faster.
Anyway, my reason for posting :
An Open World database that can be useful for building scenes. They havent supported imposters but the feature was requested in the issues section.
The developer also has a couple of chunk management projects - a quad tree and a 3D chunk loader that uses spacial hashing arrays.
The comments on this video suggest it needs an update for more recent versions of Godot …
3 Likes
There is only so much this add-on can do, as all the logic is handled in GDScript—which is far less mature when it comes to Level of Detail (LOD). From my initial thoughts, I think you have a point regarding the grass.
For now, the reality is that a lower-level language is obviously better for the CPU and direct resource access; the downside, however, is the added complexity and the need to avoid data racing. On the other hand, the GPU is better suited because of shader scattering. I think shader scattering could have a place here if we use vertex color values as a code for “allowed/not allowed” placement.
However, this complicates things from a heightmap perspective. The mesh must already be generated if I want to read vertex color values, which is where I see the possibility of using a chunk loader to split the mesh. But again, this brings back the issue of texels, which were removed from Godot’s GPU side and now rely on the CPU. You can actually see this implementation in Terrain3D, where it is used alongside LOD for terrain, similar to how oceans are handled.
This brings me back to attributes and their storage. I briefly tackled this in another topic, but community ( Advanced Asset Scattering - #6 by normalized )members generally prefer verified solutions rather than trying to innovate with data stream handling—specifically, going back to textures. While using textures is easier, it gives you far less control over manipulation.
I tested creating heightmaps in Godot using CSG objects and then bringing them to life with Terrain3D, but the results were poor. It was highly inaccurate, regardless of the texture’s precision. A direct export and import of a GLB file is far less expensive and much more accurate. The only thing that would be great is if you could use a mesh as a collider without needing to duplicate it. I’m not entirely sure if Godot handles this efficiently, whereas RealityKit and Unity handle collision directly as a component of the mesh object.
All that said, it looks like I’m going in circles here! 
1 Like
Oh i forgot that the OWDB option was mentioned in your original post …
I had a look at the code and although it seems conplicated it does not appear to have multi-threading and so therefore it wouldnt be all that fast …it might be harder to modify OWDB to work in threads.
In my own tests I made a multi-threaded loader and there is in fact a large drop in frame rate (~20 fps) when new objects get added to the scene. That is even with add_child.call_deferred(scene). I need to test with Vsync enabled.
Maybe you are over thinking this … sometimes simple and crude solutions work best because they make dramatic cuts to the scene complexity (fog, distance fading, billboards, big hand placed occluders).
So maybe just use Terrain 3D and drop grass on a splatnap.
1 Like
Theres some good addons on the asset library :
Has multi-threaded terrain chunk generation, the scene hardly hiccups when a chunk is added.
Another one, similar to the last:
That one has grass, but the code is less clear…
And a bunch more solutions if you just search for ‘terrain’
2 Likes
If you are working with Blender and vertex paint you get a bunch of color values for free, without the need to load a splatmap. This can be an advantage, but what about writing splat information as hexidecimal values and using the colors as bitflags (r & ( 1<< channel)) then you get 32 splat levels in a RGBA32 texture. I made a terrain splatmap generator, a bit like the Terrain3D autoshader. I just need gradients to control the parameters. Or each color channel could divide into two, making each splat color have 16 possible values at 4 bit per channel.
I would work with mineral content, and density like … clay, silt, sand, gravel, rubble, volcanic rock, bedrock… Then minerals affect soil colors from river deposition and tectonic activity … But thats besides the point … i was making a game.
1 Like
Thanks for the suggestions!
I looked into those add-ons, but they seem better suited for generating random terrain rather than specific asset placement.
Splatmaps are a solid option for masking textures, but to be honest, I’m more intrigued by GLSL and the Render Server, so I’ll be digging into those next.
I found this asset (Storage Buffers Compute - Godot Asset Library) which might help me use GLSL.
Have you worked with this specific addon or workflow before?
No, i havent used the addon, I just work with the Godot Demo projects examples and a couple of user contributions like the solar system example.
I am using a subviewport render target to render the splatmap. Its a shader that renders to texture, it could also be a compute shader but those have more complicated setup scripts.
I would like to render to multiple textures in one shader pass.
1 Like
It is possible to handle up to four of these under a single sub-viewport, or to pass data into multiple viewports using a uniform while keeping it all within a single pass.
1 Like
I couldnt get that OWDB addon to work properly in Godot 4.6. The DB runs in the editor but then nothing appears when the game is run. I had the OWDB position as a child of the player, and various different chunk distances.
1 Like
Short update on road where this is all took me .
From looking into engine source code, into add-ons gutters, to GLSL (which I’m still cracking) to RenderingDevice and RenderingServer .
Even when we have enough vertices the texture’s lacking in sense of natural deformation over bumps, edges, and often on Y axis.
This could be solved with noise and masking the distribution of each to mix them, but it will all comes to scale and UVMapping, in this case .
Examples are from Terrain3D, what could be potential solution to this ?
I am also still looking into asset placement, specifically regarding normal directions and minimum mesh sizes.
Additionally, I’m not entirely sure about collisions yet. It would be a great feature to use simple primitives (like cylinders) for tree bases, while utilizing trimeshes for more complex geometry.
The overall goal remains data streaming. However, I believe the approach used in The Witcher 3 ultimately relied on strict triangle counts and dynamic collisions utilizing mesh proxies.
2 Likes
You expect people on the forum to innovate for you? 
There’s no mystery whatsoever in scattering stuff. It’s straightforward:
- Generate sample positions that uniformly cover the chunk using blue noise (aka poisson disk sampling)
- Reject positions based on heightmap gradient (which you always have)
- Additionally reject positions based on biome map (which you need to generate one way or another)
- Place objects on remaining positions.
Sampling the heightmap and calculating the gradient is much cheaper than doing it from a mesh.
Generating a large amount of blue noise samples is somewhat expensive for real time but if you’re only streaming the database, then you can pre-process it.
2 Likes
It might sound a bit demanding, but I want to swap the usual answers for something more experimental to see what works.
You’ve provided a great breakdown; I’m going to give it a go and see how the metrics look.
Thanks for the response!
1 Like
How do you know which answers are “usual”?
People keep saying it: Honestly, if you click through three different threads and see five different people giving the exact same advice, that’s your answer. When the internet actually agrees on something, you know it’s the standard(usual) answer.
2 Likes
Perhaps it’s usual because it works well. So why waste time chasing some imaginary “experimental” approaches when there is a good common solution to the problem.
1 Like
Are you serious?
1 Like