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