Hey all,
So I’ve been googling and digging through documentation for a while now, and can’t seem to find an answer to my question:
Is there a way to get a geometry to ignore picking? Sometimes I want certain geometries to be pickable, and other times I don’t. I assumed there would be something like:
geometry.setPickable(false)
But alas no.
You can easily do something like that :
“geometry.setUserData(“pickable”, false)”.
It will NOT do anything itself, but then, when you iterate other results you can do something like :
[java]Boolean isPickable = geom.getUserData(“pickable”);
if ( isPickable != null && false == isPickable.booleanValue() )
{
continue;
}
//do things
[/java]
Or you just attach it to another node that you don’t pick, as explained in the “scenegraph for dummies” doc.
A node can only have one parent. I never get this advice, to have a pickable tree and an unpickable tree, cause you may have a “pickable” torso (or trunk for a tree), an unpickable arm (bough) and a pickable hand/leaf.
Yeah, i would agree with the “pickable/unpickable” thing if it was possible to have many trees (i.e. if a spatial was able to have more than one parent).
And this kind of situation (where an unpickable thing is attached to a picable one) happens. For exemple, i like to attach bullet holes to models (so, when you move the model the bullet hole doesn’t stay in the air) but i don’t want to consider that a bullet hole on something is an obstacle to pick this thing.
It would be nice to have a way to pass a filter (an interface) to the collideWith method. Yeah, i can filter after, but i think it would be faster (and easier to use) to have this method. And pretty “generic” as it’s up to the user to decide if a geometry is a valid collision or not (with userDatas(the ispickable), or name, or attached controllers or team or whatever).
If you want to pick only terrain or certain objects like e.g. houses then separation with nodes makes very much sense to me. When picking an arm in a model geometry picking doesn’t make sense to me at all, maybe with a custom collision type if at all. Bullet holes should also definitely not be separate objects or collidable, basically the perfect example for a completely separate node. You can define picking behavior of geometries by replacing their picking algorithms easily btw.
i don’t get you. If i put my bullet holes on a separate node, they will not move with the “damaged” model. Imagine a car for exemple. I can put a bullet in the car, and i want to keep this hole at the exact same place, no matter how the car moves. It’s easily done by just attaching the bullet hole to the car, but then the node is in the collidable tree.
Yeah, for bullet holes on non-moving items you can put then in a separate node, but not when you can shoot on everything, including roling balls.
But i don’t use the scenegraph collisions now, anyway, as i have a client-server game and models on the server (mainly used for collision shapes) could (should) be different than models client side.
Attaching a scenegraph object per bullet hole isn’t a good idea in any case. If you want to make dents in a car use texture splatting, if you want them in the environment make a few meshes per area and use them like particles, moving single quads within that mesh. You wouldn’t shoot at other objects cause they would not be on the immobile node you pick on… You basically implied that too by calling it “immobile node”, then talking about a rolling ball…
Thanks for all the replies, sorry to start an argument 
for simplicity’s sake I guess I’ll go with setUserData
@shaunsupra said: Thanks for all the replies, sorry to start an argument :P for simplicity's sake I guess I'll go with setUserData
I’d listen to @normen 's last advice. Either texture splatting or decals.
The idea of a flag for pickable/non-pickable works fine in a a setting where there are minimal objects in the “pickables” node, however, in a complex scene with 100’s of bullet holes being attached as objects, things are gonna get ugly fast =(
Hehe, I never said anything about bullet holes I’m working on something voxel based (original, I know) and sometimes need to be able to pick through a solid wall of blocks. In my little tests, setUserData is working fine however there is a noticeable performance hit. Saying that, my test code is kinda … chaotic to say the least, and in no way optimized. Of course, I’m still grateful for all the advice, I’ll be back if it falls apart 
If it’s a block world then the JME picking is generating and storing a ton of data that you could pretty trivially bypass by doing collisions directly against your voxel data. Presuming a certain level of math ability.
My maths is ok, isn’t the data just a list of hit nodes?
@shaunsupra said: My maths is ok, isn't the data just a list of hit nodes?
The mesh is turned into data that is used to do the picking. As I recall, block world style data structures translate very poorly into this sort of BVH hierarchy but I could be remembering wrong.
At any rate, doing picking directly in the source data (world grid) is easy and fast.
Eh, all of this is somewhat for nought now anyway. Just realized my “create the world from separate boxes” approach is fundamentally flawed, so I have to rewrite (and rethink) everything now.
… it seems we should introduce some kind of Clippy for the jME SDK:
“Hey, it looks like you try making a box world by stacking boxes. May I help you doing it correctly?”
@normen said: ... it seems we should introduce some kind of Clippy for the jME SDK:“Hey, it looks like you try making a box world by stacking boxes. May I help you doing it correctly?”
That’d be great 
@shaunsupra said: Eh, all of this is somewhat for nought now anyway. Just realized my "create the world from separate boxes" approach is fundamentally flawed, so I have to rewrite (and rethink) everything now.
I think there are approximately 5,462,357 different threads on the forum on this subject. 
There is even a block world plugin or library that someone made.
Recognize, though: counterintuitively, block worlds are HARDER to make than regular games. The graphics are simpler but you have do nearly everything from scratch or deal with a multitude of block specific issues.
i don’t think so. Block worlds dynamically generated and editable (minecraft like) are harder than static and unmodifiable world. But if you try to create a dynamically generated and “digable” world without cubes … well, good luck.