Ways to Obtain and Process Additional Landscape Information

Development World Creation
, , ,
1

Hi all,
I’ve been playing around with PCG lately, and I would really like to “bake” some additional information into the landscape sequentially - outside of edit layers and weight painting for materials.
I’ve found some parts of the puzzle, using Render Target Textures and Post Process materials, but I feel like there might be better ways.

I think the best way I can describe it is by example:
While generating a forest on some landscape, after placing the larger trees, rock formations, and the like, I’d like to sample some amount of points equally distributed throughout the terrain. From these points, a hemisphere of raycasts is done upwards, counting intersections against non-translucent geometry. That way obtaining “sun exposure” values (hitCount/rayCount) for different spots of the terrain - resolution may vary.
Then, back into PCG, I’d use these points to filter a new sampling of the landscape, and place some shrubbery based on sun exposure and non-occupied spots (would require retaining earlier sampled points between steps).

The example is simple, but the approach could be extended to obtain information about clearings, drought-levels (distance from closest point on wetland layer + sun exposure), wind (amount and direction at some point, based on landscape heightmap and prior PCG population), available nutrients … etc.

All of this would be editor-time, i.e. not evaluated at game runtime, and sequential. Preferably, the baked information would be “re-rendered” on changes to prior steps, but that can be a topic for another day. Also, I’ve yet to delve far into C++ (I have a feeling that is the place to go), but it doesn’t seem too bad (famous last words). I have experience in other languages (Java, C#, GoLang), as well as OpenGL and GLSL, but it would be nice if parts of these processes could be exposed to interop with other Blueprints.

Any suggestions are appreciated!

2

Isnt it better to go the other way around?

Place large trees. Now you kmow where they are, within X radius from them you cannot grow X plant.

Place smaller tees, now you know that in x radius from them you cant place some other plant, and so on.

Its all baked on itself rather than having to cast and do other crazy things - which you couold still do, but it does become more insane as you go performance wise…

3

True, that’d be a vastly easier approach, and can be done in PCG alone.
One problem though, assuming that sun is where some X sampled points ain’t, isnt as flexible. I.e. you would have to keep track at all sampled points and placed assets all the time, whereas resampling the terrain for sun exposure, would be more expensive, but could be done at any time.
Would probably also pick up more “accurate” information about the state of the terrain.

4

In theory yes, but in practice no.
At least.

It doesn’t even work right when you set up a skm to have 6 sockets that determine light coverage for rogue-like games most of the time.
And its generally due to meshes, the fact you cant really know unless you look for if they are transparent. The fact that foliage may or may not trace depending on wind, the fact that you have to trace all nearby lightsources increasing computational runtime costs, etc.

So the chanches of it working better than you defining a shaded area are kinda slim.
And/or depends on how the trace is conducted.

Btw, instead of “keeping track” you could just bake textures of the sun area based on the same mathematical infromation.
Write to RT > save the RT for use if in engine, or use the RT after generation.

Since its an RT, you can write one tree, place the next and write that progressively (the more you write the more it costs, so keep write calls batched as much as possible).
Once you are done writing the read cost is always neglegible, so you can perform operations off said texture.

A stoopid approach - because performance is a thing - would be to set up a live trace of the same behaviour while trees that cast shade are made to output a decal that’s only seen by a scene capture2d set to orthogonal and capturing only those items that compose the shadowing. (Rather than a dacal, a properly srtup niagara emitter?)

It could be useful if you set it to update only when update operations occur - say like player chops a tree.

Overall, get used to dealing with textures to store data since you can easily save it.

But do consider that even on avarage CPUs saving a straight up array of data with some tuples (loc v3 + radius, so a v4) is probably eons faster than it is for the Pc to write to texture.
so long as you don’t go looping over the saved array