Terrain Rendering

[arne]

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.

Arne

[c_lilian]

@Riven

If you want to soften the heightfields at certain locations, just blend it with another layer of very-very-low-frequency perlinnoise:

float hiFreqNoise = hiNoise.get(x, y);
float loFreqNoise = loNoise.get(x, y);

float noise = hiFreqNoise * lowFreqNoise;

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…

Lilian

[Grand_Poeba]

i found something about 3d render/terrrain gscape
maybe some of u know it and may know if we can use this?

[Riven]

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 m² in nearest LOD, XBox360 anyone?

[Goliat]

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
and
b: 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:

Progress:

• Heightmap Data: 90% - works fine … just there is no mapeditor …
• Terrain Loading: 100% - actually i don’t know why other implementations take hours to load the terrain …
• Terrain Tessellation: 100% - no problems here
• Terrain CLOD: 30% - detail levels are loaded correctly but there is no screen space error setting of detail levels and gaps arent solved yet
• Shader Implementation: 0% - but i just got my new card yay!

ok … [insert more apologies for beeing a egoist here] … this’ll be a loooong weekend …

Ok … for everybody searching the snapshot … there is none cause this fscking 56k modem sucks … bah …

[Goliat]

test … i’ll try it this way … but i cant grant that it has ‘good’ quality … and i believe you can’t see the ‘white points’ … bah … 56k … and windows … bah …

[arne]

Looks nice :), nice resoulution for only a 3*3 !! You’re doing that trick with the bezier curves right?

Progress:

* Heightmap Data: 90% - works fine ... just there is no mapeditor ...
* Terrain Loading: 100% - actually i don't know why other implementations take hours to load the terrain ...

maybe because their terrain’s a lot bigger? And maybe, because they have several Texture-Layers?[quote]
* Terrain Tessellation: 100% - no problems here
* Terrain CLOD: 30% - detail levels are loaded correctly but there is no screen space error setting of detail levels and gaps arent solved yet
[/quote]
I posted an idea about dealing with LOD’s, that wouldn’t be able to create gaps. But if you think it will look crap, if implemented … :’(

[jeep]

@Goliat

actually i don’t think this is a good idea …

i prefer the implementation that is used in the jme terrain system
there you have a texture constructor which first takes a heightmap
than you register several textures and specify at which heights this texture is used
then 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?

[arne]

@jeep

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.

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.

Arne

[Goliat]

how? aren’t we getting a bit offtopic here?

on the ‘non-core’ topic:
a: the terrain package ( and some others ) were moved to the toolkit
b: 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

whatever … i’m making progress here
Florian

[arne]

@Goliat

how? aren’t we getting a bit offtopic here?

yup[quote]
on the ‘non-core’ topic:
a: the terrain package ( and some others ) were moved to the toolkit
[/quote]
ahh that’s reasonable - it moved then with the other loaders. I already wondered.[quote]
b: 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 …
[/quote]
actually nobody here is a core developer, most code the stuff, what they need for their game, and contribute that. Will might be the only exception (because he’s the project owner - but don’t expect him to do all that stuff - he also got loads to do!) + About myself - I haven’t actually got a developer status yet - mmh I really should have one for the xith-tk, when Goliat has finished his code, so we can use the cvs[quote]
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
[/quote]
Nice
I am dying to test it.

Arne

[Goliat]

just another progress report:

the heightmap editor is more or less functional ( not a beauty … but it works ) to be honest the interface is very clumsy but you can create, modify and view bezier heightmaps with much less hazzle than to do it by hand
i’d like to post another screeny … but this time i really got no one here …
there are some few things left to iron out ( like some little scaling problems ) but it hope by the end of the week i’m able to give you a little ‘demo’ version to play around with

next things on my shedule:

• get some sleep
• work …
• get some more sleep
• try to find a new apartment
• etc …

no serious:
now that i have a working heightmap editor i’ll concentrate on the terrain itself again and there a lot things have to be done …

Florian, the forever restless …

[arne]

So, how has been progress?

Maybe you’ll simply add that what you’ve done to the xith-tk and let the community do the rest, if you haven’t got enough time for it.

Arne

[Goliat]

hmm… now that i see i’ve got much too less time i’d just do that … but my pc’s at my girlfriends home with (almost) no internet

progress:
have a nice terrain with 5 resolution levels per patch, with multiple texture layers ( currently just two types: baselayer and additional texture layer )

now i have to find a way to set the right resolution per patch … i would like to use some kind of screen error check ( meaning there is a error in the ‘up’ direction which is projected on the screen where it is compared to a given max error )
i have the error per patch … but i have no idea how to do the projection part … any hints?

[Goliat]

just as i promised ( to arne ) and without a lot of words
my terrain code for everyone to play around

just one node: this is not the final thing … i just havn’t got that much time at the moment so i’ll give you the current code
i’ll do some more writing tomorrow … and’ll go to bed now

[edit] should attach the code right? - just remove the .jpg at the end of the filename [/edit]

[cylab]

To answer you question for the error-projection:

In my terrain, I determine the height-error of every detail-level in respect to the most detailed one by calculating ray plane intersections from each vertex in the latter to the triangles of the less detailed patch. In the rendering, I set up a vector like [0,0,] for every detail level patch (starting with the less detailed one) and multiplicate this vector with the current ModelView Matrix. The first detail level patch is choosen for rendering, for which the length (or squaredLength for performance reason) of this vector is less than the maximum allowed error.

[arne]

hmm… I get an error with (TerPath.java L.17)

import org.xith3d.geometry.Patch;

[Goliat]

oh … jup … just another class i forgot to upload

[arne]

ok I haven’t still tested your code - hrrg - I really should do this

a nice topic about this, I found here at the forum (for everybody who missed):

http://www.java-gaming.org/forums/index.php?topic=12102.0

EDIT: woot, woot I finally managed to have some time to test it (I had to write an test-case is that correct, or did I simply miss something?) And then it wasn’t able to find all the resources (images and .gsgl files)

[Goliat]

arg … slap me, hit me, beat me … whatever … i’m depending on to many external files … i guess i’ll include the gsgl stuff ‘inline’ ( which was in my mind before as i like to use a dynamic number of texture states )

what else is missing? i guess you xith build doesn’t handle Branch-/TransformGroups which implement NodeUpdater … there was another topic started by me some time ago … but i don’t think anything got changed in the xith core

[person related babbeling: i’m currently offline … just around 20 days to go … am at seminar for this week and have inet here … but that doesn’t help me … right? ]

Greetz Florian