Howdy again ... guess it's time to contibute something useful again ( *looks at his last posts* )

in this thread i'd like to discuss some terrain rendering specific topics the last two or three weeks i was reading some articles and now the org.xith3d.terrain packages gets orphaned ... so i'd like to start some talking

i'll post two posts first:- a small overview about common technics with pros and cons- some thoughts that i've developed during the last weeks and like to have some comments on

this post is about common technics of terrain rendering. Some of them became obsolete when those high powered graphic cards came out ... and some won't get listed here ... but i'll do my best to give you a small overview about this topic

[size=12pt]In the beginning ... [/size]... there was the developer ... he was able to talk software and he thought it was good as long as he wrote the best alghorithms.The developer thought it would be cool if he'd be able to show large terrains on the computer screen and developed voxel terrain engines. The results looked beautiful and the developer was happy. ( have a look at http://www.outcast-thegame.com/ fro some examples )

[size=12pt]Voxel Engines[/size]Actually i don't know nothing about voxel terrain rendering ... and list them here just for completion ... but voxel terrain is calculated entirely in software, stressing the cpu on large terrains ... i read somewhere that there may be a voxel comeback due to the large calculation power of current cpus ... but i don't really believe in this cause nvidia'n'co will build larger gpus too and all terrain rendering will be based on polygons ... but ... who knows ...

[size=12pt]Introducing Polygons[/size]... the developer was greedy ... and he thought of new ways of rendering larger and better terrains ... one of this ways was polygon rendering ... but soon the developer found out that it was necessary to decrease the number of rendered polygons in order to render large terrains ... and again he sat down and thought about better algorithms ... he came up with an approach that would be called ROAM which could decrease the resolution of the rendered terrain where necessary ...

[size=12pt]ROAMing Terrain[/size]ROAM ... short for Real-time Optimally Adapting Meshes ... is a way to render large terrains with the minimum number of polygons necessary ...there are two major implementations of this: split and split/merge roaming they both have in common that they rely on splitting a isoscele triangle in two new isoscele triangles:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

* / \ / \ / \ / \*---------*parenttriangle

* /|\ / | \ / | \ / | \*----*----*twonewtriangles ( children )

(hopefullythisisunderstandable)

the difference between the two implementations ( split; split/merge ) is that with just splitting the whole splittree is recalculated each frame whilst with split/merge the tree is kept in memory and there are checks for each triangle wether it is necessary to have the higher resolution ... else the triangle is not splitted if it has no children ... or the children are merged into the parent triangle

the decision wether to split or not varies from implemtation to implementation ... but i think a screen pixel error based solution will work best here ... ( more on screen pixel error further down )

if a triangle won't be splitted it will be send to the graphics pipeline to be rendered

the pros:- very dynamic resolution just depending on the decision algorithm- as the terrain is recalculated each frame dynamic terrain is easy to implement- very low memory usage cause no per vertex data is kept- allows for frame coherence ( just split until the frame time is up )

the cons: - gaps: actually gaps are found in every terrain implementation at places where a higher and a lower resolution piece of terrain hit each other ... in roam this is avoided by an easy algorithm based on splitting the base neighbour if necessary- time: the terrain is recalculated every frame, there are ways to avoid this but they would require dynamic triangle counts which are as far as i know not avaible in xith- doesn't use any hardware optimisations

references:- an article with the title "ROAMing Terrain: Real-time Optimally Adapting Meshes" by ... hmm... someone with the name Turner i guess ... the article can be found on gamasutra.com here: www.gamasutra.com/features/20000403/turner_01.htm

[size=12pt]Introducing Hardware[/size]... but the developer was restless ... he found that there were graphic cards with high memory on them and he decided to transfer as much load from the cpu to the gpu as possible ... he found that there was the possibility of using some technics of imaging in his work and came up with geomipmaps

[size=12pt]Geomipmaps[/size]in mipmapping there are several copies of a texture stored in memory each at a half the resolution of its parentas modern graphic cards have huge memory banks on them these copies can be stored on the cards freeing ram and allowing for fast transfer to the graphic processorgeomipmap terrains consist of several evenly spaced blocks which i like to call patchesthese are layed out in a binary or quadtree allowing for fast culling as a first optimisationfor each patch there exists precalculated data representing the terrain of this patch at different resolutionslevel 0 means full resolution, each higher level means half the resolution of the last level

the decision which level to choose is again implementation dependend .. i'd recommend screen space pixel error calculations:it's not that hard to understand: for each patch the maximal change in height per level is precalculated than it's checked if this change results in a user seeable popping. This is done using the viewport and some easy calculations ( ok ... i confess that i write this somehow unprepared and have the papers not at hand

the pros:- uses the benefits of current hardware to free the cpu from calculations- allows free detail levels - very fast

the cons:- more memory requirement than other approaches ( but graphic card memory is used )- terrain changes require recalculation of patches- gaps: as above need some tweaking to avoid these

[size=12pt]Beauty[/size]the developer was happy with his work ... however he was annoyed with the popping of terrain that happend sometimes ... he thought that if he could find some way to slowly morph between two states of detail he would be pleased ...

[size=12pt]Geomorphing[/size]this is essentially easy: take the to detail levels and define a function that gives level a if you put 0 in it and level b if you put 1 in ... than calculate this over several frames ... the result is a smooth 'morph' between two detail levels( ok ... it's not that easy ... but i think it's easy to understand that way )

as you remember correct the vertex data of the geomipmap approach is stored on the graphic card ... this is where newest features of graphic cards kick in: vertex programs are able to modify vertex data before it is rendered on the screen.geomorphing can be implemented as a vertex program which reduces cpu load alot

( actually i can't say more on this topic cause i'm waiting for my new graphic card since one week now ... and so wasn't able to work with vertex programs etc )

[size=12pt]Rest[/size]the developer was happy with his work ... and set down to rest i'm not that happy about my article as it just covers two technics ... but i decided that these are the easiest ways to render terrain ... and i believe they are the ones most suitable for xith ... there are of course other interesting ways, terrain rendering got some sort of academic disciplin ... but ... let's Keep It Simple, Stupid

any questions on this first post can be posted here ... i'll take some time and continue with the second post ...

in this second part of my writing i'll try to explain what kind of terrain implementation i'm aiming at if you have any questions please feel free to ask

[size=12pt]Representation of the Heightdata[/size]although the usual way to handle height data is a heightmap, represented by a grayscale bitmap, i'd like to show that there are other ways without giving up compability to the old method

Normalized Heightspaceunder this definition i'd like to define an area in 3d space which is exactly 1x1x1 unitsif you'd look at this area you'd see a representation of an terrain with evenly spaced points acting as it's heightdatano matter how large the terrain resulting from this data is every coordinate is inbetween 0.0f and 1.0fthis is a graphical representation of what i tried to explain above

HeightSpace Interfaceto implement this in java i provide an interface which has these features:

float getHeight( float x, float y ):gives you an normalized heightvalue for this point ... x and y have to be between 0 and 1 the result is also between 0 and 1 ( except for a some times i'll explain below )

float getMinResStep(): gives you the number that a value has to be increased to get the next height valueExample: you have an 10x10 field heightmap. getMinResStep would give you 0.1f cause you'd have to increase for example 0.0f by 0.1f to get the next heightvalue

ok ... now i said before that there are exceptions, that the returned height sometimes is not between 0 and 1 ...i'd like to have the functionality that parts of the terrain aren't rendered so if getHeight() returns a value < 0 a flag is setif a triangle has this flag for all of it's 3 vertices it isn't drawn ... easy huh?

Implementations of HeightSpaceok ... now you may shake your had and think 'that boy's crazy or stuff' ... but i'd like to show you the benefit of this waythe old approach of representing heightdata is to get a greyscale image and make a terrain from that, but there are numerous ways to represent height data ... for example you could ( and i'll try to implement that one ) use a quadtree which nodes are bezier patches ... this would provide almost unlimited detail heightdata ... and thats the reason HeightSpace does have a getMinResStep and no getNumOfHeightValuesPerSide

Terrain Mechanismi think the system should use a geomipmapped approach just like the one in org.xith.terrain ... a heightspace object is loaded and then scaled to fit the users wishes ... although i'd like to add the optimisations mentioned in the above post. geomorphing is implemented as a vertex program but if this isn't avaible old fashioned software calculations should be used

Interoperability with level geometrythere are two things i'd like to say about this:

a: detail geometry and stuff quadtree based frustumculling speeds up terrainrendering alot ... but it can do more. My implementation ( which honestly is far from complete ) uses the xith scenegraph and culling for it's culling ... now if i would add level data ( for example trees buildings etc ) directly in this quadtree alot culling calculations could be omitted when for example one topnode of the quadtree is out of boundsthis of course would work just for static or static animated stuff or would need some coding that objects can change it's parent quadtree part

b: indoor levelsremember when i said i'd like holes in my terrain? in this holes i'd like to add indoor geometry ... if the terrain would be rendered at these places it wouldn't be possible to go deeper than the heightmap

Texturesactually i was very dissapointed by the Terrain demo cause it was plain greyscalethe texture should feature a 2 texture surfacethe one texture defines the overall look and should be created from several images and the heightdata ( for example everything above 0.8f uses the snow image ) ... this texture is scaled all above the landscape and should fit with mountains and valleysthe other texture is a detail texture which is scaled at a much lower rate so that it repeates all over the terrain

ConclusionI think that should be it ... it's much ... but it's just enough for xith as i mentioned i have some parts of this already implemented ... but nothing is yet presentablenevertheless i'd like to see some nice comments and stuff ...

Wow, wow, wow nice job explaining all this !!! I actually like the idea of bezier patches very much. Oh yes! a function for the terrain, where you simply can say getHeight(x,y) that returns you a height value for any x,y value would be a nice idea to start with. Then you can also have dynamic positions for the vertices.

About coloring the Terrain:For that I have in my terrainloader a alphamap, that specifies the visibility of a texture, and then I layer different textures above each other:

snow*snow_alpha +gras*gras_alpha +sand*sand_alpha

the alpha textures are not wrapped, they span over the entire terrain, but the can contain a pretty low resolutionthe other textures are wrapped, so allow a pretty detailed ground.

Pros:Terrain is easy to paint (you'll only need some pictures)Nice slow fades are possible

Cons:Lot's of layers are needed (some graphic cards got only a low number of TextureUnitStates e.g. 2)For this the Geometry would have to be created several times and then put above each other with some distance (which is visible)

There's also a fix for the duplicate creating of the Geometry, simply to split the terrain into several chunks and then to don't create the terrain that never is possible to be seen (either because the alpha-texture is there completely transparent, or because there is an totally opaque layer above).

i prefer the implementation that is used in the jme terrain systemthere you have a texture constructor which first takes a heightmapthan you register several textures and specify at which heights this texture is usedthen you tell the constructor to create the terrain texture and you get a new texture with smooth blended transitions

have a look at the jme system to see this in action ...not much time ... Florian

i must confess that i'm not that conviced by whome's article cause it uses too many texture unit states and i think that an open library should sacrifice performance where compability is needed

in my opinion 2 texture states should be enough to give a nice looking terrain which is usable even on older graphic cards ( think gforce 4 downwards i guess )

if i got it right the splashshape thing uses multipass rendering does it? guess that would affect performance alot altough i don't know how far ...

on the other hand we have an advantage cause we have seperate patches which could get different detail textureswith, say, 5 different detail textures the 'repeat-effect' wouldn't be that strong ... if these textures would be freely rotatable ( with each edge fitting to each other edge from any texture ) this would result in a large amount of combinations ...but that would restrict the user alot cause it's not that easy to get those edgefitting textures ...

actually i'm no expert with textures ... but i think a better solution should be found ... and if there aren't any good i guess we should fall back on the 'overall+detail-map' scheme cause it is ( in my eyes ) the most commen used

i had a look at the demeter terrain engine and now i think it's a good idea to use the splat shape approach cause it allows ( of course almost ) unlimited textures on the terrain ... i'd give the user a 'splat texture at point on terrain' function too ... this way he'd be able to easily add trails, roads, and stuff to his landscape without having to deal with creating additional geometry and fitting it exactly to the terrain ( z buffer problems )

i had a look at the demeter terrain engine and now i think it's a good idea to use the splat shape approach cause it allows ( of course almost ) unlimited textures on the terrain ... i'd give the user a 'splat texture at point on terrain' function too ... this way he'd be able to easily add trails, roads, and stuff to his landscape without having to deal with creating additional geometry and fitting it exactly to the terrain ( z buffer problems )

the bad newsi'd like to give you a full description here ... but i'd like to accompany it with at least a simple techdemounfortunatly my new job grants me much less time than i originally thought, leaving me with about half an hour free time a day ...

the deali'll give you a little feature overview and'll try to implement it over the weekend which actually shouldn't be that hard cause it is really simple ... ( an other thing i'll do is to search the web cause it is really that simple that i don't think nobody have done this before )

the namei like to call it "Ultimate Height Data" ...

features

can use both bezier ( "unlimited resolution data") and ordinary ( "heightmapping" ) mode ( maybe even in the same height data )

when using ordinary mode almost no overhead exists ( actually i have no proof for this right now ... but as ordinary mode uses very simple math this may be true )

provides full interpolation even in ordinary mode

provides normals that should be exacter and faster to create than NWA or NWE ( another guess ... but as it doesn't work on a x times per vertex level and is simple math again ... i might be right again )

Radeon 9000 and above have at least 6 TUs.Geforce 3 and above have at least 4 TUs.

Only when you fall below to Radeon 7500 (3 TU) and Geforce 2 (2 TU) do you see such low multitexture unit counts. Your decision concerning how many TUs to require certainly depends on your target audience, but I personally wouldn't lose any sleep over getting terrain to render in 2 TUs.

Here's an example of how we could do the LOD with the idea I posted before:(Assuming z is up)the vertices on the terrain are not fixed at their position in world coordinates, but their x,y coordinates are fixed relative to the camera's position and rotation along the z-Axis. So they might have distances like in the image I attached. Their z-coordinate is the height of the heightmap at that place.With that method, we won't be able to get holes, because vertices don't jump. We'll also probably be able to use much less vertices then elsewise.Only negative aspect: I don't know how much performance it will cost us to have dynamically changing coordinates.

But before it suits your needs, you're doing the funkiest math with lots of noise-layers. Been there, done that, still recovering from the headache.

Not sure if it was a reply to my post... but what I proposed was the opposite : to soften a perlin noise with a height field... which is much more interesting as it gives the designer the opportunity to define custom areas at some places, and pseudo-random areas at any other places...

About the "static moving LOD", that would work well in theory yes, just interpolating over a 2D heightfield, but now think how it will look: the terrain will "slide" over up-and-down-moving vertices. Nice idea, really, but it will look crap

...unless when you have like 10x10 samples per m2 in nearest LOD, XBox360 anyone?

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

howdy ... and sorry that i'm not present here for the last weeks ... but my new job takes almost all my free time ( i get up at 5 am and come back at 7 pm and fall asleep almost at once ) ...

but ... not everything is lost ... i have finished my work on the heightdata last weekend and am writing some sort of simple 'map editor' cause i use a binary format for the data, but it works with greyscale images too ( and gives some additional detail cause of the interpolation )

i'd like to show a screenshot ... but: a: cause i lack an editor just a 3x3 map exits andb: this is not my pc ... ( i'm depressed ... grr )c: whatever ... i'll attach a little snapshot

some notes on the snapshot:- the white points are ( as you may have guessed ) vertices ... indexed and random colored ... no normals or lighting so far ( normals exist ... but no lights )- another thing you see is that there are rectangle shaped 'things' ... these are my patches ( on the snapshot every patch has the highest resolution level )- as i said before this is 'just' a 3x3 grid ... (and it is a veeery regular grid but i'm lazy ... until the map editor is presentable )

again i'd like to apologize ... but i'm not a good team player ... so i'll publish details, code and formats when i believe it is presentable ... until than ... i'll post screenies and give a little progress overview:

i prefer the implementation that is used in the jme terrain systemthere you have a texture constructor which first takes a heightmapthan you register several textures and specify at which heights this texture is usedthen you tell the constructor to create the terrain texture and you get a new texture with smooth blended transitions

have a look at the jme system to see this in action ...not much time ... Florian

With an art team, you just have the art team create lots of meshes and textures and deal with artifacts by geometry copies or creating a solid out of the mesh (i believe jcanyon called the latter filets).

I did play with this type of terrain generator in a mud once. I found a cool one in java that did spherical translations and modified it for a mud world. I set the terrain according to a function of terrain height and latitude and it's closeness to water (low terrain height). It could have been improved with rivers, rapid terrain changes, and distance from water (river and ocean). There is a lot of research in this area...such as gscape. Perhaps the engine should be designed to work optimally with such external terrain generators and conventional means (documentation) rather than optimally with an internal terrain generator?

i find terrain generation to be a very non-core feature. Documentation, finding/fixing bugs, better loaders, shadows, shaders, culling, picking, animation, bones, joints, physics, sound integration, and other such features seem much more important. I'm still not sure on the HUD issue. AWT seems like it would result in better look (no floating point error) and ease (no splicing textures). Not sure on the texture memory vs. performance issue with HUDs. True orthographic with textures not stored in hardware is probably the best way to go on it. My knowledge is lacking here.

One thing I did see in Java 3D was spherical backgrounds. JME approaches this with a cube. How does Xith3D address it?

I did play with this type of terrain generator in a mud once. I found a cool one in java that did spherical translations and modified it for a mud world. I set the terrain according to a function of terrain height and latitude and it's closeness to water (low terrain height). It could have been improved with rivers, rapid terrain changes, and distance from water (river and ocean). There is a lot of research in this area...such as gscape. Perhaps the engine should be designed to work optimally with such external terrain generators and conventional means (documentation) rather than optimally with an internal terrain generator?

Yes. (I believe I posted a similar idea before ) We could create a simple interface for terrain generator (i believe there's already a very similar one in com.xith3d.loaders.terrain, so people using the old loader, won't be left behind, if we use that) that specifies function for getting the height at specific coordinates. Then it doesn't matter for the Terraingeometry creator, how the heightmap was generated. So we could simply plug loads of different generation types in.

Quote

i find terrain generation to be a very non-core feature. Documentation, finding/fixing bugs, better loaders, shadows, shaders, culling, picking, animation, bones, joints, physics, sound integration, and other such features seem much more important. I'm still not sure on the HUD issue. AWT seems like it would result in better look (no floating point error) and ease (no splicing textures). Not sure on the texture memory vs. performance issue with HUDs. True orthographic with textures not stored in hardware is probably the best way to go on it. My knowledge is lacking here.

- yeah, maybe terrainloading should be moved out, too (like all the other loaders). - I wrote some code for picking (it also works!), but I would have to put some effort into it, to make it a useable tool. As it seems many people are asking questions about picking - maybe it should be added ?- for physics most use odejava, so I don't see any reason here to implement it in xith, like JMe did. - huds are an issue already, we discuss - in the moment somebody (I believe Bluesky) has volunteered to implement another hud system.- bones ofcourse would be cool - I once tried to write some code that did that, but it didn't work. If such is implemented, we would also think of how it should work with the scenegraph.

If you have good ideas of how to improve things, simply create a new thread and post them there.

on the 'non-core' topic: a: the terrain package ( and some others ) were moved to the toolkitb: i'm ( and i guess arne isnt either ) by no means a core developer just some guy who came along and thought i'd contribute something to xith ...

as of the progress:i externalized the loading to modules .... at the moment there is a 'load from image', a 'load from binary file' and a loader that loads a plane terrain that can be modified afterwards ... the modules implement an interface ... so everybody can implement an own loader

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org