i didn't realize the pickbuffer in ogl could provide that or maybe it was a convenience function the sdk would provide over the standard ogl pick buffer?
regardless, i will bring this up as a suggestion. s On Wed, Aug 1, 2012 at 1:32 AM, Brent McPherson < brent.mcpher...@autodesk.com> wrote: > 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. > > >
