View Full Version : RayMeshGridIntersect Grid Size testing...

02 February 2006, 02:18 AM
James Haywood wrote:
...and how exactly do you determine the best grid size when using RayMeshGridIntersect?

For James (or anyone else interested), here are some results of recent testing I've done regarding optimal grid sizes when using RayMeshGridIntersect. I've just finished an event handler in my script that uses the intersectRay, getClosestHit() and getHitDist methods extensively. I figured it was a good time to fine tune the grid settings for speed.

Shown below is the code I've been using to automatically calculate an appropriate grid size for RayMeshGridIntersect:

MyGridThingy.initialize (((MyObject.numfaces / MyDivisor) + 2) as integer)

Now, I've had MyDivisor = 1000.0 for some time, but I just recently tried adjusting it to see if there is a speed gain. To my surprise, there is a considerable one....below are the results.

Keep in mind that this process is done on a terrain mesh with bounding box dimensions of 100 x 100 x 14.7 units. This mesh is a Delaunay-subdivided (at varying face counts) NURBS plane with Noise and Edit Mesh modifiers applied to it, so it is not a closed object. Obviously, these acceleration results might be very different with a mesh of different shape/dimensions.

At 5,000 faces:
(MyDivisor values / Processing time)
1000.0 -> 7.984 sec
500.0 -> 6.328 sec
250.0 -> 4.891 sec
150.0 -> 4.265 sec
100.0 -> 3.969 sec
50.0 -> 4.047 sec

At 30,000 faces:
(MyDivisor values / Processing time)
1000.0 -> 22.641 sec
500.0 -> 17.156 sec
250.0 -> 14.672 sec
150.0 -> 14.812 sec
100.0 -> 14.625 sec
50.0 -> 23.285 sec Grid size here: 602

At 60,000 faces:
(MyDivisor values / Processing time)
1000.0 -> 35.516 sec
500.0 -> 28.359 sec
250.0 -> 26.500 sec
150.0 -> 28.187 sec
100.0 -> 30.703 sec Grid size here: 602
50.0 -> ? Grid size here: 1202
(Max locked up immediately with this grid size...twice!)

Conclusion #1:
There is quite a bit of speed to be gained by optimizing the grid size. For this range of face counts, a value of 250.0 looks like a fairly ideal setting.

Conclusion #2:
There appears to be a limit to the grid size that can be requested without locking up Max.
The highest successful grid size tested was 602, while the size of 1202 immediately locked up Max both times it was tried. Subsequently, I've decided to limit my grid sizes to a maximum of 500. My new code is as follows:

local fastgridsize = (((MyObject.numfaces / 250.0) + 2) as integer)
MyGridThingy.initialize (if (fastgridsize<=500) then fastgridsize else 500)

Note: There's a reason I didn't test higher face counts. In my terrain work I need to be able to use the Optimize modifier, so I can't deal with meshes that have more than about 60k faces. (At least in Max 6, the Optimize modifier craps out and stops having any affect at all when face counts go above ~64k.)

02 February 2006, 11:41 PM
This is great information, John. Thanks for putting in the effort and sharing the info.

CGTalk Moderation
02 February 2006, 11:41 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.