[vtk-developers] Cleanup of crufty code in vtkPicker
Will Schroeder
will.schroeder at kitware.com
Tue Jan 5 12:32:35 EST 2010
Okay this changes things I understand now. I have no remaining concerns.
On Tue, Jan 5, 2010 at 12:12 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> Hi Will,
>
> I can understand that, but right now going through the pick list is
> really the only valid way of doing that anyway, because a PickEvent is
> not generated for every prop that goes into the pick list. Please
> bear with me while I explain what the current code for vtkPicker (and
> vtkAreaPicker) does:
>
> For each "hit" prop, that prop is added to the pick list. If and only
> if that prop is closer to the camera than any previously hit prop,
> prop->Pick() is called and a PickEvent is generated.
>
> So, in my opinion, it's better for only one PickEvent to be generated
> (for the closest prop), rather than to have PickEvent generated for
> just "some" of the props that go into the pick list.
>
> The other solution, ensuring that a PickEvent is generated for every
> prop that goes into the PickList, would require a fairly radical
> redesign of vtkPicker and its subclasses because this->CellId,
> this->Mapper, etc. are all stored only if the current prop is the
> closest to the camera. That is why PickEvent is currently only
> generated if the current prop is the closest to the camera.
>
> David
>
>
> On Tue, Jan 5, 2010 at 9:26 AM, Will Schroeder
> <will.schroeder at kitware.com> wrote:
> > David-
> >
> > I believe that the idea behind invoking the PickEvent multiple times was
> so
> > that if you could perform multiple "operations" on each prop picked, for
> > example placing a bounding box, or changing the color of each picked
> prop,
> > etc. I realize that there is an alternative way by processing the pick
> list
> > after the end pick event is emitted. I guess I don't understand why you
> want
> > to change behavior, is there a compelling reason? Performance? I agree
> the
> > risk is small, but I'd rather not aggravate anybody if we can help it.
> >
> > Will
> >
> > On Mon, Jan 4, 2010 at 3:13 PM, David Gobbi <david.gobbi at gmail.com>
> wrote:
> >>
> >> Hi All,
> >>
> >> I'd like to do a little clean-up of vtkPicker so that the code and the
> >> header documentation are in better agreement with each other. There
> >> is a chance that there could be some backwards compatibility problems,
> >> but I think that the risk is very small. The interface of the class
> >> will not be changed.
> >>
> >> So, here is the main adjustment:
> >>
> >> Right now, the picker might invoke PickEvent for more than one prop
> >> during the pick, and I don't think that this is correct behavior. I
> >> want to change the code so that the PickEvent is only invoked for the
> >> front-most prop under the cursor. Any objections? This change will
> >> not require modification to PointPicker or CellPicker, and should not
> >> require modification to any third-party subclasses, either.
> >>
> >> David
> >> _______________________________________________
> >> Powered by www.kitware.com
> >>
> >> Visit other Kitware open-source projects at
> >> http://www.kitware.com/opensource/opensource.html
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> http://www.vtk.org/mailman/listinfo/vtk-developers
> >>
> >
> >
> >
> > --
> > William J. Schroeder, PhD
> > Kitware, Inc.
> > 28 Corporate Drive
> > Clifton Park, NY 12065
> > will.schroeder at kitware.com
> > http://www.kitware.com
> > (518) 881-4902
> >
>
--
William J. Schroeder, PhD
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
will.schroeder at kitware.com
http://www.kitware.com
(518) 881-4902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20100105/12acaf55/attachment.html>
More information about the vtk-developers
mailing list