PickingLibrary extension

[Qudus]

hi

What do you think about a modification of the PickingLibrary class in which the pick methods get renamed to pickNearest and they make use of new methods called pickAll? These new pickAll methods would return a Vector with all picked Shape3Ds encapsulated by a PickResult. This vector would be ordered with item zero being the nearest one. pickNearest would then easily return the zero item of this Vector.

At this opportunity, I want so additionally suggest once again to add a new flag to the Node class indicating that this Node is to be ignored by a picking done by the PickingLibrary. You could use the setPickable flag and invert the boolean parameter. But this is really dirty I think.

How do you like this idea?

[eMKa]

@Qudus

You could use the setPickable flag and invert the boolean parameter. But this is really dirty I think.

Why then ?

[arne]

@Qudus

hi

What do you think about a modification of the PickingLibrary class in which the pick methods get renamed to pickNearest and they make use of new methods called pickAll? These new pickAll methods would return a Vector with all picked Shape3Ds encapsulated by a PickResult. This vector would be ordered with item zero being the nearest one. pickNearest would then easily return the zero item of this Vector.

pickNearest would then be a waste of resources. (That’s probably why my picking code is so much faster than the other one, because it doesn’t look any closer at the nodes further away than an already found Result)

[eMKa]

@arne

@Qudus

hi

What do you think about a modification of the PickingLibrary class in which the pick methods get renamed to pickNearest and they make use of new methods called pickAll? These new pickAll methods would return a Vector with all picked Shape3Ds encapsulated by a PickResult. This vector would be ordered with item zero being the nearest one. pickNearest would then easily return the zero item of this Vector.

pickNearest would then be a waste of resources. (That’s probably why my picking code is so much faster than the other one, because it doesn’t look any closer at the nodes further away than an already found Result)

pickNearest() shouldn’t call pickAll()

[Qudus]

@arne

pickNearest would then be a waste of resources. (That’s probably why my picking code is so much faster than the other one, because it doesn’t look any closer at the nodes further away than an already found Result)

[quote="<MagicSpark.org [ BlueSky ]>,post:4,topic:27676"]
pickNearest() shouldn’t call pickAll()
[/quote]
Ok. But do you agree in the need of a pickAll method which returns a Vector of all picked Shapes?

[eMKa]

@Qudus

But do you agree in the need of a pickAll method which returns a Vector of all picked Shapes?

Yes but will it be any faster than the traditional picking method ?

[Qudus]

[quote="<MagicSpark.org [ BlueSky ]>,post:6,topic:27676"]

@Qudus

But do you agree in the need of a pickAll method which returns a Vector of all picked Shapes?

Yes but will it be any faster than the traditional picking method ?
[/quote]
indeed!

[eMKa]

@Qudus

[quote="<MagicSpark.org [ BlueSky ]>,post:6,topic:27676"]

@Qudus

But do you agree in the need of a pickAll method which returns a Vector of all picked Shapes?

Yes but will it be any faster than the traditional picking method ?

indeed!
[/quote]
Then go for it !