There are raycast methods in xsisdk http://www.si-community.com/community/viewtopic.php?f=16&t=2595&p=20942#p20942
From: Steven Caron Sent: Tuesday, July 31, 2012 10:38 PM To: [email protected] Subject: Re: SDK : caching the tool context pick buffer thanks, i am going to use the fps counter for now ... i made some progress last night... i am caching the pickbuffer properly now and can reuse it, its a single view only now and just compares a CTransformation i get off the view camera. removing snap reduced the lag a fair bit. the reason to use the snap was to get the hit position on the surface. while not complete i changed to use the polygon's vertices average position and their average normals to setup a CPlane which i then intersect the world ray with. i am not checking to see if i am inside the triangle yet but even this saves me considerable time and effort in making my own intersection routines. i haven't got my brush orientation perfect yet but i think that's just a matter of wrangling my oglRotate calls. fun stuff! steven On Tue, Jul 31, 2012 at 1:21 PM, Brent McPherson <[email protected]> wrote: The longer a tool takes to process an input event the less events that gets generated by the window system so you would have a bigger distances between mouse move events. (which could lead to gaps in brush spacing in a paint tool etc) I guess you really want to measure mps - mouse events per second. ;-) The fps counter should work because when interacting the tool generates a redraw after each mouse event but you would need to try it to be sure. -- Brent From: [email protected] [mailto:[email protected]] On Behalf Of Steven Caron Sent: 31 July 2012 20:59 To: [email protected] Subject: Re: SDK : caching the tool context pick buffer @brent, can i use softimage's fps counter to do speed testing? does that counter represent the entire ogl rendering pipeline? no biggie if not, i just didn't want to have to make my own profiling/fps counter. s On Mon, Jul 30, 2012 at 3:09 PM, Steven Caron <[email protected]<mailto:[email protected]>> wrote: well the CGeometryAccessor is a dump of everything too, but its just float/long data arrays instead of full fledged classes. at least i could cache this data easily without loops... should be a fun exercise, which is available here for anyone who is interested... https://github.com/caron/SimpleBrush On Mon, Jul 30, 2012 at 2:58 PM, Brent McPherson <[email protected]<mailto:[email protected]>> wrote: I would say use the GeometryAccessor but I have probably used the SDK less than most of you guys. ;-). One thing that always bugged me about GetPolygons and related geometry calls is that they return an array of *all* the polygons in the object so it is a really inefficient way to access a single polygon when you know its index. l_polymesh.GetPolygons().GetItem(l_compIdx); GeometryAccessor seems designed to address this shortcoming.
