Awesome work

Xavi
Here: PlanetEngine Wireframe Video (5.5 MB)can you post a video in wireframe mode?
I probably will, although probably not for some time. It's really in the a very early stage - there's a lot to improve.Maybe you're interested in releasing the source for this?
Yes, they're called "skirts" (by the author of the Chunked LOD technique, at least). It's a crack filling technique, and is much easier than decimating the side of a mesh to match up with lower detail chunks like HexiDave's system. It works so well and is so easy, I almost felt like I was cheatingThe seams look a little odd, like there is a ridge running under the terrain. Is that intentional?
Ya, that's true enough - the main reason I did the decimation at the edges was because it felt like cheating (OgrePlanet was to be only a learning exercise), but I left it in because it satisfied some things I wanted to care for later on.JohnJ wrote:Yes, they're called "skirts" (by the author of the Chunked LOD technique, at least). It's a crack filling technique, and is much easier than decimating the side of a mesh to match up with lower detail chunks like HexiDave's system. It works so well and is so easy, I almost felt like I was cheatingThe seams look a little odd, like there is a ridge running under the terrain. Is that intentional?. The only possible drawback is that it can cause a small area of texture stretching near where cracks would be, although as described in the paper the screen-space pixel error LOD system makes it virtually impossible to spot (which seems to be true even with very high-res textures, from what I tested).
I disliked the skirt methods. If you are keeping LOD levels within one level as it seems a lot of the implementations I have run across do/suggest, I prefer changing the patch layout and just skipping vertices instead. Makes it as simple as keeping around a static index buffer with each of the 16 possible layouts at differing LOD directions.JohnJ wrote:Yes, they're called "skirts" (by the author of the Chunked LOD technique, at least). It's a crack filling technique, and is much easier than decimating the side of a mesh to match up with lower detail chunks like HexiDave's system. It works so well and is so easy, I almost felt like I was cheatingThe seams look a little odd, like there is a ridge running under the terrain. Is that intentional?. The only possible drawback is that it can cause a small area of texture stretching near where cracks would be, although as described in the paper the screen-space pixel error LOD system makes it virtually impossible to spot (which seems to be true even with very high-res textures, from what I tested).
Code: Select all
// Patch Structure #1
// *--*--*--*--*
// |\ |\ |\ |\ |
// | \| \| \| \|
// *--*--*--*--*
// |\ |\ |\ |\ |
// | \| \| \| \|
// *--*--*--*--*
//
// Patch Structure #2
// *--*--*--*--*
// |\ | /|\ | /|
// | \|/ | \|/ |
// *--*--*--*--*
// | /|\ | /|\ |
// |/ | \|/ | \|
// *--*--*--*--*
Yes, but my current "ChunkLoader" implementation is a placeholder at best. I'm still thinking about heightmap data loading/generation methods. I'd like to combine a procedural technique with a medium-res heightmap, but I don't know how well dynamic procedural generation is going to work with my plans for dynamic lighting with normal maps and ambient occlusion maps.Are you currently limiting to your heightmap data source resolution when it comes to the amount of terrain detail shown?
I'm not sure yet, but my requirements are that an entire planet doesn't take too much memory (<10MB maybe) since I want lots of them, and obviously I don't want to sacrifice too much visual quality or performance. I haven't done much research here yet, but any info I can get will help.What are your plans for texturing?
If I used the GeoMipMapping technique, I would definitely have used 16 static index buffers, but with Chunked LOD it's just not possible. Chunked LOD, unlike GeoMipMapping, does not have a constant batch size - at a distance the planet can be rendered with only 3 batches (with horizon culling), when close up the subdivision process increases that to about a hundred. This means that a very large "chunk" can be neighbor to many assorted sizes of chunks, and as you can see in screenshots from HexiDave's implementation, indexing these in real-time wouldn't be trivial.I disliked the skirt methods. If you are keeping LOD levels within one level as it seems a lot of the implementations I have run across suggest, I prefer changing the patch layout and just skipping vertices instead. Makes it as simple as keeping around a static index buffer with each of the 16 possible layouts at differing LOD directions.
Yeah, it's fun experimenting with techniques. The heightmap/texture generation / loading system will probably be the next technical hurdle, but I'm sure I'll solve it with enough research and experimentation.Would be interesting to learn more about your implementation. Always enjoy just kicking around intriguing possibilities and techniques.
ARTIFEX TERRA 3D - Artist-friendly, free and easy WYSIWYG realtime outdoor scene Editor & Painter
New loader now with Ogre::Terrain support: Addons for Artifex on SourceForge
MOC - Minimal Ogre Collision & Mousepicking
Simple TerrainMaterialGenerator for the use of standard Ogre material with Ogre::Terrain
Support me on Patreon
Yeah, definitely, although I'll probably improve the graphics before I do that video (I'm currently researching procedural generation of terrains which I can use to expand a 512x512 height/property map to 4096x4096 or 8192x8192 in real-time. The engine runs at almost the same speed no matter how large planets are, so it would be a waste to only use it for tiny planetsOK, I have a video request that should really show some cool stuff off, maybe it's something for in the future, but!
Start on the ground, "take off", go into orbit, outer space, then make a reentry finally coming to rest at near ground level.
I think that would make an awesome video showcase.
Yeah, Planet is derived from MovableObject, which means you attach it to a SceneNode just like an Entity, so you can create as many as you want, and rotate/position/etc. as you like.Does this allow you to have more than one planet?
so, when is the game gonna be done?JohnJ wrote:Yeah, planet engines open a lot of opportunities in game design. Don't expect anything soon though, since the engine has a way to go until completed. Also, this is actually going into a game project that may be sold, so we probably won't open-source it until the game is done.
Me tooLord Alexion wrote:Seems like I'm not the only one with the idea of making the next ELITE-like space sim huh?
Like I say, perhaps you might be better to join forces with an existing project (there's a few good open source ones: SFZ, Vega Strike) so you can concentrate on your universe generation ideas.Lord Alexion wrote:But unfortunately I ave a long way to go to understand this kind of low-level rendering code...
I'm sure this engine would be a great combination, and I'll be glad to open-source it when the time comesPerhaps you would like to look at the possibility to merge your techniques / rending with their gameplay engine. If it's at all feasible, it would be an incredibly powerful combination.