Simple Paged Terrain [v2.00 Released! Page 21]

[denreaper]

When we delete SPT::Terrain then create a new one, it crashes (consistently on the new one's creation for someone else) and randomly between 2-5 delete/creates for me. Both of us are using Linux (One Ubuntu and one Debian). Is it possible that there is something going on in the SPT2 code that could cause this?

P.S. I'm willing to help test the editor on Ubuntu 8.04 LTS.

[HexiDave]

Huh, I thought I had this fixed. Are you using the most up-to-date SVN copy? Can you show me how you have SPT setup and how you're destroying it? Check the demo's createSPT and destroySPT functions.

Thanks for offering to help with testing - I'll be in touch.



As an aside, I was able to upload an HD version of what I was testing yesterday, so lemme know if this video works for you folks:
http://www.vimeo.com/1342651

[xadhoom]

Your video looks really good! Nice performance.

From good old Bryce I know a feature to blend materials depending on the height.
Maybe this would be a nice optional feature for fast development...
(if it isn´t already implemented)

Keep up this good work!

[HexiDave]

Your video looks really good! Nice performance.

From good old Bryce I know a feature to blend materials depending on the height.
Maybe this would be a nice optional feature for fast development...
(if it isn´t already implemented)

Keep up this good work!

I have a few splatting methods for slope and/or height as well as some pre-computational splat-map builders based on the same factors and a bit more (like strength, to fight any other channels for that spot).

Pretty much right now it's all focused on actually editing stuff, but by the end of the week it'll be time to make stuff prettier and do some cleanup and documentation. I've been wanting to really flesh out the shader/material setup, but it's time consuming as hell because there are so many possibilities.

Edit: Also, I don't say this enough, but thanks for your support, folks!

[Trancient]

Wow, great work, thanks very much for making this available.
I'm really looking forward to seeing how this progresses.

I have a performance related question: If I wanted to run SPT maximising performance against Graphical quality & Features, would what would be the most FPS saving features to disable / reduce, ie:
- LOD Morphing
- Dynamic Lighting
- Splatting
- Atmospheric scattering
- ...anything else... ??

and is it possible to manage these features to that effect?

( My game concept is primarily focused on the simulation aspect, so I like to baseline the graphics to see how much processing I have left to spend for lower level machines, and then of course have options to enable all the nice effects for the high end machines. )

Also, a small observation with the LOD morphing, is it possible to have an option to speed this up at all, when traversing a lower res terrain, it can be quite noticeable, maybe even have the speed related to the camera distance... just a thought.

If I'm jumping the gun, no probs ( maybe this info will be in the docs ).

[HexiDave]

Well, right now, the most expensive thing is the "medium" shader as it does tri-planar texturing for each splat, so it's incredibly costly. I think the next most expensive thing is the terrain geometry. Currently, I'm not focusing as much on geometry LOD as I am whole-terrain LOD; basically, I'm handling the quad-tree such that you don't have as much geometry on-screen as you would normally for such a large terrain, but I don't have half a dozen levels of detail for each chunk. This means more geometry on screen at one time, but it looks a lot better. I opted to go this route (although, it will be tunable soon) because most cards can gargle this amount of polygons per frame and spit them right out before getting to the main course.

The current Atomspheric Scattering model there is actually pre-computed into a skybox texture (cube-map) and there's almost no math involved in the shader. Believe it or not, there's no dynamic lighting going on there either! That's a light-map that gets computed on the GPU (will have a CPU equivalent soon for non-SM 3 capable cards) that stores the normals in the remaining 3 channels (this is for either dynamic lighting in other implementations or tri-planar texturing at present).


Splatting can be pretty cheap most of the time, but I'm just abusing tri-planar texturing in the medium shader, so it's a lot slower than "normal" implementations.


The speed on the LOD morphing is customizable as a constant (changable at run-time), but I just need to sit down and finish building a camera monitor to handle velocity/movement based updates (i.e. if the camera doesn't move, don't check the LODs anymore - also, if the camera is going fast, speed up the morphing).


This weeks upgrades are targeted at making SPT as easy to work with as possible, so I should be addressing most of these issues.



Edit: To show you why I use tri-planar texturing:

Tri-Planar On:


Tri-Planar Off:

[denreaper]

I have the latest SPT2 from https://ogre.svn.sourceforge.net/svnroo ... rain/trunk (r2472). Furthermore I do it like the demo does. Here is my source code. On line 35 I create, and on line 46 I destroy. I don't think I'm doing anything wrong (I hope I am though).

By the way, excellent looking videos

[HexiDave]

I'm almost positive it's because of two things:

1. After you delete mTerrain, you don't set it to zero. There's a reason for this...

2. In frameStarted and frameEnded you call mTerrain, but it doesn't check to see if (mTerrain == 0) first, so it could be calling bad memory. This is what got me in my implementation. I also see you're doing it for getHeightAt.


If that doesn't help (I know you're calling delete from the destructor, but something in Ogre could be trying to get at it), let me know. Send me a call-stack and the Ogre.log if it keeps breaking down.

[Trancient]

I see, so most of current processing is handled by the GPU, so adding a lot of CPU processing shouldn't affect it too significantly.. hopefully.

I was curious about the effect of the shader levels, definately a nice feature for the higher specs.

Now to plug it into my app.

Cheers.

[DanielSefton]

Excellent job with the editing functionality!

I'd like to be able to switch the atmosphere off, say, if I want to use a normal sky or Caelum. An option to turn off just the sky, and keep the fading gradients, and to turn the atmosphere effects off completely with no fog or fade effects. With Caelum, the gradient fade in the distance looks odd, being bright blue, especially at night. I'm not keen on SPT being usable without the atmosphere.

Could you explain more on how you work with the grid? i.e. Place entities at tile X/Y? Code?

I figured that I don't need to wait for physics support to have a character running around. Could I just use raycasting and getHeightAt()?

As for the physics, it would be good if you could throw together a demo using OgreNewt (since it's the most widely used wrapper). It's hard to make much use of it without collision and dynamics.

I imagine SPT will mostly be used in RPGs, FPSs and the like, so I think it's important to consider the aspects involved in those kind of games. In looking to make my project playable and practical, I need to know how best to make use of SPT. I've turned it off in favour of DotScene for now, because adding masses of objects seamlessly on top of SPT is a real ball ache, and without physics, I can't do much.

In your editor, do you plan to have the ability to add objects dynamically? Say, have it imported into the scene and have it 'snap' to the pages, along with raycasting for height. Also, the ability to flatten the terrain underneath certain objects, so that they can be added to slopes. (Ever played Populus? Like when the men 'jump' on the terrain to make it flat for the building =) Or is your editor just for the terrain itself, and objects still need to be added manually? Developing your own scene format would be fantastic. I can't imagine it would be too taxing - just use TinyXML to save out the position/rotation/size of every object and their ray height on each page of the terrain. Also, having the objects affect the lightmap of the terrain would be doubly great.

Well, I have somethings that might need SceneManager work eventually (like EarlyZ and extra culling mechanisms later), it works with the core SceneManager and, when I have time, PCZSceneManager. It just handles geometry data on it's own and feeds it to Ogre as Renderables.

Actually, that's one of the reasons I chose SPT, because it isn't a scene manager. I'm a bit phobic of them, being proprietary to Ogre. AFAIK, you can't have more than one scene manager running at the same time in Eihort anyway, and I already have a scene manager. I don't know; I'm probably speaking nonsense, but it feels clunky; unless you can convince me otherwise.

Anyway, that's just a bunch of new musings I had recently. You've probably considered most of it, but I just want to cover everything in this thread so you and others can use it as a reference and reminder of the issues raised. I know it all adds to the time and size of SPT (we don't want it clunky like PLSM!) But I think its practicality and role in a game environment should be near the top of the list.

[HexiDave]

Excellent job with the editing functionality!

I'd like to be able to switch the atmosphere off, say, if I want to use a normal sky or Caelum. An option to turn off just the sky, and keep the fading gradients, and to turn the atmosphere effects off completely with no fog or fade effects. With Caelum, the gradient fade in the distance looks odd, being bright blue, especially at night. I'm not keen on SPT being usable without the atmosphere.

Right, I had just thrown in the current atmosphere system because I was getting sick of looking at flat terrain and no sky. I have several more implementations coming as well as the obvious "don't use them" option. The reason why it's so tricky is the shaders - I try to avoid multipassing, but I'll see if I can do that as an optional thing. Otherwise, I'll just make tons of examples and snippet shaders to show you how to add it to your own shaders. Basic ambient/diffuse lighting and fog will be seen in the coming updates, so Caelum users needn't fear.

Could you explain more on how you work with the grid? i.e. Place entities at tile X/Y? Code?

Not entirely sure what you mean - this is using a quad-tree, so it's not just a grid of terrain tiles like TSM, ETM and PLSM use. Currently, I have the ObjectHandler class that helps you build SceneObject's, which are just a MovableObject and SceneNode created for you in one item and gives you some automation functions for clamping to the terrain (i.e. making sure the object stays on the terrain). I'll be expanding that further in the future, but for now it's fairly simple and handy.

I figured that I don't need to wait for physics support to have a character running around. Could I just use raycasting and getHeightAt()?

Sure! I do that as well when I don't need to "fire and forget" with my objects.

As for the physics, it would be good if you could throw together a demo using OgreNewt (since it's the most widely used wrapper). It's hard to make much use of it without collision and dynamics.

I'll be doing demo implementations for OgreNewt, NxOgre, OgreBullet and OgreODE when I get the time - sometimes getting the libraries up and running takes more time than implementing test features.

I imagine SPT will mostly be used in RPGs, FPSs and the like, so I think it's important to consider the aspects involved in those kind of games. In looking to make my project playable and practical, I need to know how best to make use of SPT. I've turned it off in favour of DotScene for now, because adding masses of objects seamlessly on top of SPT is a real ball ache, and without physics, I can't do much.

Have you tried working with the ObjectManager/SceneObject stuff in the demo? You basically feed it the data for your object, twist a few settings and it's good to go.

In your editor, do you plan to have the ability to add objects dynamically? Say, have it imported into the scene and have it 'snap' to the pages, along with raycasting for height. Also, the ability to flatten the terrain underneath certain objects, so that they can be added to slopes. (Ever played Populus? Like when the men 'jump' on the terrain to make it flat for the building =) Or is your editor just for the terrain itself, and objects still need to be added manually? Developing your own scene format would be fantastic. I can't imagine it would be too taxing - just use TinyXML to save out the position/rotation/size of every object and their ray height on each page of the terrain. Also, having the objects affect the lightmap of the terrain would be doubly great.

All of that is coming, I just need to sit down and do it. The flatten stuff works already (RectFlatten) and is being improved on, so adding a "flatten under" won't be hard at all. I'd like to work with DotScene and I'll do my best with it, but if worse comes to worse I'll to some file work of my own - not dealing with new territory there.

And, yes, I will eventually have shadow examples and try to get light-map baking for objects, too.

Well, I have somethings that might need SceneManager work eventually (like EarlyZ and extra culling mechanisms later), it works with the core SceneManager and, when I have time, PCZSceneManager. It just handles geometry data on it's own and feeds it to Ogre as Renderables.

Actually, that's one of the reasons I chose SPT, because it isn't a scene manager. I'm a bit phobic of them, being proprietary to Ogre. AFAIK, you can't have more than one scene manager running at the same time in Eihort anyway, and I already have a scene manager. I don't know; I'm probably speaking nonsense, but it feels clunky; unless you can convince me otherwise.

What I meant there was that I'll have implementations that'll work inside a SceneManager (and I want to hook into PCZSceneManager as well), but it won't be required.

Anyway, that's just a bunch of new musings I had recently. You've probably considered most of it, but I just want to cover everything in this thread so you and others can use it as a reference and reminder of the issues raised. I know it all adds to the time and size of SPT (we don't want it clunky like PLSM!) But I think its practicality and role in a game environment should be near the top of the list.

Yep, this should be fairly easy to work with (I want to use it, too!) and I'm keeping simplicity in mind when everything is being built.



Quick update on progress: I've finally cleaned up the editor setup with the OgreWindow and got external FrameListeners working, so I'm in great shape to move on and start integrating fun stuff.

[DanielSefton]

Cool. Thanks for clearing things up. That's put just about all my queries to rest. (for now)

On a different note, it looks damn beautiful with Hydrax. As you can imagine with the reflections of the terrain.

Just out of interest, what kind of game are you planning to use it with yourself?

[HexiDave]

I was planning on some multiplayer worlds while I get OgrePlanet built; I really miss the old Star Wars: Galaxy gameplay, so I'm shooting for something along those lines (very community-based, lots of focus on in-game crafting, customizable homes and cities, player-run government, huge environments, etc). It's one of the games that really brought me to appreciate game development and also to absolutely loathe crappy development companies. Do a search on SWG or Star Wars: Galaxies and read up on it's history - it went from a real fan-favorite to one of the most despised games on the market in about 3 months time. I haven't seen any games even come close to what they had in terms of community support and sandbox-style gameplay (EVE has it's own type, but it's still extremely rigid).

I plan to improve on the original model as well, so it'll look good and won't melt outdated computers. And it won't be run by some greedy company - I intend to get it very community-involved so I won't have to supply a huge back-end that will fall out the second I run out of money.

[KungFooMasta]

As for the physics, it would be good if you could throw together a demo using OgreNewt (since it's the most widely used wrapper).

Could you elaborate on this? Sorry, but I don't believe you on this one, and just by seeing the thread/post statistics, it doesn't appear to be the most busy of the addon forums. I suppose it could be the case that OgreNewt doesn't have many bugs, requests, or updates, which would result in a lower post count, but I kind of doubt it.

If anything, PhysX/nxOgre should be the first demo implementation.

Also I've been wondering, if you create a huge amount of terrain, how can it be stored and re-loaded? Multiple heightmaps?

[HexiDave]

As for the physics, it would be good if you could throw together a demo using OgreNewt (since it's the most widely used wrapper).

Could you elaborate on this? Sorry, but I don't believe you on this one, and just by seeing the thread/post statistics, it doesn't appear to be the most busy of the addon forums. I suppose it could be the case that OgreNewt doesn't have many bugs, requests, or updates, which would result in a lower post count, but I kind of doubt it.

Took me a solid minute to realize you weren't talking to me and mis-quoted or something.

If anything, PhysX/nxOgre should be the first demo implementation.

I already talked to Betajaen, so I have the right way to go with this and have used NxOgre in the past (as well as OgreNewt), but I'm going to get them all done at roughly the same time.

Also I've been wondering, if you create a huge amount of terrain, how can it be stored and re-loaded? Multiple heightmaps?

For now you're stuck with one height-map, but I'm going to have multiple heightmap support as well as ECW decompression (and maybe compression, too, if I can get it all working). I mentioned it earlier in the thread, so it probably got burried, but the ECW SDK is up for grabs, so I can do wavelet decompression without decompressing the entire image at once (meaning, I can get parts of the quad-tree when I need to from several gigabytes of compressed height-map data).

[DanielSefton]

Could you elaborate on this? Sorry, but I don't believe you on this one, and just by seeing the thread/post statistics, it doesn't appear to be the most busy of the addon forums. I suppose it could be the case that OgreNewt doesn't have many bugs, requests, or updates, which would result in a lower post count, but I kind of doubt it.

lol -- I guess I can't justify it. It does seem that NxOgre has gotten a lot more popular recently. Who knows.

I really miss the old Star Wars: Galaxy gameplay, so I'm shooting for something along those lines (very community-based, lots of focus on in-game crafting, customizable homes and cities, player-run government, huge environments, etc).

Wow - sounds ambitious. I look forward to seeing what you come up with!

Have it like Wurm Online - where servers are interlinked, which stitch together terrains in realtime, to have an endless and seamless world. Wurm Online actually has the most incredible terrain system - it allows live terraforming on the servers, including caves and overhangs with no performance hit. I'll have to find out how it works.

[HexiDave]

Overhangs are just other pieces of geometry - the overhang scenemanager around the forums does the same thing, which is basically voxel tessellation. It's planned for the future, but it's some ways off for now.

As for seamless worlds, it's not too difficult to do with SPT even as it is now, but I'll get some testing done to show how it works. I also have OgrePlanet, so I've got options.

[HexiDave]

Alright, I think I'm done for today. Didn't get as far as I wanted, but that's because when .NET wants to fight, it doesn't like to lose. I've got SPT rendering into a .NET Form just fine, but with one exception currently: it hates DirectX. OpenGL is fine and dandy, but DirectX loses the device and scorches my terrain black. Everything else is great, but the terrain is a ruined mess. The Ogre demos run fine in DirectX, minimized or whatever, so I assume I missed something somewhere, so this'll likely get resolved. Worse comes to worse, you're using OpenGL for the editor (not that bad, really).

Wish I had more fun stuff to report, but it was all grunt work today. Hopefully I'll have something to show off tomorrow.

[denreaper]

Seamless terrains will probably be much more practical once there is support for multiple heightmaps. My project is very dependent on yours, so please let me know what I can do to help out.

On another note, I did what you said but still have the same issue. I'm at my girlfriend's house right now but I'll post the call stack and Ogre log when I get back home.

-Denny

[Trancient]

You mention that you might incorporate the ECW Mapper SDK, because it is free for non-commercial uses, will this prevent using SPT in commercial apps?

[HexiDave]

If I read the documentation right, you can use it for commercial apps as well, but there's a limit on compression using the SDK - I think 500 MB pre-compressed. Other than that, I don't think there's any issues.

Regardless, that's just assuming you're using the ECW format for file loading - typical height-map and noise synthesis stuff won't have any anything to do with that.

[Trancient]

Ok, thanks, I wasn't sure how pervasive it might be.

[denreaper]

Call stack:

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6624720 (LWP 7488)]
0xb7d41981 in Ogre::Root::_fireFrameStarted (this=0x81e5130, evt=@0xbf960494)
    at OgreRoot.cpp:625
625	            if (!(*i)->frameStarted(evt))
Current language:  auto; currently c++
(gdb) #0  0xb7d41981 in Ogre::Root::_fireFrameStarted (this=0x81e5130, 
    evt=@0xbf960494) at OgreRoot.cpp:625
#1  0xb7d41ef7 in Ogre::Root::_fireFrameStarted (this=0x81e5130)
    at OgreRoot.cpp:672
#2  0xb7d41f32 in Ogre::Root::renderOneFrame (this=0x81e5130)
    at OgreRoot.cpp:746
#3  0xb7d41fa1 in Ogre::Root::startRendering (this=0x81e5130)
    at OgreRoot.cpp:739

Ogre log: http://rafb.net/p/rfejP235.html

Hope this helps.

Thanks,
Denny

[xadhoom]

lol -- I guess I can't justify it. It does seem that NxOgre has gotten a lot more popular recently. Who knows.

NxOgre is currently in a hot development time. The stable Version (0.9)
is not developed any further and really old (forum support is still available) and
the new Version (Bleeding) currently lacks some features like CharacterControl
and seems to be unstable. But Betajaen is working hard on it and it is a really good PhysX wrapper...

[Edit]
Another plus is maybe the hardware acceleration in the future with the graphic card.

[HexiDave]

Call stack:

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6624720 (LWP 7488)]
0xb7d41981 in Ogre::Root::_fireFrameStarted (this=0x81e5130, evt=@0xbf960494)
    at OgreRoot.cpp:625
625	            if (!(*i)->frameStarted(evt))
Current language:  auto; currently c++
(gdb) #0  0xb7d41981 in Ogre::Root::_fireFrameStarted (this=0x81e5130, 
    evt=@0xbf960494) at OgreRoot.cpp:625
#1  0xb7d41ef7 in Ogre::Root::_fireFrameStarted (this=0x81e5130)
    at OgreRoot.cpp:672
#2  0xb7d41f32 in Ogre::Root::renderOneFrame (this=0x81e5130)
    at OgreRoot.cpp:746
#3  0xb7d41fa1 in Ogre::Root::startRendering (this=0x81e5130)
    at OgreRoot.cpp:739

Ogre log: http://rafb.net/p/rfejP235.html

Hope this helps.

Thanks,
Denny

It doesn't even look like it's getting to SPT. Also, make sure that if you have the latest SPT checkout that you get the SPT2_Mat.material as it makes use of the all the shaders properly.

I saw that your game is on SVN, so I'll check it out in a bit and try it.