To eliminate the sky from picking you don’t place it in a pickable node.
To have the sky reflect in simple water you have to have sky in the same node as the reflection scene and it cant be rootNode.
To have the sky reflect in WaterFilter, the reflection scene just needs to be a child node of the node the sky is in.
This means sky in rootNode can not work with terrain placed in a pickables node with respect to SimpleWater.
Shouldn’t SimpleWater also work like WaterFilter? or at a minimum allow SimpleWater to be placed in a separate node of its own rather than having the relection scene and sky be in the same node?
The skybox is a peculiar geometry.
you can move it away and never think about it, it will still be rendered properly.
So for exemple do something like this.
sky.setLocalTranslation(1000,1000,1000);
It should prevent you from accidentally picking it.
I guess we could have a Pick hint on each geom that would define what’s pickable and what is not…
When you perform the picking, does CollisionResults not collect all intersections?
So it should be possible to use a regular picking on the root node and filter out the sky from the results instead of using the closest result directly.
@nehon for the picking flag: as an alternative, could it be possible in the future to add a spatial to multiple nodes so that they have multiple parents? Apart from simplifications of the picking and water reflection scenes would this allow many cool effects. Like a “vampire” that is visible normally in the scene but has no reflection in a mirror.
This would be a COMPLETE REWRITE of JME. Spatials have only one parent. Nearly EVERYTHING relies on this. It simplifies a ton of stuff. (For one thing, we don’t have to create a separate render graph on the fly.)
Well, there could be 11362473 reasons that the closest is not really the one you want.
What is is that you are picking? Lemur’s built-in picking support wouldn’t pick the sky box because you wouldn’t have added a listener to it. It actually looks at what’s interesected and sees if it has something that denotes you are interested… ie: the listener.
A similar strategy is usually for the best. Determine if what you’ve picked is what you really want by looking at user data on the object or whether it has a control or not. Then you won’t break with every new scene reorganization.
This is 3rd person-no gui-using mouse pointer for navigation that I’m setting up to test/study the AI stuff. Afterwards I want to write a test app for the wiki based on this.
For the wiki I am trying to keep inline with the other tutorials that use closet object so as to avoid confusion. The sky was getting in the way for clicks about 15 units or so away from the camera. I didn’t know it could be moved so far away and still work.
I was under the illusion that closest was what you want. I am trying to imagine when I wouldn’t want closest but cant seem to see any. Can you give me an example when I would not want closest?
Okay. It can be achieved in other ways too. One can share the meshes and materials among multiple geometries and use controls to sync the transformation.
Normally it wouldn’t but maybe you just want to spawn a simple particle in a child of the node you are picking agains (easy position syncing) and you don’t really worry about the performance impact in that case.
Maybe not the best example…
Well there are dozens of application to ray casting. Picking is just one of them. For picking…the closest seems to be the most relevant (and here again depends on what you want to do).
Actually i copied the CollideWith Code to make it work on lists of spatials which I think is even more useful than a pick hint especially when you have different sets of pickable things.
Btw: if a node had two parents, issues start with the question on what Worldtransform to pick
No. As said, it requires a complete redesign of the engine. You basically stop keeping world transforms and can never ask for a world transform for a spatial. You can only ever ask for a world transform for a “PATH” of spatials.
There are other scene graphs that do this… they are a pain in the ass in totally different ways. So, yeah, you can share subgraphs in those 0.00001% of cases that you want to… but then you pay for it in other ways every minute you use the API.
Whoever writes JME4 can deal with that if they want.