picking problems

[Qudus]

@Zer_Gut_Shnitzel

No, but I need the ray to precisely pick the shape based on the geometry rather then bounds.

Isn’t PickRay everything you need? If not, what do you need further?

@Zer_Gut_Shnitzel

We worked pretty much like this. Project the ray into our main 3D space (which is different than Xith’s world space) then use space partitions and bounds to check for the ray intersection in our core data graph use all these results to set the branches pickable in the Xith scene graph and then do the view.pick that was based on a slow but precise (polygon based) GL_SELECT I assume. Since mostly one branch containing shapes would be marked pickable the view.pick was actually fast enough and precise. I am trying to figure out if we can speed up the process of picking by using some of the new methods you created.

Yeah, maybe you can use one of the pick methods taking a group to pick solely in it. Please keep in mind, that the Canvas3D.pick*() methods don’t need to be synchoronized anymore (and shouldn’t be). They are synchronized internally. the current VirtualUniverse instance is used as the mutex by the render thread, which is used by the pick methods, too. So double synchronization could become very slow or cause a deadlock.

This view.pick method was exactly, what canvas.pick methods are now (GL_SELECT picking).

Do you consider your picking algorithm to be worth being put into the xith toolkit?

Marvin

[Zer_Gut_Shnitzel]

[quote]Isn’t PickRay everything you need? If not, what do you need further?
[/quote]
It should be, I am gonna do some tests to see how it compares with our old system…

[quote]Do you consider your picking algorithm to be worth being put into the xith toolkit?
[/quote]
We tried building this using Xith volumes initialy but we could not figure out how Xith’s bounds work, so we built our own system of groups/bounds and TransformGroups. I guess our picking system is way to coupled with our core data structure at this point, moving it back to Xith would require the bounding volumes / space partitioning to work properly and update dinamically.

Cheers

[apohlmann]

Hi again,

I tested the PickingLibrary, works fine so far. Than I used to create an example for picking under J3D, just to compare it with xith…
and now I’ve got a question: why is it necessary to set the transformgroup and the element (e.g a cube) pickable = true ?? OK I know, setting it to fals means the cube is not pickable… but what is the reason for that? In J3D it seems that everything is pickable at the beginnig. Something about performance?
I don’t want to criticize someone… I just want to know 8)

[eMKa]

@apohlmann

Something about performance?

All right, doc. Less nodes to test, thus the algorithm runs faster.

@apohlmann

I don’t want to criticize someone… I just want to know 8)

You’re welcome.

[Qudus]

@apohlmann

I tested the PickingLibrary, works fine so far. Than I used to create an example for picking under J3D, just to compare it with xith…
and now I’ve got a question: why is it necessary to set the transformgroup and the element (e.g a cube) pickable = true ?? OK I know, setting it to fals means the cube is not pickable… but what is the reason for that? In J3D it seems that everything is pickable at the beginnig. Something about performance?
I don’t want to criticize someone… I just want to know 8)

You can modify the default xith Xith3DDefaults class. And when you use Xith3DEnvironment, the default is true.

Marvin