C++ custom tool SDK programming tip

[Ahmidou]

Hey Ahmidou, I think SetupPointLocatorQueries is very slow when you pass -1 (all polys) argument, so its better to restrict search for particular polygons

Hi Piotrek,
I took some time to run some tests and found out that it's equivalent.
The only difference is when moving the camera, when I pass a polygon, it's slower on the first and second iteration,
then it's coming back at the same speed.

Good to know!

Cheers
A

[origin]

I think it's dependand whenever raycasting cache (generated with GetRaycastIntersection...) is cleared or not.
It's cleared when you lose scope of your PolygonMesh variable.
So best bet is to run SetupPoint.. in customtool's Setup function (and maybe in SelectionChange event) with PolygonMesh being global variable.
This way cache is generated only once and futher raycasts are instant.
Eg for 31 million poly raycasting with cache its realtime (no drop in fps)
The only problem is to keep this cache so It won't be cleared when you exit the tool, not sure how you would do that (it take ~10seconds to cache 31 million tri object)
I think, watching ram usage, in your LivePaint tool you're recaching also on changeview which leads to huge performance drop.
Another case in your tool is that your pointposition change, so the cache needs to regenerated every mouse drag...

[scaron]

as far as caching goes the Geometry class provides PutCache and GetCache...

http://download.autodesk.com/global/docs/softimage2013/en_us/sdkguide/index.html?url=si_cpp/classXSI_1_1Geometry.html,topicNumber=si_cpp_classXSI_1_1Geometry_html,hash=a776317aeb4cf15a9d68074a17c38d824

but with a plugin ahmidou's where the point positions are changing constantly it might not be useful. unless the cache can be some how partially and incrementally updated. i doubt that though

[Ahmidou]

I just saw the Put/GetCache yesterday, this might be usefull for a relax+shrinkwrap brush.
Anyway the tool is already faster than push or smooth + weightMap, but I'm still testing which method would be faster.
Piotrek you're right and it make sense, there is some point where rebuilding the acceleration tree become slower than the pickBuffer.
It also need to be rebuilt for the GetClosestLocationsWithinRadius which I'm forced to use every drag update...