The pickbuffer doesn't have the information but intenally we could look it up on the mesh more efficiently than you can using either the geometry accessor or polygon arrays in the SDK. (both of which don't seem to be very efficient) -- Brent
From: [email protected] [mailto:[email protected]] On Behalf Of Steven Caron Sent: 01 August 2012 18:18 To: [email protected] Subject: Re: SDK : caching the tool context pick buffer 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 <[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Steven Caron Sent: 31 July 2012 21:39 To: [email protected]<mailto:[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]<mailto:[email protected]><mailto:[email protected]<mailto:[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]><mailto:[email protected]<mailto:[email protected]>> [mailto:[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>] On Behalf Of Steven Caron Sent: 31 July 2012 20:59 To: [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[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]><mailto:[email protected]<mailto:[email protected]>><mailto:[email protected]<mailto:[email protected]><mailto:[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]><mailto:[email protected]<mailto:[email protected]>><mailto:[email protected]<mailto:[email protected]><mailto:[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.
<<attachment: winmail.dat>>
