why noone points me that 6th and 7th parameters in Unproject() is not ZNear and ZFar, but Viewport.MinDepth and ViewPort.MaxDepth

Sorry, I'm not very good with SharpDX...

SO, could you please tell how correctly make ray a maximum length possible?

Why don't you just use Ray.GetPickRay: http://sharpdx.org/documentation/api/m-sharpdx-ray-getpickray?

Note also that from the description of Ray.Direction (http://sharpdx.org/documentation/api/f-sharpdx-ray-direction), it seems that Ray actually always holds a normalized (length 1) vector for the direction of the ray, so there's no such thing as a "maximum length" ray - SharpDX Rays always have length 1, and they are probably always treated as "infinite length" in calculations.

Why don't you just use Ray.GetPickRay: http://sharpdx.org/documentation/api/m-sharpdx-ray-getpickray?

I don`t know why, but this method almost always return direction as NAN and correct position. Its strange, but it is.

Unproject() work correct, but I can`t peek object because intersection gives me false when I far from object and true when I am inside bounds.

It returns true ONLY when camera is inside the boundbox.

This is how I check intersection.

Vector3 point;
bool intersect = ray.Intersects(ref box, out point);

The same result for all other intersections. So, I don`t know how to check intersection with the ray while camera is not inside the boundingbox...

As far as I can tell so far, you are testing if a view-space Ray intersects with a world-space BoundingBox. To get a world-space ray, you have to multiply the Ray with the inverse of the view matrix.

But GetPickRay should also work IMHO. If I were you, I'd try figuring out why it returns NaN, by changing the input values,rather than re-implementing it's functionality from scratch. You had the same NaN problem with your own implementation, remember? And now we also know that it's pointless to give a huge value for ZFar, since in the end, Ray.Direction is always length 1 -- ZFar doesn't affect it in any way, except when you use a value that is too big, which will cause Ray.Direction to be filled wtih NaNs. Maybe if you reduce your ZFar value to something more acceptable, GetPickRay will work properly... First, give up the assumption that you have to use huge numbers for things to work properly (or that the computer can even interpret those huge numbers), then check, ouble-check,and triple-check all your variables in debug, to make sure they really are what you want them to be.

OK, i found out the use case. Seems it works now. I have to increase ZNear to 10 to keep ZFar in my Projection Matrix with 16 000 000. In that case it works. Seems that than bigger ZFar, that zNear must also become bigger...

In near vector and far vector instead of ZNear, ZFar muste be 0 and 1 correspondingly. SO, both methods now working the same and at last picking is working correctly, but strange thing happens:

If i decrease ZNear in projection matrix <10 for ex, 8, ray becomes unstable and periodically looses boundingbox althought vectors are still NOT NAN. Some sort of magic happening here...

I don't understand why after everything I've explained, you still try to use large values for ZFar. Fine, then... just use ZFar=1000, because I'm telling you to .

Some sort of magic happening here...

There's nothing magic about it. It's something like this: SharpDX takes your huge 16000000 ZFar value and multiplies it by 2 (best case), or even by itself (worst case)... The result of this multiplication will be a number that is way above 16777216, and like I've been trying to tell you, that's where the crazy happens. You have to use values that account for whatever SharpDX or D3D might do with them. 1000 is pretty reasonable. Or do you have any reason that I don't know of to stick with 16000000?

Or do you have any reason that I don't know of to stick with 16000000?

Yes. For now I use this huge numbers in my projection matrix to create projection for space simulator. If I use 1000, I wiil just don`t see nothing. I need at least 1 000 000 and more. IDK, maybe in future numbers will be changed, but for now I cannot do this.

But with 16 000 000 as zfar and 10 as znear works just fine.

BTW, ZFfar doesnt present in projection matrix in clear view. There is no huge numbers in result matrix, except position maybe. So, The only problem here is ration between ZFar and ZNear.

There is no huge numbers in result matrix, except position maybe.

There don't have to be... For bad things to happen, it's sufficient that an intermediary calculation produces a large value (that maybe then gets divided, subtracted or square-rooted back to a small value).