Error in _findVisibleObjects() - Eihort port?

SceneManager changes

* _findVisibleObjects has changed signature, be sure to update your custom SceneManager classes that override this method. It passes a new member, 'visibleBounds' which if non-null must be updated with the bounds of all objects that are found to be visible in the implementation. SceneNode::_findVisibleObjects has changed signature for the same reason.

As it is now, findVisibleObjects() signature is correct, but it ignores visibleBounds.

EDIT:

I have now succefully patched it and I must say that it is quite weird no one noticed this erlier. Enable shadows and you'll see why (tiles inside the textureshadow plane will just be rendered, the others will not). Someone with CVS commit access can PM me here and I'll send him/her the changes (including the fixed setHeight).

Here is a before/after the changes:
Before: http://www.netherforce.com/images/before.jpg
After: http://www.netherforce.com/images/after.jpg

Ah Asmo, my saviour! I have had this problem for a very long time now. I posted about it before with you in a thread I believe, setting the far shadow distance was a small fix but glad you have found the cause behind it.

Has it been uploaded to the CVS yet? If not could you provide the fix here so i can compile with my current version. Thanks a lot!

I have not got any request from anyone who can commit it yet, so no, it is not on the CVS yet. I will upload the source later to night to some other URL, however. Just hold on a couple of hours. (:

Ah, ok just tried CVS and to my disappointment it wasnt there Good that you havent uploaded it yet though, better than it just not working Will be awaiting the update with baited breath, untill that time comes I'll probably watch some more episodes of Heroes, man that show rocks!

Heroes is indeed a good show (:

I have not comment anything of major importance, so you need to check for your self against the original source for what I have changed. Check _findVisibleObjects() and trace from there, if you need to. I have just included the src directory of PLSM2:
http://www.netherforce.com/files/plsm2Eihort.rar

I can not say for sure if this is all that is needed, of course, but everything works for me. This also includes the patch for setHeight and fillBrushArray, so you can use that now as well.

This will not compile against Dagon, if you are using Dagon, use the version that is on the CVS.

Unfortuantely, I am indeed using Dagon It is a requirement of the project i am doing.

Is there anyway to fix this issue with Dagon? I searched for the VisibleObjectsBoundsInfo data type but it seems to only exist in Eihort. Is there anything similar you know of in Dagon or was this a newly introduced thing in Eihort? If I knew what the problem was them maybe I could come to a solution for Dagon users. Any help would be appreciated.

It was introduced in Eihort, so I assumed the problem was due to Eihort, which mine was. Not sure why this happens in Dagon, really.

Ah, I've had this problem for a long time with texture modulative shadows. The only way I found to reduce the effect was to increase the number of renderables and the farshadowdistance. Annoying...maybe I could try and integrate the VisibleObjectsBoundsInfo into Dagon.... long shot I know...

It sounds exactly as the same problem I had in Eihort, which was caused of what I mention above. It was quite a trivial thing to trace down, due to the ignorance of visibleBounds in Eihort, but this I don't know. :/

Hi there, I have tried lookign at the code on the CVS to see if I could come up with a solution for the Dagon version, but for some reason I can't actually find where the findvisibleobjects method is called. I've searched the entire project and all that seems to show up is the declaration and the method itself. Could you shed any light on this? Thanks.

It's a virtual function from the tree/treenode in Ogre, so it's called by Ogre core.

Don't know how I missed that.

I'm trying to gte it working with Eihort. Is there anyway you could also post your include direcotry asmo? It's just that there are so many changes that need to be made to all the header files. Would save me a lot fo time and headaches I'm sure.

I notice you were having problems with splatting via eihort even after Tuan posted some code that was supposed to fix it, I too am now having an issue with it. Did you ever manage to solve that?

Of course, updated the rar to include both src and include:
http://www.netherforce.com/files/plsm2Eihort.rar

I notice you were having problems with splatting via eihort even after Tuan posted some code that was supposed to fix it, I too am now having an issue with it. Did you ever manage to solve that?

I did not know he posted code that fixed it, or what the problem was, but this includes the fixes I'v made to Eihort and splatting works fine.

Thanks a lot, will give ur files a go in a few mins...

The fix for splatting I was referring to is here:

http://www.ogre3d.org/phpBB2addons/viewtopic.php?t=3610&highlight=splatting+eihort

2nd post from the bottom, just above your post actually.

Oh yes, that is fixed as well (:

The problem with the code tuan posted was that e was never checked to be not null, which of courses causes a crash when it is.

The code you agve me compiels nicely, but it still crashes in this piece of code, the same bit I believe Tuan posted that I linked to in previous post.


// splat settings.
#ifdef PLSM2_EIHORT
GpuConstantDefinition const * const e = params->_findNamedConstantDefinition("splatSettings", false);

// use index to get RealConstantEntry
CRASH!---> params->_writeRawConstant(e->physicalIndex + 0, opt->matHeight[1]);
params->_writeRawConstant(e->physicalIndex + 1, opt->matHeight[2]);
params->_writeRawConstant(e->physicalIndex + 2, float(opt->maxValue));
params->_writeRawConstant(e->physicalIndex + 3, 0.0f);

#else
GpuProgramParameters::RealConstantEntry * const e = params->getNamedRealConstantEntry ("splatSettings");
if (e)
{
e->val[0] = static_cast <float> (opt->matHeight[1]);
e->val[1] = static_cast <float> (opt->matHeight[2]);
e->val[2] = static_cast <float> (opt->maxValue);
e->val[3] = static_cast <float> (0.0);
e->isSet = true;
}
#endif


I've used the universal symbol "CRASH!---> " to show where it crashes.

Are you sure you are using my modified code?
Btw, I just edited my last post to describe why it crashed :p
The correct code should be like this:
if(e)
{
// use index to get RealConstantEntry
params->_writeRawConstant(e->physicalIndex + 0, opt->matHeight[1]);
params->_writeRawConstant(e->physicalIndex + 1, opt->matHeight[2]);
params->_writeRawConstant(e->physicalIndex + 2, float(opt->maxValue));
params->_writeRawConstant(e->physicalIndex + 3, 0.0f);
}

It may be that you are using the uncompressed shader, at what line and which file did you find that code?

yeah, I am using the uncompressed shader. The file is ogrepaginglandscapetexture.cpp and the line is 135.

Then you can't be using my version :/ Re-check so you are using the source I posted above.

I'm online @ irc (#ogre3d - irc.freenode.org) now if you want to chat there instead, a little easier than on the forum (:

Whoops, I replaced the wrong files. The only reason it compiled was because i had edited the .h files myself before you got back with your files Sorry about that. Just recompiling it now................

Ok, the spaltted map runs now.... can't tell if anythings working though, cause it freezes Must just be my game not being compatible with something in Eihort. Thanks a lot for your help Asmo, I got there in the end

Np (:

Good luck with the game!

After quite a while of strugglign to get my game running again, I have it in a state where i can walk around again. Problem is though, is that the shadow bug still seems to be there. I definately have your code running this time asmo so its definately not that. When I turn off shadows its fine, but as soon as I enable shadows the tiles start cutting off dependent on the value I set for farshadowdistance. Is there anything else you changed asmo apart from what you've already given me?

This is my .cfg file in case I have any wrong settings:


GroupName=PLSM2

Width=1
Height=1

Data2DFormat=HeightField
LandScapeFileName=testMap
FileSystem=testMap

TextureStretchFactor=2

VisibleRenderables = 2000
MaxAdjacentPages = 100
MaxPreloadedPages = 100
MaxNumRenderable = 100
MaxNumTiles = 100

NumTextureFormatSupported=1
TextureFormatSupported0=PLSplattingShaderLit
TextureFormat=PLSplattingShaderLit

ScaleX=10260
ScaleY=5100
ScaleZ=10260

Deformable=yes
VertexCompression=no
VertexProgramMorph=no
VertexNormals=yes
VertexLit = yes
TextureModifiable=yes
MaterialDistanceLod=400000

#PositionX = 5130
#PositionY = 0
#PositionZ = 5130

PageSize = 513
#RoughnessLod=no
DistanceLOD=16
#MaxRenderLevel=100

NumMatHeightSplat=4

SplatFilename0=Terrain_Dirt1.jpg
SplatFilename1=Terrain_Rock1.jpg
SplatFilename2=Terrain_Grass1.jpg
SplatFilename3=Terrain_Cobble1.jpg


I set my shadows using this standard code, nothign out of the ordinary here:


mSceneMgr->setShadowTechnique (SHADOWTYPE_TEXTURE_MODULATIVE);
mSceneMgr->setShadowColour(Ogre::ColourValue(0.5, 0.5, 0.5));//config
mSceneMgr->setShadowFarDistance(2000);//config
mSceneMgr->setShadowTextureSettings(2048, 1);//config


Oh yeah, and the splatting is working beautifully!

I just tried the demo that comes included with the cvs plugin, I tested the alpes map.

After getting the input to work again, I noticed that when you are REALLY far away from the map it displays it correctly, its when you get in between really far and close it disappears completely. Then when you get to about ground level the tiles appear as you move towards them. It only happens when shadows are turned on. Strange, and I have no idea how to fix it

Can anyone confirm that I'm not the only one who has these issues? I'm using an ATI radeon x1900xt and have vertex compression off.

@asmo: Out of interest what culling mode have you got set for your camera?

I'm using the default culling mode (not CHC). I'm not sure CHC is working as I have not tried it, but I did make the changes there as well.
I have noticed problems with shadows casted from point lights, is that what you are using?

The only light source I have in my scene is a directional light. I have noticed that depending on what direction you set it to it chnages the distance tiles get culled at.

In your pictures it loks like you have fog enabled, if you disable it do the tiles still remain? The only difference I can see is that I dont have fog turned on. Kinda clutching at straws at this stage.

Have you tried the demo that comes with the cvs? To get the input working i just took out the capture from the if(!mInputSwitchingOn) and put it at the start of the framestarted method. Seeing as my app is based of an older version of that same demo, perhaps there is something inherently wrong in the demo that maybe you dont have included in your app?

It works while fog is disable as well (I actually use my own fog rutine for fading the terrain in the shader). It sounds really strange, it is the same problem I had before I patched PLSM2 with visibleBounds, can you debug _findVisibleObjects and see if visibleBounds every is set?

Ok, I added a printf to your code in the plugin to see what the min and max distances were in visiblebounds....


if(visibleBounds)
{
int erwwer = 1;
printf("\nVISIBLE BOUNDS IS DEFINED!: The max distance is %f, Min DIstance is %f\n", visibleBounds->maxDistance, visibleBounds->minDistance);
}


The print out from my console is this:


VISIBLE BOUNDS IS DEFINED!: Max distance: 0.000000, Min DIstance: 1.#INF00


So whilst it is getting though the if statement, it doesnt seem to be getting setup properly. There is of course a whole load of other variables that make up visiblebounds, but these were the easiest to print out. I hope thats enough info. I assume those values are wrong... Is there an easier way to debug the plugin rather than using if statements? I've never had to debug files that aren't actually part of my project before.

EDIT: Ah, you can debug dlls by providing an exe, cool feature I never realised was there. Gonna debug properly and see what i get....

Ok, heres what the debugger had to say about visibleBounds:


visibleBounds
aabb
mMinimum
x -4.3160208e+008
y -4.3160208e+008
z -4.3160208e+008
mMaximum
x -4.3160208e+008
y -4.3160208e+008
z -4.3160208e+008
mExtent EXTENT_NULL
mpCorners
x CXX0030: Error: expression cannot be evaluated
y CXX0030: Error: expression cannot be evaluated
z CXX0030: Error: expression cannot be evaluated
minDistance 1.#INF000
maxDistance 0.00000000


Make of that what you will

On the subject of culling, the only one that doesnt freeze for me is the default which is frustrum_direct.

visibleBounds should be set if not null (or updated), and will most likely not contain any good values before that. The code I made there was just for a debug breakpoint, so remove that :p

Check OgrePagingLandScapeOctreeNode.cpp - Line 172:

if (visibleBounds)
{
visibleBounds->merge(mo->getWorldBoundingBox(true),
mo->getWorldBoundingSphere(true), cam);
}

Here is where visibleBounds gets updated.

Ok, sorry about that.

It does indeed seem to get updated, it changes every time i continue (F5), i assume this is the aabb boxes for each visible node? The only value that never gets initialised is the mpcorners(the corners of the box?)

Also, the mExtent sometimes goes to EXTENT_NULL, when this happens, the maxdistance becomes 0 and the min distance ebecomes 1.#INF000.

I could try and upload a cutdown version of my app sometime tonight if you wanted to take a look...

Sure, I can take a look tonight / tomorrow if you want.

Hi all,

I patched in the changes discussed above in this thread to my _CVS build (taken from HEAD a few days ago), but wanted to mention that they break the mapsplitter.

I'm starting to port my older work, which was based on Dagon, to a new project based on Eihort, and want to get PLSM2 up and running this time around. (I'm a PLSM2 noob, but I think I've tracked down and read most of the info I need.)

Regarding the mapsplitter, can I use the old Dagon build of that tool, say from the September stable release, to split my maps for use by the Eihort-patched PLSM2? At least until I learn more about this system?

Thanks!

I'm still using the mapsplitter from the spetember sdk and it's fine, so yeah you can still use it. Do the changes you made from this thread fix the problem when shadows are enabled? i.e. tiles disappearing if they are outside the shadow distance?

Thank you for your reply--Since the old Mapsplitter should be ok, I am using maps I split last year.

I might not have correct results for a little while though, because this time around (with Eihort replacing Dagon), I am trying to refactor the minimum relevant PLSM2 code from the sample into my own application without actually having to get the sample running first. The last time I got that sample running, it was so sample-centric that it drove me nuts

It is running now though, (thank you for the patches) and rendering ~something~, so my next step is to correct my scene/camera/lighting parameters and see just what the heck is flickering down there...

nindim:
Do the changes you made from this thread fix the problem when shadows are enabled? i.e. tiles disappearing if they are outside the shadow distance?

I don't think so. I went back to testing with the sample application, and I still see the same lossy tile problem I saw under Dagon. I'm using the ps_height_1k and the alpes maps, and if I move the camera up and down above the map whole batches of tiles disappear suddenly as I move in, and reappear as I back out, until I toggle through the "C" key to no shadows. The tile loss appears to be more random on the alpes map, though.

I'm still not sure that this problem is a problem in the plugin, the sample application, the terrain configuration metrics I'm using, or a combination of all these.

I want to throw out the sample app completely, and instead start with the minimum PLSM2 functionality to allow a camera to walk the terrain--much like what was done with the original standard ogre terrain demo, but adding the paging functionality.

I've sent a stripped down version of my app to asmo, so hopefully he can find whatevers causing it in my implementation, which funnily enough is based off of the demo. Possibly there is something inherently "wrong" with the demo that is causing this strange bug. Hopefully asmo has done something differently in his app (which doesnt seem to suffer from this problem) and can determine the problem. At least that is what I hope for.

Ratz, my last reply was vaporized on submit. I hope I remember to never, ever again write a long reply into a web page directly.

The short reply is that I took a very small amount of relevant code from the PLSM2 demo, and put it into my engine application. With a well behaved application and joystick controls, it became immediately clear that the metric for shadow distance was too small for the map scale and camera height above terrain (puget sound data set). I raised it to a large number, and had good visible results. Maybe the shadow distance is being incorrectly applied to the tile visibility determination? I don't know, I'll have to study deeper.

I also think somebody already pointed this out, I vaguely remember reading something buried in the deep history on this forum.

In any case, I think PLSM2 with some cleanup would be helpful for at least a few independent projects, until we get to the Shoggoth/PLSM3/HyperSceneManager era.

A good exercise would be to take the same small amount of PLSM2 code I ported to my engine, and port it back into the standard Ogre Terrain sample. It really is pretty simple. That and clean up the noisy integration issues that really shouldn't be there this late in the game.

I'll look at that in a bit.

-cheers!

Yeah, the visibility of the tiles is linked to the farShadowDistance that is defined.

As asmo pointed out earlier (and you have also now come to the same conclusion) it seems to only render tiles that are within the shadow texture volume. Annoyingly, the larger you make the far distance, the more degraded the quality of the shadows become and the more computationally expensive as it calculates more object's shadows etc.

This is probably the one feature of the PLSM2 I would like to get fixed above all else. The lack of any shadow on my main character just now gives him a very floaty feel, he looks disconnected fom the ground under him. A shadow would help cement his position in the scene. I could always use a textured mesh decal underneath him, but there is something really nice about having dynamically changing 'accurate' shadows.