Sounds cool Steven! Feel free to log suggestions for the tool SDK with support.
I had ideas for adding methods to the pickbuffer to get surface position, normals etc but I am not directly involved with this anymore... -- Brent From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Steven Caron Sent: 31 July 2012 21:39 To: softimage@listproc.autodesk.com 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 <brent.mcpher...@autodesk.com<mailto:brent.mcpher...@autodesk.com>> 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: softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com> [mailto:softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>] On Behalf Of Steven Caron Sent: 31 July 2012 20:59 To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com> 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 <car...@gmail.com<mailto:car...@gmail.com><mailto:car...@gmail.com<mailto:car...@gmail.com>>> 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 <brent.mcpher...@autodesk.com<mailto:brent.mcpher...@autodesk.com><mailto:brent.mcpher...@autodesk.com<mailto:brent.mcpher...@autodesk.com>>> 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.
<<attachment: winmail.dat>>
