Continuation of "Infinite loop" discussion

Discussion continued from: http://www.ogre3d.org/phpBB2/viewtopic.php?t=13789

Actually, I've been meaning to post this but hadn't gotten around to it.

I had already gotten bitten by the "infinite loop" problem a few times, so I revisited the situation.
A better fix it seems would be this:
File OgrePaginglandscapeTile.cpp (did I incorrectly reference OgrePagingLandscapeOptions.cpp before, or did this function move?), line 344.

if (dir.y > 0.0001)
{
while( ray.y < PagingLandScapeData2DManager::getSingleton().getRealPageHeight( ray.x, ray.z,
mInfo.pageX, mInfo.pageZ,
0))
{
ray += dir;
}
}
else if (dir.y < -0.0001)
{
while( ray.y > PagingLandScapeData2DManager::getSingleton().getRealPageHeight( ray.x, ray.z,
mInfo.pageX, mInfo.pageZ,
0))
{
ray += dir;
}
}
else // dir.y == 0
{
*result = Vector3( -1.0f, -1.0f, -1.0f );
return false;
}


Also, I think a temp variable should be used in the while loop, to avoid calling getRealPageHeight many times.

What do you think?

infinite loop too, when launching ray from above terrain in negative direction.

Problem is in 2 case :

0. you start the ray from above terrain :

Old code actually works whatever direction given, with the addition (which is in CVS) of a x,z boundary test (like the while test just above) + y > max && y > 0

1. you start the ray from below terrain

there we need a totally different code.
but do you actually need this sort of queries ?

0. you start the ray from above terrain :

Old code actually works whatever direction given, with the addition (which is in CVS) of a x,z boundary test (like the while test just above) + y > max && y > 0
So you're saying you've got a fix elsewhere that does away with the need for this check?

1. you start the ray from below terrain

there we need a totally different code.
but do you actually need this sort of queries ?
Well, when debugging a game, it can be very useful to be able to go below ground level. Sometimes you can see things down there that you can't from above (like "Where'd my tree go?").

yep in latest dev CVS it's

while (ray.y > dataManager->getRealPageHeight(ray.x, ray.z,
mInfo.pageX, mInfo.pageZ,
0)
&&
ray.y < 0
&&
! ( (ray.x < leftBorder) ||
(ray.x > rightBorder) ||
(ray.z < topBorder) ||
(ray.z > bottomBorder)))
{
ray += dir;
}


Ok I see your need here...

so perhaps the good way would be 2 type of PagingLandScapeTile::intersectSegment
one PagingLandScapeTile::intersectSegmentFromAbove and
PagingLandScapeTile::intersectSegmentFromBelow, selected when we call it in PagingLandScapeSceneManager::intersectSegmentTerrain.

added in dev CVS.
Should be in anon tomorrow

added in dev CVS.
Should be in anon tomorrow

I think an epsilon should be used in the "ray.y < 0" check. I've seen ray.y as a VERY small negative number (-1e-8 or something like that), which can cause lockups.
Or do you think your tests for left/rightBorder will avoid that?

And again, I'd like to suggest a temp var for storing the results of getRealPageHeight. That's not exactly a lightweight function.

[EDIT]
Oops, silly me. You can't use a temp var for getRealPageHeight, because ray.x and ray.z are changing each iteration.

right, adding the epsilon.