How best to use my geometry in CastleTerrain?

Is it possible to apply the CastleTerrain texturing with its various layers and logic to any mesh? My ‘water mesh’ now duplicates castle terrain geometry but is fast to modify and rebuild. It is the same mesh as the one you gave me demo code for a few weeks ago but far more optimized so doesn’t have to rebuild x,z data. I would like to switch to using this to do the terrain too, as current terrain rebuild for 100x100 tile is slow. I want keep all the CastleTerrain functionality except use my geometry or use my code to generate the geometry. What is the smoothest easiest way to accomplish this? I find the TCastleTerrain code daunting because a lot is going on in that unit and I am not sure how best proceed.

Here are both meshes with wireframe. blue lines is water mesh, brown lines is castleterrain mesh. You can see them diverge undewater. Also I now have LOD working for my distant tiles. It will be handy to have terrain rebuilds be as fast as water for dynamically changing LOD as you move around.


My basic mesh is defined as

TBaseGridMesh = class( TCastleScene )
     public
     constructor create2( iLinkedTerrain : TBaseTerrainTile;
                          offset : TVector2);
     destructor destroy; override;
     protected
     fGridCount  : integer; { vertex count }
     fGridStep   : single;

     CoordinateNode : TCoordinateNode;

     function getcellcount : integer;
     public
     LinkedTerrainTile : TBaseTerrainTile;
     property CellCount : integer read getCellCount;
     procedure UpdateGraphics; virtual abstract;
     procedure InitializeData; virtual;
  end;                                   

and then I subclass that to tie it to the data. the subclass is currently keeping a TexCoordNode for quickly updating those. The TBaseTerrainTile is a TCastleTerrain tile parent that it gets its terrain data from. The basics will be simple enough to share eventually. I need to consolidate the classes and cleanup a lot.

Yes, you can take a look how AdjustAppearance in TCastleTerrain.Create in src/scene/castleterrain.pas sets up the shader – and you can essentially use this approach to apply this shader on your own mesh, created/updated in any way. The core are GLSL shaders in

  • src/scene/glsl/source/terrain.fs
  • src/scene/glsl/source/terrain.vs

You can just copy and adjust these shaders to your project :slight_smile: I hereby officially say (as the only author of that shader, per History for src/scene/glsl/source/terrain.fs - castle-engine/castle-engine · GitHub ) that it can be reused on public domain terms.

1 Like

Maybe it is a long shot or a long way off, I am hoping someday this will be a game I can sell as that is how I justify all this time with no income. Are you saying that isn’t an option if I use this shader (or castleterrain)? I plan to share my more general code with the group, like the icosphere, and eventually the fast deformable mesh classes when they aren’t so in-flux.

On the contrary, I said that you can still sell it (and keep the code closed if you wish) even if you reuse (copy to your project, tweak) that shader code or piece of CastleTerrain unit :slight_smile:

To give more details:

  1. the engine is distributed on terms of “LGPL with static linking exception”, see License | Manual | Castle Game Engine for details. This is the same license as used by FPC RTL and Lazarus LCL units. This means that if you just link your own code + unmodified CGE code, then the result can be distributed in binary form (and sold, if you wish), without you having to disclose your source code.

  2. It also means that if you tweak some CGE unit, and your code uses modified CGE, or if you copy some CGE piece to your own project – then when distributing (also when selling) you should make sure to distribute source code of your CGE modification. To be clear, you never need to disclose source code of your own units, but you have to disclose your modifications to CGE units, if you do this.

    ( The same rule would apply if you e.g. modified some standard FPC unit, like SysUtils source code – “LGPL with static linking exception” says that you then should show the source code of your modified SysUtils unit to anyone that gets the binary version of your project. )

  3. But my above statement, that places the shader code on public domain terms, means you can ignore the point 2 for this case. You can copy the shader code to your project, tweak it, and you don’t need to distribute modifications to it.

    That shader code is so trivial that frankly, I’m not sure whether the copyright protection would apply anyway :slight_smile: It’s not a problem if you copy from CGE code a few trivial lines and reuse them. I just wanted to make it 100% clear that it’s allowed by saying “this shader code may be used on public domain” terms.

1 Like

Thanks for the clarification. I am poor at reading the fine print. I am open to sharing all general code and/or cge mods. My resulting terrain code should be castle terrain compatible and maybe faster. The other major difference is that I only get the values from the tcastleterrainnoise once and fill a list in memory that I keep around. This allows me to deform the values, save, look up, and walk values very quickly when calculating water flow and water layer. It doesn’t really cost that much in the memory footprint.

Sounds good.

A potentially related development: Andrzej Kilijański is now working on terrain editing, the goal is to implement first 2 points from terrain TODOs on Roadmap | Manual | Castle Game Engine - edit terrain heights, edit terrain textures. This will include ability to “flatten” procedurally generated terrain height to grayscale image (to later edit it, just like in your case) and also fast editing of this texture on GPU and using it for rendering (using shaders, without the need to update the terrain mesh after each brush stroke on the terrain). This will be alternative terrain rendering mode, the existing terrain workings will keep being available as before. More info as we make it :slight_smile:

1 Like