C++ custom tool SDK programming tip

[Ahmidou]

Nice Steven! too bad I didn't found the time to finish mine... Anyway as piotrek pointed it was slow with dense meshes and your's should be more effective

[origin]

Steven what about cmake tutorial you mentioned some time ago on mailinglist ;)

[scaron]

i made the first part a while ago, just not the second part which is needed for new projects using cmake. feel free to ask my any questions though... maybe i can turn this new project into a tutorial on cmake also

[luceric]

just wanted to note that you can talk to the developer of the tool SDK (and the tweak and manipulators), Brent, by posting on the XSI mailing list.

[scaron]

i figured brent is too busy working on maya ;) thanks for the reminder...

s

[scaron]

here is the code...

https://github.com/caron/SimpleBrush

this basic brush looks like the built in weight paint brush, adjusting the radius with the r key works, normal alignment is still wrong. i am trying to mimic the built in weight paint brush, i havent figured out how they're doing the smooth interpolation or averaging yet. you can see it on the default sphere when you move the brush across the surface.

i am sharing for others who haven't made a brush tool yet but want to, this should could be a nice start. piotrek wont find anything new in here ;)

steven

[origin]

I have noone to learn from in my work so I welcome any piece of code with joy
I have a question, do you write those cmakelist.txt files by hand from scratch or you have some templates that you fill only with links to libs and cpps? Do these files work without any modifications on linux too? (i started to learn fedora...)

[scaron]

I have a question, do you write those cmakelist.txt files by hand from scratch or you have some templates that you fill only with links to libs and cpps? Do these files work without any modifications on linux too? (i started to learn fedora...)

i usually copy from my last one, or copy from other available projects using cmake (alembic is big ol'nasty one) but otherwise they are written by hand. this file can be source controlled easily and is included in the visual studio project so you can make edits easily. visual studio actually knows when you changed the cmakelist.txt and will auto regenerate the project with new settings.

i only have to fill out 'extra' links, at this time the FindSoftimage.cmake module (this is actually all the hard work done by alan jones) doesn't understand CustomTool plugin types but that is an easy addition and i will do so eventually so all you need to do is call 'add_softimage_tool_plugin()' and the adding of the ogl and glu libs will be taken care of automatically. also you can use globbing to collect all your source files instead of listing them by hand. http://www.cmake.org/Wiki/CMake:How_To_ ... nput_Files

these cmake files might need modification for linux, but since alan jones made them i doubt it will be much to change. this does NOT mean you can neglect to make your code cross platform. the FindSoftimage.cmake module needs to be updated as new versions of softimage come out, updating the various paths to the new version.

good luck!
s

[origin]

Thanks I migrated all my projects to cmake, simply by editing your cmakelist.txt and hand typing all the *.c* and *.h files. So no more setting up VS projects, great!
Now the only annoying thing is that I have to copy my .dll from cmake's build dir to plugin's Application/bin/... folder everytime I build project in VS. Should I manually change output directory in VS?

[origin]

OK It was just a matter of setting CMAKE_INSTALL_PATH pointing to plugin base dir. and turning on INSTALL project in Configuration Manager

[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...