Ray Intersections with Terrain

Jon

12-05-2007 23:56:05

I started looking into this since it is an area which depends on rectangular tiles linked together. Here are a couple of observtions:

1) It seems like these intersections could be computed by the page, and probably more efficiently. (Note the 36 stack frames due to recursive calls)

2) In PagingLandScapeTile::intersectSegmentFromBelow, if the ray starts out with a negative Y component and is pointing down, it will never intersect, yet the ray in practice is propagated from tile to tile, page to page. At a bare minimum I want to add a check here and in intersectSegmentFromAbove to check for that.

Now one might ask, how is it possible to start with a negative Y? I'm not sure of the exact details, but I set a breakpoint and clicked on the terrain, and started out with:

* ray start {x=-3282.6833 y=-153.61951 z=-8905.7705 }
* ray direction {x=0.50141233 y=-0.15366226 z=0.85145384 }

3) There seems to be a problem with tile linkage across page boundaries:



# 3,1,5,0 (south to)

# 3,1,5,1 (east to)

# 3,1,6,1 (south to)

# 3,1,6,2 (south to)

# 3,1,6,3 (east to)

# 3,1,7,3 (south to)

# 3,1,7,4 (south to)

# 3,1,7,5 (east to)

# 4,1,0,5 (south to)

# 4,1,0,6 (east to)

# 4,1,1,6 (south to)

# 4,1,1,7 (south to)

# 4,2,1,0 (east to)

# 4,2,2,0 (south to)

# 4,2,2,1 (south to)

# 4,2,2,2 (east to)

# 4,2,3,2 (south to)

# 4,2,3,3 (east to)

# 4,2,4,3 (south to)

# 4,2,4,4 (south to)

# 4,2,4,5 (east to)

# 4,2,5,5 (south to)

# 4,2,5,6 (south to)

# 4,2,5,7 (east to)

# 4,2,6,7 (south to)

# 4,3,6,0 (south to)

# 4,3,6,1 (east to)

# 4,3,7,1 (south to)

# 5,3,7,2 (east to) !!!

# 5,3,0,2 (south to)

# 5,3,0,3 (south to)

# 5,3,0,4 (east to)

# 5,3,1,4 (south to)

# 5,3,1,5 (east to)

# 5,3,1,5 (south to)

# 5,3,2,6 (south to)

# 5,3,2,7 (east to)

# 5,3,3,7 (runs south off loaded pages, negative result)

# final ray position {x=12640.270 y=-5034.0562 z=18140.979 }

4) As suspected, there is a similar problem with PagingLandScapeTile::intersectSegmentFromAbove where the ray starts out below the local max (which seems reasonable), but pointed down and therefore unable to reach the local max. Frankly an intersection check against the max perplexes me.

4.5) Maybe this is why I've been unable to place a sphere on the terrain using the PLSM demo application under Eihort.

Rowan

14-05-2007 01:05:27

It's coincidental that you've just posted this as I've just finished re-working the very two functions you mention due to having significant problems with accuracy and other issues.

I intend to post my [ fairly average ] code soon, but I'm just giving it some run-time testing before doing so.

I also found the sphere placement in the demo was now broken as well, just needs a little code, not sure why though.

nindim

14-05-2007 04:24:24

That would be great if you could post your (hopefully) working code soon. My game is due this friday (18/05/07), so if the ray scene query intersection problems were sorted before then thatd be nice

Jon

16-05-2007 21:37:46

Rowan: did your work touch on the improper page-shift in the ray? Or is that still in there?

Looks like a fun thing to track down, but I don't want to waste time on it if there is code going into CVS to fix it.

Rowan

17-05-2007 03:30:34

I'm not exactly sure what problem you are referring to ( are you saying incorrect tiles are being referenced as the ray proceeds? ).
There was a problem when the ray crosses 'tile' boundaries in that the function would return there and then, where it should actually continue until the terrain is hit, which I have addressed.

I have taken note of the cases you mention in point 2.
Re point 4, as far as I have gathered, the test against localMax is there to save unnecessary calls to getHeight(), which is probably more useful than not ( IMO ).

Unfortunately I have become very busy at the moment, so I haven't had much time to work on it ( a bug has crept in while finalizing ), also, I PM'd Nindim a version and he has reported a performance problem ( which is surprising, but certainly possible ), so I need to do a little work before it's worthwhile posting, maybe by the weekend or something.

Jon

17-05-2007 04:25:36

Yes, incorrect tiles are being referenced as the ray proceeds. The entire path was shown above, the error is:



# 5,3,7,2 (east to) !!!

# 5,3,0,2 (south to)

Those tiles are not adjacent. There should have been a page change rather than wrapping within the page.

A much more fun problem than trying to figure some way to pump up the number of splats without adding passes.