This function is called twice per pixel to create the ray and i have found that this is by far the bottlneck as using the same precomputed ray for each pixel (just for the purposes of a speed comparison) is the difference between 10fps and 60fps. My only conclusion, given that the Unproject function is significantly slower even than the ray/tree traversal, is that unproject must be severely unoptimized. This I'll admit would not usually be a problem given that its mostly used for picking but in this case it needs to be as fast as possible. Could someone with a better handle on 3D math show me an exposed version of the function (optimized if possible but not necessary).
As a pointer i feel there ma be an optimization that could be found in precomputing an array of rays based on a viewport at some specific location and then transforming the rays within the ray loop. I also tried simply unprojecting the starting point of the ray and setting the direction to the forward vector of my view matrix, to cut out one of the Unprojects. I expected something akin to orthographic projection but got something akin to a dog's breakfast, still don't understand why

New Topic/Question
Reply



MultiQuote


|