Thank you for your quick reply, I'll read the paper :)

I think the data missing in the repository is:
- Default_HeigthMap.png and Default_TexMap.png used by
testQuadTreeTerrain.cpp
- worldground.jpg used by openglslave.cpp
- gras.jpg, stone.jpg, tree1.3ds, triplane.3ds and dinopet.3ds used
by testShadowST.cpp
- WorldMap.png, HeightMap_0_0.png and others used
by testTiledQuadTreeTerrain.cpp
- grace_cross.chdr used by testHDRStage.cpp

Thank you,
    Christian


----------------------------------------------------------------------------------------------------------
       Hello Christian,

On 11/03/2011 11:19 AM, Christian Bar wrote:
> I was wondering:
> - how the QuadTreeTerrain uses the input image as a heigthmap, what
> types of images can be used as heigthmaps, and how the image data is
> interpreted (greyscale images, 8 or 16 bit per channel),

it should support single channel 8/16/32 bit integer and 16/32 bit float
textures (those are the cases handled in
QuadTreeTerrain::getHeightDataScaled()).

> - if the input image has some limitations in size (2^n+1, 2^n+1 ?),

yes, the image must be square and power of 2 + 1.

> - what the VertexSpacing means (horizontal resolution?),

If I read it correctly, it is the distance between vertices that belong
to adjacent pixels in the heightmap. So given a map of size 257 and
VertexSpacing == 2.0 the terrain geometry will be a square with edge
length 512 units (256 segments of length 2.0).

> - what GeoMorphing means and how it works,

I think this is explained in the paper the code is based on:
"Real-time generation of continuous levels if detail for height fields",
by S.Roettger, W.Heidrich
(<http://www.cs.ubc.ca/~heidrich/Papers/WSCG.98.pdf>)

> - how the Detail has to be set to get a decent result.

to a high value.

> We tried a PNG 8-bit RGB image and the resulting image had the same
> heigth both for pure Red, Green or Blue, and this behaviour was a bit
> misleading to us (it seems that the input image is converted in some way
> to extrapolate the luminance value)

hmm, I'm not sure it deals well with multi channel images. Have you
tried a single channel format? (The example data set uses a single
channel PNG).

> If we use a 8-bit grayscale image we are limited to a 256-level
> heithmap, so the question is: how can we bypass this limitation? If we
> use a floating point image is the heigtmap correctly handled?

it should, see above.

> I did not found in the git repositiory the test images used in
> the testQuadTreeTerrain program (Default_HeigthMap.png and
> Default_TexMap.png), can someone tell me where can I find these files
> (along with the test data of the other test programs)???

ah, sorry, the files for the terrain test simply did not make the move
from the 1.x repository, I'll add them later today.
What other test programs are you referring to?

       Cheers,
               Carsten
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to