Page 1 of 3

Normalising terrain height values

Posted: Tue Feb 25, 2014 1:20 pm
by FluffyFreak
Ok I'm asking on here out of sheer frustration and because I have to get back to the day job.

When we get a height value from the terrain generator it's in some vanishingly small range between 0 and 0.0042 (For Earth) (or something tinier depending on planet).

I want to normalise that value back into a 0 to 1 range.
I have some information about the planet held in m_terrain, of which only two variables:
m_planetRadius 6378135.0000000000
m_planetEarthRadii 0.99999999999999989

Only these have any independence, as the rest are calculated/generated from the process that I'm trying to normalise the values from.

I'm testing with Earth itself by the way hence m_planetEarthRadii being so very nearly 1.

Anyone got any bright ideas? I've no idea how or why they're such small values or how they relate to feature size etc.

Andy

Re: Normalising terrain height values

Posted: Tue Feb 25, 2014 8:16 pm
by FluffyFreak
I'm starting to think that maybe it's going to be something to do with the maximum height being limited by the gravity, or something.

For now just multiplying by 200 will suffice :) HAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACK!

Re: Normalising terrain height values

Posted: Tue Feb 25, 2014 9:17 pm
by lwho
I remember from some discussions in GitHub issues that it was agreed that terrain generation probably needs quite a thorough rewrite. But nobody really seemed to understand what was going on in this code (count me one them ;)).

Re: Normalising terrain height values

Posted: Tue Feb 25, 2014 10:03 pm
by FluffyFreak
Yeah it's a pain, one of the many things that I'm trying to fix.
Currently I'm trying to implement terrain texturing like this article http://www.gamedev.net/blog/73/entry-16 ... explained/.
I've gotten some stuff working but this is just one of the stumbling blocks.

Re: Normalising terrain height values

Posted: Tue Feb 25, 2014 10:22 pm
by FluffyFreak
Oh and part of the reason for doing it in parts is because I've tried doing it all in one big go... that way lies madness :)
This way I can do it in bits and pieces and we see imcremental results... without the madness... mostly.

EDIT: The (very early) WIP branch is: https://github.com/fluffyfreak/pioneer/ ... st_texture in case anyone wants to try it out.
There's only a single pre-made texture, it's got bad mipmapping and is generally incomplete, as is the LUT but they're both for testing, also it doesn't repeat the textures depending on the LOD depth yet so the texture is always mapped 1:1 to the quad tree patch which is something else I need to add.

In the final version the Atlas will need to be built for each planet from a selection of colourised source textures, not all worlds will have grass/moss, not all world will have beaches etc.
Also this one doesn't have anything for water yet.
Likewise for the LUT, we might need a selection of them for different rocky world types etc.

... basically it's totally experimental :)

Re: Normalising terrain height values

Posted: Wed Feb 26, 2014 1:18 am
by Luomu
FluffyFreak wrote: //create buffer and upload data
Graphics::VertexBufferDesc vbd;
vbd.attrib[0].semantic = Graphics::ATTRIB_POSITION;
vbd.attrib[0].format = Graphics::ATTRIB_FORMAT_FLOAT3;
vbd.attrib[1].semantic = Graphics::ATTRIB_NORMAL;
vbd.attrib[1].format = Graphics::ATTRIB_FORMAT_FLOAT3;
vbd.attrib[2].semantic = Graphics::ATTRIB_UV0;
vbd.attrib[2].format = Graphics::ATTRIB_FORMAT_FLOAT2;
vbd.attrib[3].semantic = Graphics::ATTRIB_UV0;
vbd.attrib[3].format = Graphics::ATTRIB_FORMAT_FLOAT2;
This can't work, to enable a second texture channel you need to
- add a new semantic UV1
- in renderer, when setting up the vertex pointers for each channel (because we're using the old fashioned glXpointer style):

Code: Select all

glClientActiveTexture(GL_TEXTURE0 + uvIndex);
glTexCoordPointer(...);
Then it should be accessible as gl_MultiTexCoord1 in the shader. Don't forget to restore clientActiveTexture to GL_TEXTURE0 after drawing.

Re: Normalising terrain height values

Posted: Wed Feb 26, 2014 9:35 am
by FluffyFreak
Hmm, well, I gave that a quick go - adding and hooking up the ATTRIB_UV1 and calling glClientActiveTexture before each glTexCoordPointer for vertex buffers - but now all I get is a dun coloured landscape.

Still that might actually be progress :) it's hard to tell with these kinds of issues!
Yay for graphics coding! Yesterday I spent two hours tracking down a typo :/ (http://threepanelsoul.com/2013/04/15/on-infinite-loops/)

I'll try to take another look at lunchtime, probably start by creating a couple of test textures rather than the final-implementation style ones that I've been using so far, 4x4 grid is 16 which could be solid blocks of colour... i'm thinking of a landscape that looks like a Windows 98 safe-mode now :D

Re: Normalising terrain height values

Posted: Wed Feb 26, 2014 9:17 pm
by FluffyFreak
Bit stumped, it's like the UV coordinates or the slope+height values are being ignored. I dunno, brain is just not working tonight.

Re: Normalising terrain height values

Posted: Thu Feb 27, 2014 8:27 am
by FluffyFreak
Ah ha! Starting to get there now!

Image

Image

Looks like my height and slope calculations were wrong for a start, also the indexing LUT texture will need to be customised / rebuilt.

Ah but sweeet sweet progress! :)

Re: Normalising terrain height values

Posted: Thu Feb 27, 2014 9:16 am
by robn
Merge it! Ship it! ;)