picking problems

Engines, Libraries and Tools Xith3D Forums
#1

Hi all,

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 )

#2

Hi, Andre

Welcome to the forum… finally :wink:

Oh. Thanks. getRootBranchGroup() existed only a few days. I’ll change that in XIN.

I’ll check that. Have you checked the tests in org.xith3d.test.picking?

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

You’re welcome :slight_smile:

Marvin

#3

I checked the PickingLibraryTest and it works fine :slight_smile:

#4

Hi apohlmann ! And welcome to Xith3D and its board.

I see Marvin beat me one this one so I don’t have anything to answer to, just the usual question, are you planning to achieve something special with Xith ?

#5

Hi Amos,

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 ;D …

#6

Picking works now.

I replaced PickResult pr = PickingLibrary.pickNearest(env.getRootGroup(), env.getCanvas(), pickX,pickY); by
List pr = PickingLibrary.pickAll(env.getRootGroup(), env.getCanvas(), pickX, pickY); from the picking-test.
And I replaced pr.getShape().getName() by
int i = 0;
for (PickResult pr: results)
{
System.out.println(" Hit (" + i++ + “): Shape3D: “” + pr.getShape().getName() + “”, distance=” + pr.getMedialDistance() + " position=" + pr.getPos());
}
that’s from the picking-test too… 8)

But why is the example from xin not working?

#7

Marvin will fix that soon hopefully.

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).

#8

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).

Marvin

#9

Yoicks!!! This surprised me…

[quote]When you’re using (Ext)Xith3DEnvironment all Nodes are pickable by default. So this line is not necessary.
[/quote]
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.

#10

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.
[/quote]
Hmm, yes. This makes sense. I added a new property to Xith3DEnvironment (also available in ExtXith3DEnvironment, too, of course). Call


(Ext)Xith3DEnvironment.setDefaultPickableEnabled( false );

before you create your Xith3DEnvironment instance.

Marvin.

#11

The example from XIN worked for me. Anyway, I modified the XIN picking cheapter to fit the new implementation of GLSelect picking. Please have a look.

Marvin

#12

Actually I am getting some problems… but the day isn’t over yet :wink:

#13

What kind of problems? If they’re deadock related, then I’m also getting these ones in BSPLoaderTest, but not in other tests.

Are you still using PickingLibrary?

When these synchronization/deadlock problems are gone, GLSelect picking is better than PickingLibrary picking. It should be faster and doesn’t need to be synchronized from outside or scheduled.

Marvin

#14

O.K. I tested the code from chapter 9a.
Everything seems to be all right but I got an Exception in thread “AWT-EventQueue-0” java.lang.NullPointerException. :-\

Then I tested the code from 9b… the Exception is gone but I always “Pick nothing” …

Maybe I am doing something wrong? (Maybe lol… I am sure …)
It’s a shame that I am not that deep into this material to solve the problem :’(

#15

Could you send me your code?

Marvin

#16

Hi,

Is there a way to get the Pick Ray object like in the old version. Also can someone provide a lilttle details on inner workings of different picking methods in the current version.

Thanks.

#17

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.

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.

Marvin

#18

[quote]if a whole group is not picked
[/quote]
Does that mean that the groups have correct bounds to check againts the ray intersection?

Does the software picking method (Picking Library) intersects down to Shape’s polygons?

Thanks

#19

No, they don’t have correct bounds. But it is guaranteed, that all the shapes in a groupd are inside these bounds.

No, it doesn’t. A Shape3D is an “atom” for this algorithm.

Do you need the information, which polygon was picked?

Marvin

#20

[quote]Do you need the information, which polygon was picked?
[/quote]
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.

Thanks.