I am new here (and finaly here ... long story ^^).I used to test the code written in xin "chapter 9a picking" and i have some problems.The first problem: env.getRootBranchGroup() seems to be wrong (?!)... env offers getBranchGroup() is this correct?and the second: all seems to be correct but I am not able to pick the rotating cube! -> "You just picked nothing!" I added cube.setPickable(true) but it is still the same

PS: Thanks to Marvin for support via e-mail (i wasn't able to login here )

I am working on my project at university. It's a technology research about tools, engines and more.Anything you can use to build a simulator for mobile robotics.And so I have to test some of these things...There are a lot of projects that offer useful things but not all are comfortable enough.Xith seems to be a bit further than J3D.

And at the End I hope to implement some of my ideas with Xith....To many ideas and not enough time ....

I wish you good luck for your project, if you have any problem/comment/idea/suggestion/rant/whatever, don't hesitate to post.. I just remember how sad that Niwak said (a year ago) the core code was ugly while it was being refactored, and that it lacked a particle system whereas JavaCoolDude did one long ago.. and so on.. There are LOTS that have been done for Xith3D, some old work just asks for being picked and adapted a little bit. (Whenever I need particle system in my game, I'll *finally* dig JCD's work).

I'll do. I anyway need to dig into GLSelect picking code again. After Yuri last fixed it to support picking in parallel projection, the picking in BSPTest runs into a deadlock. I'll look for it the next days (maybe tonight, don't know).

When you're using (Ext)Xith3DEnvironment all Nodes are pickable by default. So this line is not necessary.

I have been managing the pickability of objects myself, to isolate scene items that can be interacted with, I did not expect everything to be set as pickable. Can an option to control this behavior be added. I would prefer to control this myself.

When you're using (Ext)Xith3DEnvironment all Nodes are pickable by default. So this line is not necessary.

I have been managing the pickability of objects myself, to isolate scene items that can be interacted with, I did not expect everything to be set as pickable. Can an option to control this behavior be added. I would prefer to control this myself.

Hmm, yes. This makes sense. I added a new property to Xith3DEnvironment (also available in ExtXith3DEnvironment, too, of course). Call

In the old version it wasn't possible to get a pick ray object. You could only call the picking method on the View class (if I remember right), which filled two tuples, one for the origin and one for the direction.

Now the way to go is create a new instance of the class PickRay. It will then hold two tuple instances with the values like in the old version. Please also check all the constructors and methods of the PickRay class. They might be useful.

Also can someone provide a lilttle details on inner workings of different picking methods in the current version.

Well, the picking initiated by canvas.pick*() uses GLSelect to pick the scene. In large scenes this is too slow. PickingLibrary uses pure software picking, which traverses the scenegraph just as far as it is possible (if a whole group is not picked, no shape can be and the group is not further traversed). This picking method needs to be synchronized with the render thread. ExtXith3DEnvironment (together with ExtRenderLoop) does it for you. So you only need to use the pick*() methods of the ExtXith3DEnvironment. Please read XIN for more details.

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

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.

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?

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?

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.

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

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

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

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org