Ogre Forums

rubasurex wrote:Firstly, the colour shadows appear to project two sets of shadows in opposite directions. The each house has two shadows protruding opposite from one another.

No, it's just that colour shadows are not depth-aware. It's a single shadow, but it's projected to every point intersecting the caster along the light vector - that's what non-depth shadows always do. Use depth shadows if you want to avoid this.

[/quote]Secondly, with the depth shadows, I noticed that the houses shadow the terrain, themselves and each other, however the terrain shadow never effects the houses. If I place a house in the shadow of a large hill, the house stays fully lit. I understand that the terrain is using a lightmap, which obviously only effects itself. However I was thinking that perhaps with depth shadows, the terrain could cast a shadow that could affect the houses? Is this possible or are there technical or performance limitations to this?[/quote]

Yep, this is because a) it would be impossible in colour shadows (because they're not depth-aware) and b) because the terrain is not a shadow caster right now. You could make the terrain a depth shadow caster if you wanted, it would require modifying the material generator to create a corresponding shadow caster material. I haven't done this because I don't have time to do it, and also it would have a knock-on effect of reducing the fidelity of the shadows generally (since the LiSPSM bounds matching would have to take into account all the terrain patches too, which would reduce the focussing effect). But, it can be done.

In practice though, if I were doing a real scene with this, I'd probably bake terrain shadows into my static geometry ahead of time in my modeller because there's no reason for them to be dynamic unless you have a need for a full day/night cycle. Some people do of course, but they'd need to burn resources on a global terrain-wide dynamic shadowing solution for that, which again we don't supply out of the box (because doing dynamic shadows up to the horizon on large-scale geometry like terrain is A Very Hard Problem And Not One I Have Time To Solve For Free (tm).

Terrain crashes when compiled for x64 (vs2008), is this a known issue or should I submit a bug?

First-chance exception at 0x000007fef0055c55 (OgreTerrain_d.dll) in OgreSnowSim.exe: 0xC0000005: Access violation reading location 0xffffffffffffffff.

OgreTerrain_d.dll!Ogre::TerrainQuadTreeNode::load() Line 255 + 0x27 bytes C++
> OgreTerrain_d.dll!Ogre::TerrainQuadTreeNode::load() Line 250 + 0x14 bytes C++
OgreTerrain_d.dll!Ogre::TerrainQuadTreeNode::load() Line 250 + 0x14 bytes C++
OgreTerrain_d.dll!Ogre::TerrainQuadTreeNode::load() Line 250 + 0x14 bytes C++
OgreTerrain_d.dll!Ogre::Terrain::load() Line 1018 C++
OgreTerrain_d.dll!Ogre::TerrainGroup::handleResponse(const Ogre::WorkQueue::Response * res=0x0000000002782018, const Ogre::WorkQueue * srcQ=0x0000000001ca7758) Line 647 C++
OgreMain_d.dll!Ogre::DefaultWorkQueueBase::processResponse(Ogre::WorkQueue::Response * r=0x0000000002782018) Line 601 C++
OgreMain_d.dll!Ogre::DefaultWorkQueueBase::processRequestResponse(Ogre::WorkQueue::Request * r=0x00000000022c6928, bool synchronous=true) Line 461 C++
OgreMain_d.dll!Ogre::DefaultWorkQueueBase::addRequest(unsigned short channel=1, unsigned short requestType=1, const Ogre::Any & rData={...}, unsigned char retryCount=0, bool forceSynchronous=true) Line 237 C++
OgreTerrain_d.dll!Ogre::TerrainGroup::loadTerrainImpl(Ogre::TerrainGroup::TerrainSlot * slot=0x0000000002781f88, bool synchronous=true) Line 292 + 0x82 bytes C++
OgreTerrain_d.dll!Ogre::TerrainGroup::loadAllTerrains(bool synchronous=true) Line 231 + 0x1b bytes C++

Just a small issue/caveat when using TerrainGroup, instead of just Terrain:

When defining a terrain using a buffer of floats, you need to set inputImage to '0' (zero), otherwise Ogre will try to load an non-existent image:
And, if you do this instead of setting the image to zero: It does not try to load from a non-existent image, but you will cause the destructor of TerrainGroup to crash, when deleteInputData is set to 'true', because it tries to delete an image which isn't there.

It's probably a small bug, because when using Terrain directly, you don't need to set the image to zero when using a buffer of floats.

Please raise these issues as bugs in mantis and they'll be undeniably 'on my list' I can't test in x64 yet though so please provide as much detail as you can on that one, such as current variables and any other investigation you can do, because I'll be flying blind just from what you tell me.

http://www.ogre3d.org/mantis/view.php?id=271

Please let me know if there is anything else I can check. I'm afraid I don't know any of the code so it's hard to do any meaningful investigation;/

This is a minor issue bug report:
http://www.ogre3d.org/mantis/view.php?id=272

sinbad wrote:I'll need a repro case, TerrainGroup does exactly this when being used for paging and I don't get this problem. Make sure you updated to the latest too since I fixed some issues.

Sinbad,

I have a bad news and a good news. Bad News is, yes OgreTerrainQuadTreeNode has a small BUG as i stated before. Good news is its so easy to fix

The problem is you FORGOT to initialize mLocalNode variable to "0" in the constructor, somehow/sometimes it gets initialized with (0x000000F) and it passes the check if(!mLocalNode) in load() which causes the crash next line. So adding a mLocalNode(0) to constructor just after mMovable(0) fixes the problem.

BUT:
Its strange that it gets initialized with 0x0000000F, although its created dynamically, doesnt the allocator create it in a field of 0x00 memory values? If so, there may be other reasons/leaks to be investigated, if not, thats the only small fix

Could you file a bug in Mantis, Stealth?

I just didnt since its such a small bug and fix is included already...

>>>>Its strange that it gets initialized with 0x0000000F, although its created dynamically, doesnt the allocator create it in a field of 0x00 memory values?

This is something I have witnessed many times. Sometimes, it is not initialized correctly. I never had this problem on vs2003, but since I switched to 2008, it seems it is best practice to "verbosely" initialize all objects and values (including bool, pointers, vector() etc...) in the constructor. I think it's a shame thought.

stealth977 wrote:I just didnt since its such a small bug and fix is included already...

Yes, but please file a bug none the less - I bet Sinbad checks Mantis more than this forum these days.
And it's not really a small bug, if it prevents people from using the terrain component.
Small bugs with easy fixes are welcome on our Mantis tracker.

madmarx wrote:

>>>>Its strange that it gets initialized with 0x0000000F, although its created dynamically, doesnt the allocator create it in a field of 0x00 memory values?

This is something I have witnessed many times. Sometimes, it is not initialized correctly. I never had this problem on vs2003, but since I switched to 2008, it seems it is best practice to "verbosely" initialize all objects and values (including bool, pointers, vector() etc...) in the constructor. I think it's a shame thought.

Then you were simply lucky. All POD variables must be initialised, this has always been so in the C/C++ world. If you don't, then the variable will get the value which was present in the memory block assigned to it. That value is entirely arbitrary, it will often be 0, but it doesn't get blanked, so it can contain anything.

It's even more devious than that, as some compilers will automatically set all uninitialized variables to 0 if compiling in debug mode, but not when compiling in release mode. This can lead to a lot of pointer exceptions which aren't caught until the app is run in release mode. But I digress.

'Surviving the release mode' - a classic. Especially when using Visual Studio.
I stopped developing in debug mode a long time ago. (Unless I need to debug something, of course)

Although i am not much familiar with nedalloc's pooling, my observations lead to the fact that usually in the first run the classes are allocated in a fresh memory location and doesnt cause the crash (luckily), but when you start to delete and re-create the classes, the pool may assign a dirty memory location to the new allocated class and that may cause the UNINITIALIZED variables to become corrupt (non-zero) causing the crash.

So, much care must be spent to make sure all variables are initialized correctly and no assumptions should be made to prevent hard to track bugs, especially when pooling is used, also the OLD CODE may create some troubles to us due to NEW CODE (like pooling).

And a side note: Byatis seems to be suffering from those problems since some really unrelated/unexpected classes started to cause crashes without any main application code changes...

Thanks, Stealth:
http://www.ogre3d.org/mantis/view.php?id=273
I was about to file the bug for you, but you beat me to it.

Thanks, fixed.

That was awfully quick

Sinbad:

An option to enable/disable LightMapping and also a function to fully refresh the LightMap would be greatly appreciated (sorry if those exists, but i couldnt find them)

The reason i am asking is, at some point i need to change the lightmap direction and refresh everything, yes i probably can do that by making whole terrain dirty and forcing a deriveddataupdate but, this has side affects:
- I have no idea about the lights in the scene before i create/load them all
- When i have info about the lights and determine which light to use for lightmap, the terrain is already loaded and trying to updateitsderived data, at this point forcing another update is overkill
- So, i could just disable lightmaps the first run, then when i have an idea about which light to use, i can enable and refresh, thats much easier

I am sure there may be other uses for such an option...

BTW: I cant order the loading of lights and terrain, since every object depends on another, brute force ordering is always prone to errors, so my objects can skip some steps and complete them later when the dependencies are ready, but terrain doesnt let me do that

Enable / disable lightmapping is on the TerrainMaterialGeneratorA. Basically the way this works is that a material generator asks the terrain for things that it needs to render, which causes the terrain to calculate them. That's why it's on the material generator.

Try the latest v1-7 svn for dirtyLightmap/dirtyLightmapRect (and call updateDerivedData with the lightmap mask afterwards).

Hey, nothing urgent, and I have no idea how what parts are your priority but I saw this the other day: http://graphicrants.blogspot.com/2009/11/udk.html

After talking a bit about stuff he mentions some of the new UDK's shadow baking features. It seems they generate a lightmap using Valve's 3-component basis (produces 2 lightmaps, or 3 if you want full-color). He also mentions that baked shadows automatically create signed distance fields. I imagine he was talking about the this technique: http://www.ogre3d.org/forums/viewtopic.php?f=1&t=50844. For hard environment shadows it can probably produce incredibly smooth shadows compared to the resolution of the lightmap. Perhaps something to think about for any lightmap generation system. I'll be keeping it in mind for sure.

I am having quite bad results with depth shadows using OGRE::Terrain, this is my first time using shadows and i copied Sinbad's implementation in the terrain sample, the first map is 2048x and the other 2 are 1024x, only change i made is that i have a shadow far rendering distance of 500 instead of 3000 Sinbad used. Below is an example of the problems:
Is this a known problem?? And it seems to me that the shadow is a bit offset too (walls shadow starts from infront of the wall!!

I tried to load 36 terrain pages, and Ogre crashed bitterly.
How many pages have you guys loaded in one go?
I can load it in three batches of 12, but I guess I need to look into making a paging provider?

@stealth977: should have been in a new thread
This is just because you're using front-facing casters and no bias. This is why I use back-facing casters - which has it's own issues such as light bleeding at the back, but it tends to look generally better. See http://www.ogre3d.org/forums/viewtopic. ... 29&start=0 for a more in-depth discussion.

@jacmoe: You probably ran out of GPU memory. The most I've ever loaded at once is 16, normally 9 is plenty. Yes, you need paging I have a TODO about 'scraping' off the most detailed geometry in the distance so that the terrain instances load in 2 (or more) stages, since the geometry is partitioned already in the quadtree so you don't actually need to keep the top-level data in memory all the time if the page is distant. It's one of the in-built benefits of having hierarchical geometry. I haven't had time yet though.

sinbad wrote:Yes, you need paging

Sounds like a good challenge.
Yes, I ran out of GPU memory.