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