next »

[horati]

I have a need to pick Links to SharedGroups.  The class hierarchy is

• Node
   
  • Leaf
         
    • Link
    • Shape3D
    • other stuff
       
  • GroupNode
         
    • Group
               
      • TransformGroup
      • SharedGroup
      • other stuff
             
       

Since any Leaf could potentially be picked (although I cannot see how Sound, Behavior, etc. could actually happen), does it make sense to move the getPickHost method up to Leaf?  It almost seems as if a Pickable interface would be nice; however, that doesn't really seem to make sense since all Nodes may be isPickable().

['n ddrylliog]

In the meanwhile, use NodeMap

[Marvin Fröhlich]

I will optimize the PickingLibrary for GC-friendliness now. And while I do it, I will add the functionality to pick Links.

I guess you mean, that the PickHost thing should be moved up to Node, but not to Leaf. I will see, if I can do it. Maybe there must be a new interface called PickHost, that NodeGroup and Link have to implement. I believe, this is the way to go.

Marvin

[horati]

GroupNode contains setPickHost( boolean ).

Shape3D contains getPickHost()

I think all I need is to move (or you to move) getPickHost() to Leaf.  If I understand correctly, the various picking mechanisms will always place a Leaf in the PickResult.  We are then supposed to ask the Leaf for its PickHost.  Am I missing something?

[Marvin Fröhlich]

GroupNode contains setPickHost( boolean ).

Shape3D contains getPickHost()

I think all I need is to move (or you to move) getPickHost() to Leaf.  If I understand correctly, the various picking mechanisms will always place a Leaf in the PickResult.  We are then supposed to ask the Leaf for its PickHost.  Am I missing something?

Oh, I misunderstood you. Moving the getPickHost() method to Leaf is ok, principally. But I will do it, when it will actually have an effect. So far only Shape3D instances are picked. And therefore the getPickHost() method woun't be usable in any way in Leaf for now. Just wait unitl tomorrw.

Marvin

[horati]

Sweet, thanks.  My program gains substantial benefit by using Links.  This way, I can keep focusing on SWT threading :-)

[Marvin Fröhlich]

Sweet, thanks.  My program gains substantial benefit by using Links.  This way, I can keep focusing on SWT threading :-)

Yeah, cool.

[Marvin Fröhlich]

Links can now be PickHosts as well. And The PickingLibrary is fully capable of picking Links/SharedGroups. Though it is fully untested. I will do some tests tomorrow. It's late now.

Marvin

[Marvin Fröhlich]

Links can now be PickHosts as well. And The PickingLibrary is fully capable of picking Links/SharedGroups. Though it is fully untested. I will do some tests tomorrow. It's late now.

I wasn't working at all . Now it is .

To pick on a linked shape with PickingLibrary (or of course PickScheduler from Xith3DEnvironment), you just have to do the following:

Code:

Link link = new Link( new SharedGroup( myPickedShape ) );
link.setPickHost( true );

Then the PickResult instance will return the Link from the getPckHost() method. Note, that the getPickHost() method of the Leaf class only returns a GroupNode. It is simply not possible to handle it that way. But getting the Link from the PickResult just works great.

To get the Link as a pick-host from the PickResult, no GroupNode inside the Link must be defined as pick-host!

All Leaf implementations are now pickable with PickingLibrary. But you have to be aware, that other Leaf types (like Sound) need proper Bounds to be set (e.g a new BoundingSphere instance). Otherwise it won't be pickable. And of course a Link (which is a Leaf extension) is not handled like a Leaf in the picking algorithm, but more like a Group.

Enjoy

Marvin

[horati]

Looks great.  Exactly what I needed.  Thanks so much!!

[Marvin Fröhlich]

Looks great.  Exactly what I needed.  Thanks so much!!

You're welcome