View previous topic :: View next topic |
Author |
Message |
anarky
Joined: 03 Jul 2010 Posts: 35
|
Posted: Mon Jul 19, 2010 3:15 am Post subject: Yage terrain engine |
|
|
Here we go,
everything related to the yage terrain engine come here A brief sum up of things to consider:
- terrain generation: heightmap of some sort. What about the procedural stuff from Infinity? How do they generate their terrain?
- terrain texturing: Ok I read the comments about Earth Sculptor. I had a look at this soft's webpage and I don't really see how it can generate the first texture (the one referencing the others). It is Windows anyway. I think I will do this look up texture myself referencing 4 other monochrome textures for the moment (say 4 kind of brown)
- lighting: natural lighting from the sun well if I actually pipe everything to the renderer as you said Joecoder it will work great for planets no? Of course we can include a possibility to have light-map too as commented in the code.
- LOD: geomipmapping.
JoeCoder can you give some details about the 4 points above? |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
anarky
Joined: 03 Jul 2010 Posts: 35
|
Posted: Mon Jul 19, 2010 9:22 am Post subject: |
|
|
Ok got it,
something like that:
Code: | if (terrainNode)
{
//Log.info("found terrain");
//result += geometry(terrainLol.getGeometry(), lights, n.materialOverrides);
result += geometry(terrainNode.getVisibleGeometry(camera), lights, n.materialOverrides);
} |
We add camera as an argument to send only the vertices of terrain node worth rendering. In fact only the patches of terrain worth rendering if we use geomipmap with patches.Not that easy from here ![Mad](images/smiles/icon_mad.gif) |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
JoeCoder
Joined: 29 Oct 2005 Posts: 294
|
Posted: Mon Jul 19, 2010 6:36 pm Post subject: |
|
|
About yage.scene.terrain: This is the best interface I could come up with, but it can change if you have better ideas for it. Brandon was going to work on this, but we can replace his name in the copyright and author tags with you. Anyway, this is how it can work:
The terrain system has two layers. The TerrainGenerator interface is used to give raw geometry data to TerrainNode. HeightMapGenerator is one implementation of this that gets its data from a Heightmap image. A different implementation could generate 3d worlds procedurally like Infinity.
TerrainNode uses a TerrainGenerator to build geometry and create the different geomipmap chunks, complete with triangles, texture coordinates, and normals. Render will call getVisibleGeometry to get an array of these chunks that are inside the CameraNode's view frustum.
Vertex color values can be used to interpolate between up to four different textures. Multiple passes can be used if the terrain uses more than four textures. This can be done even on old hardware without shaders. EarthSculptor is one program that can create terrain texture data in this format, but it's not a requirement to support it, especially if you know a better one.
Using Image instead of Image2 is fine for now. I would eventually like to replace SDL_Image with libavcodec in Image2, but that hasn't been started yet.
The code you pasted is correct (you're good at figuring out code). I plan to add a function to CameraNode that will take a point and a radius and tell if that "sphere" is inside the camera's view frustum. Would that make it easier for you? |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
anarky
Joined: 03 Jul 2010 Posts: 35
|
Posted: Tue Jul 20, 2010 7:09 am Post subject: |
|
|
I think that the interface is quite good.
The problem with Earth Sculptor for me is its windows dependency I don't have Windows. But this is details, I will find out something for the textures.
A fustrum culling function would be appreciated if you have planned one. There is a plethora of those on Lighthouse. I don't know if it should be a bounding sphere or a box, I don't think that it is really important, so a sphere is maybe easier. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
JoeCoder
Joined: 29 Oct 2005 Posts: 294
|
Posted: Tue Jul 20, 2010 9:20 am Post subject: |
|
|
CameraNode already has frustum culling using spheres. I just need to break it apart so this simple case can be called by itself. Box culling can be added as a second test after sphere culling if it can make things faster, but for now, sphere culling gets us most of the way there.
There's no shame in not using Windows. I think that's a good thing. I only use it because I need it for my work. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
anarky
Joined: 03 Jul 2010 Posts: 35
|
Posted: Fri Jul 30, 2010 6:13 am Post subject: |
|
|
about Negative coordinates values
The interface describes:
Code: | this(TerrainGenerator generator, TextureInstance[] textures, Vec2f min=Vec2f(-128), Vec2f max=Vec2f(127), Vec2f resolution=Vec2f(256)) |
I am not sure of the use of min and max values. I feel that it would be easier to define only the grid resolution at this point. For example:
Code: | this(TerrainGenerator generator, TextureInstance[] textures, Vec2f resolution=Vec2f(256)) |
A problem of course comes if we start the vertices array at 0 and finishes at 256 because the terrain would not be "centered", but it is easy to fix in getTerrainPoint() for only the vertices array.
This way it is cleaner to calculate the heightmap mapping and the texture mapping without worrying about negative values. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
JoeCoder
Joined: 29 Oct 2005 Posts: 294
|
Posted: Mon Aug 09, 2010 9:42 pm Post subject: |
|
|
Go ahead and implement it this way (without the min and the max).
I'm trying to think of any situation when you would actually need the min and the max, but I'm not sure of any.
Thanks for thinking this through. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
anarky
Joined: 03 Jul 2010 Posts: 35
|
Posted: Tue Aug 17, 2010 8:21 am Post subject: |
|
|
Hi,
I have some working terrain code (without mipmap). It computes the terrain once at start and store the TerrainPoints in an array. I don't know if it mixes well with the mipmap approach, which sounds more "on-the-fly". I will starts this week with mipmap and see how it goes.
I still have this lack of access to svn, so I have my environment with a backup on network disk. One day I will update the svn I promise The code is mostly independent anyway.
/+ Anarky +/ |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
JoeCoder
Joined: 29 Oct 2005 Posts: 294
|
Posted: Tue Aug 17, 2010 8:48 am Post subject: |
|
|
That's great.
If you want, just mail me a zip and I can merge it myself. It might be a little while before I can get to it (work and stuff), but then I can look at what you have and make sure you're not doing anything the hard way. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
anarky
Joined: 03 Jul 2010 Posts: 35
|
Posted: Fri Aug 27, 2010 7:13 am Post subject: |
|
|
Quote: | it might be a little while before I can get to it (work and stuff) |
BTW it is also my case, this is why you should not worry if you don't see me for a couple of months sometimes in the future.
I forget to say that the terrain class accepts only one texture too, so nothing I am proud of. I will bother with the SVN transfer when I have something more solid
I considered some LOD algorithms and I have been doing a lot of theorical thinking. My first conclusion is that mipmapping or another LOD is not that important, compared to culling. And culling in turn implies a certain way to divide the terrain, so it is best to do culling first. For example if I chose to cull with a regular "patch" grid, it sounds better to then reuse the patches for LOD with mipmapping instead of for example quadtree culling + LOD with quadtree.
So I gonna write the radar culling algorithm for sphere and work from that. I gonna probably take a regular patch grid with 16*16 patches to start, and make something simple work.
/+Anarky+/ |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
JoeCoder
Joined: 29 Oct 2005 Posts: 294
|
Posted: Fri Aug 27, 2010 8:40 am Post subject: |
|
|
Sounds good to me. All of the code for telling if something is inside the camera's view frustum is in scene.camera. It would be good to have a simpler checkVisible function that could accept a point and a radius (I think this is better than what I have there now), and then the terrain could use that. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
|