Few technical questions on CreateGroundFromHeightMap

I’m loading ground terrain from my datasource (server side of game engine) and making a bipmap just to feed in to the CreateGroundFromHeightMap . I had a look at the code and saw that i could probably optimize the speed in my situation by forgoing the bitmap layer since i can return the actual point heights in an ajax called array. but is this actually faster/better? i wondered does dealing the bitmap have some fundamental benefits (speed/simple/cross platform way to move buffered ints around).

Also the height map seems to be using gray scale for it’s height calculation in the samples i’ve seen. but looking at the documention and code. color filter seems to be intended for either a filter or a way to scale each color’s contribution. Am i wrong in this? so if i want to make an 24 bit number represent the height i can just put 8 bits in to each color and use an appropriate color filter to scale the red blue and green to be those parts of the height basically (0.00390625,0.0000152587890625 and 0.000000059604644775390625) right? the alternative is just to write a custom version that has the mapping hardcoded (so maybe a bit faster).

also do any of the optimize mesh functions remove “pointless” polygons (repeated flat areas). it occurs to me that unless i’m making a mountain there is A_LOT of repetition that could be removed to save on polygon count in most situations. Though that may not be ideal if textures need those faces. but assuming i’m stretching 1 texture over the whole thing. would it make sense to do some sort of runlength encoding of the polygons to cutdown on polygon count… basically try and make it smart that the height isnt changing over an area and make one big square instead of a bunch of little ones? if this is reinventing the wheel (exists in some form in the other optimize functions) or if there isnt much gained due to runtime processing costs or complexity, i’d love to know (either way).

finally, as load terrain in chunks and dispose the mesh as they move away, i was wondering is it a bad idea to just add a wall straight down at the edge so “this” image doesn’t happen. or is there a good way to merge the meshes but then later remove the section being unloaded? I also toyed with the idea of having 2 edges of each ground mesh share 1 set of pixels with the previous 2 edges so they fit together like a lock and key. i stoped short of doing this cause i didnt want any flickering where to textures/triangles perfectly overlap. how do people normally handle this sort of thing?

Not sure it would as it might not compress like png would do but might be worth testing :slight_smile:

Nope, this would be accurate.

Not really unfortunately, we do not have a function to optimize geometry as such but it is a nice idea :slight_smile:

About the lod and dynamic loading I will let @jerome shine in as he did an amazing job with this previously.

1 Like

I ended up doing what i supposed was going to be “bad” but i think maybe it’s okay. so my terrain was 255x255 per chunk. instead of stitching the meshes together i did just just make them 256x256 so each chunk had a 1 pixel/block overlap along two edges and a corner 3 neighbors. the chunks seem to fit together nicely (i dont see any flicker for whatever reason at least yet.) it does require some more processing but i think its just a necessary evil to make it look nice and load it piece meal.

later, maybe in the months to come i’ll experiment with some of the filters and optimizations that might help out performance. i’ll probably implement the filter sooner than that but till i get textures/biomes, trees, creatures and water/rivers all rendering the height filter can probably wait. (unless it becomes an issue)

1 Like

I thought you would like to know. i did end up making a custom version of the ground height algorithm. it works pretty well. i basically took out a bunch of conditional code that while nice for general use, only slowed down my code. I also changed it so that it could read in a javascript array the map data. i figure between gzip (giving me fast data transfer on json data) and my need for raw data for the game this is the best mechanism for me anyway.

I have noticed, that when i get far away for origin in the X axis the mesh rendering of the gui seems to get weird. strange. like there are all kinds of rounding imprecision based on camera location. I’ll probably relocate the meshes to a 0 height and just record a virtual offset of the player instead of rendering at 250meters up or down (or more) … if the go above or below about 250 from origin. i’ll recenter the all the mesh positions and adjust the internal offset (so the terrain will move down). the brief shift probably wont be noticeable and if it keeps the rendering from being less buggy all the better.

the only other thing i thought i’d mention was the optimization for less verticies. i’m gonna save this for later. i think i’ve got a handle on how to do it … it probably should be done serverside and sent back with the raw data to make processing faster, but for right now that’s not low hanging fruit and i have a game to write! here’s a for fun screen shot of something rendered from development . (cause its fun to share)