next »

[Marvin Fröhlich]

Hey, Mathias (cylab)

Thank you very much for the new Terrain implementation. It works just great .

What would you think about further abstraction? Then it would be imaginable to load the Terrain by simply doing

Code:

Terrain terrain = new Terrain( myTerrainURL );

The Terrain instance would then provide a method render(View) or update(View) or render/update(Tuple3f), which is called before the next frame and could even be managed automagically by a ScheduledOperation.

The Terrain class then provides a method called getHeightMap() to retrieve the height map.

Wouldn't this be much simpler than implementing the TerrainRenderInterface? I don't know, if it can be abstracted at this level or if it isn't that common. I don't know if one would loose possibilities, if it was abstracted that way.

But if it is, there could be a method setTerrainShape(Group) or so, which would replace the default Terrain shape.

What do you think?

Marvin

[Mathias 'cylab' Henze]

Hey Marvin

Thank you very much for the new Terrain implementation. It works just great .

Tanks, but that's not my credit. It's not a new implementation, I just made a new test case of the original terrain code to help me debugging. Unforunately it works not as great as I hoped. There are cracks in the landscape and there is some strange behaviour when the height settings are changed.

What would you think about further abstraction? Then it would be imaginable to load the Terrain by simply doing

Code:

Terrain terrain = new Terrain( myTerrainURL );

The Terrain instance would then provide a method render(View) or update(View) or render/update(Tuple3f), which is called before the next frame and could even be managed automagically by a ScheduledOperation.

That's the goal. The terrain should be as simple as possible to handle. I see your proposed Terrain class as an additional utility class to hide the underlying complexity.

The Terrain class then provides a method called getHeightMap() to retrieve the height map.

Wouldn't this be much simpler than implementing the TerrainRenderInterface? I don't know, if it can be abstracted at this level or if it isn't that common. I don't know if one would loose possibilities, if it was abstracted that way.

I am not exactly sure which role the TerrainRenderInterface plays in the CLOD algorithm. I have to investigate further to answer that question. On the other hand I like for example the TerrainSampleInterface as an abstraction where to get the height data, so you can use procedural height map generation as well as reading a map.

I think we can archive both, flexibility and simplicity of the terrain implementation, if we follow the interface path like it is now for the base implementation (as far as it is sensible) and provide a higher level AbstractTerrain utility class that could be easily extended to fully utilizy the terrain features.

Ideally there should be a provided HeightMapTerrain implementation which follows your suggestion:

Code:

HeightMapTerrain terrain = new HeightMapTerrain( myTerrainURL );

to make things as simple as possible for the user.

On the sad side of things, I don't think this get's finished for the next release, so don't advertise with this feature to much:/

Thanks for the suggestions!
Marvin

[Marvin Fröhlich]

On the sad side of things, I don't think this get's finished for the next release, so don't advertise with this feature to much:/

That's no problem. I will exclude the new Terrain Test from the 0.9.0 branch then.

If you need to break the API to completely replace the current Terrain implementation, then I think it won't be a problem, since the current one doesn't seem to be very good. If anyone had a problem with breaking the Terrain API, please shout here.

Will the new Terrain support Bezier plains? And will it support partitioning managed by a QuadTree?

Marvin

[Mathias 'cylab' Henze]

That's no problem. I will exclude the new Terrain Test from the 0.9.0 branch then.

Thanks

If you need to break the API to completely replace the current Terrain implementation, then I think it won't be a problem, since the current one doesn't seem to be very good. If anyone had a problem with breaking the Terrain API, please shout here.

The Terrain by David Yazel is not too bad, but a little bit difficult to understand. I think I will need to change the API a bit, but as you said that won't be a problem as noone really uses it (I think).

Will the new Terrain support Bezier plains? And will it support partitioning managed by a QuadTree?

I am not sure about the Bezier planes, since I have little to no knowledge regarding bezier planes, curved surfaces and nurbs. But I think it could be incorporated with a little help from someone capable in that area. The new Terrain will definitely have to support some kind of partinioning, since it has to support Texture LOD and continuous terrain swapping using disk io. Time will tell if this will be quadtree, octree or just a flat array of chunks.

[Marvin Fröhlich]

I am not sure about the Bezier planes, since I have little to no knowledge regarding bezier planes, curved surfaces and nurbs. But I think it could be incorporated with a little help from someone capable in that area.

Well, if you are at this point, you can ask me. I have been through a course at the uni, that was about Bezier curves/planes/-patches. I will have to look through it again, but in priciple, I think, I will be able to help you with it.

The new Terrain will definitely have to support some kind of partinioning, since it has to support Texture LOD and continuous terrain swapping using disk io. Time will tell if this will be quadtree, octree or just a flat array of chunks.

Well, an OcTree is definitely overkill for this, I think, since the Terrain is only 2-dimensional (with height map). Do you agree?

Marvin

[Mathias 'cylab' Henze]

(...)bezier planes(...)

Well, if you are at this point, you can ask me. I have been through a course at the uni, that was about Bezier curves/planes/-patches. I will have to look through it again, but in priciple, I think, I will be able to help you with it.

That was, what I had in mind

Well, an OcTree is definitely overkill for this, I think, since the Terrain is only 2-dimensional (with height map). Do you agree?

Kind of. It depends on the data you try to visualize. If you want to make e.g. an action game in the rocky mountains, an octree might give a performance boost for frustum culling, since you could sort out a lot of patches "above" the player character, but in 90% of the games a quadtree would be good enough.

[Marvin Fröhlich]

Kind of. It depends on the data you try to visualize. If you want to make e.g. an action game in the rocky mountains, an octree might give a performance boost for frustum culling, since you could sort out a lot of patches "above" the player character, but in 90% of the games a quadtree would be good enough.

Agreed. I thought, a Terrain would only be used as 2D+HeightMap. So an OcTree was just the wrong structure. But if you explain it that way...

Marvin