Hi,

Can someone help unjam my coders-block please ? I have a point in world space in my Pixel Shader and want to check if it lies within a bounding box (or conceptually any bounding mesh). Whats the quickest way of doing this check ? In 2D C# I'm used to taking an arbitrary line from a point and counting the number of times it crosses a line that makes up a containing polygon - it seems to me there must be an analogy for this in 3D that counts how many times my projected line crosses a plane making up the containing polygon (an odd count means I'm "inside", but an even count means I'm outside, as does a zero count). I'm doing this check for a lot of pixels so it can't be an expensive call.

I have searched around the phrases ("point in bounding box","point in mesh") and it does give me a lot of collision based solutions, but I'm already inside a shader so they dont seem appropriate. It seems like something I should just "get" but I can't seem to visualise it.

Thanks in advance,

Phillip

PS Just in case I'm going at this completely the wrong way, the problem occurs where I'm trying to "layer" a landscape feature over a previously rendered landscape mesh. I'm using a bounding cube that intersects the landscape, and back-calculating the world position of each pixel that is rendered on the surface of the cube, using the inverse projection matrix and the depth buffer to construct the world space of the pixel. Once I have the world space pixel, I want to check to see if it fell within the bounding volume - in which case I should render my texure (river, road, field etc) otherwise the viewer should see the previously rendered landscape.

If you think AABB as min and max corners and you then imagine the point being more than the min but less than the max it should be really easy to figure algorithm.

For an oriented bounding box: if you know the normals of the six planes that make up the box, it's as simple as testing whether the point lies behind all six planes.

dot(point, boxface.normal) < dot(boxface.vertex, boxface.normal)

This should work for any half-space defined convex shape. A point in an arbitrary polygonal mesh test is a lot more involving and is probably not something you would do in a pixel shader.

Using the box as a cut-out like you described should work fine.

Thanks for the tips.

eppo - this would work for a non-AABB, yes ?

eppo, kalle_h, is my method here sound for doing landscape overlays on dyanically rendered terrain; is there another cheaper option, or is this common practise ?

Phillip

eppo - this would work for a non-AABB, yes ?

Yes, any box can be defined as a set of half-space planes.

Doing it all in a single multi-textured pass might be faster, since it needs one less render call and it'll save you the depth buffer lookup. On the other end the branch might have a negative impact on performance. You'd have to try and see for yourself.

All,

I'm grateful for the help given but I seem to be hitting an accuracy problem with the Point in Box when the Point has been calculated by back-calculating the XY from V_POS and the Z from the depth buffer. My depth buffer is a deferred rendered texture SurfaceFormat.Single, but because this is a landsape with a large depth of field, I'm pretty sure this isn't going to be accurate enough to store and then re-calculate the world position well enought to then do my cut-out. I get a lot of artefacts which are explained by the depth buffer not being able to accurately reconstruct my world position. However I do realise that the original world position was expressed a Vector3 (which is a set of 3 Single) so the data is using the same range structures.

Can anyone just confirm that a Single based texture is appropriate as a deferred depth buffer ? If so, I can then go and take my code apart bit by bit to find my problem.

Thanks

Phillip

Just to finish off this topic, the recommended solutions did work. My reported problem with inaccurate clipping was becuase I'd generated by BoundingBox from the objects existing BoundingSphere, which conseuqently was much larger than the "proper" tightly scoped bounding box.

Hope noone else makes this stupid error :-)