I have a scene full of Geometries. I use the mouse to pick some of them. I have no problems checking which objects were picked with a ray but now I am faced with the next question: How can I determine which object was picked - which object this picked geometry belongs to?
I seems to me it is mostly a question of good data structure and perhaps the solution becomes obvious to me also, when you advise me on how I could better organize my game.
Currently I create a number of Java objects in the GameState constructor and one of the object fields is the jME Spatial. After creating these objects, I basically do rootNode.attachChild(object.getSpatial()). However when I execute MousePick in the update method, I of-course get the Spatial as a result. The question is - how to get the object itself or how to organize my game better for not having this problem? I would hate to iterate through anything just for identifying them as it seems terribly inefficient.
Thank you kindly
Edit: I also read somewhere that identifying a Geometry by its name is not good form… or is inefficient… or both. So I am not happy about that either. Or would it still be good practice to identify the Object by the Geometry unique Id?
One possibility would be to have a HashMap of all GameObjects.
In this map you would have references to the Spatial the GameObject it belongs to.
This way, you could easily get the GameObject which the Spatial belongs to.
But i'm sure there are better structures to solve this kind of problem, without having to manage an additional HashMap.
Thank you for answering, Core-Dump. I am very interested of how the guys who are involved in bigger projects have done this… so I hope no-one is holding back a perfectly good reply just because the problem may seem trivial 
You could use the (inherited) name field of spatial using some naming convention to map a spatial to an object of Yours.
edit:
ah just read Your edit:
Edit: I also read somewhere that identifying a Geometry by its name is not good form.. or is inefficient.. or both. So I am not happy about that either. Or would it still be good practice to identify the Object by the Geometry unique Id?
yes, it's not good form mostly. Performance wise i don't believe this to be a show stopper.
The other way would be to use inheritance, so that every GameObject is derived from Spatial.
So when you pick a geometry, you could cast it to the GameObject.
I guess you could say that a GameObject is a Spatial or a GameObject has a Spatial, so i think both methods are valid from a OO point of view.
Thank you both for ideas. My initial solution was using identical names and getting the spatial from a HashMap. I now modified the code to use the Spatial itself as the key for the HashMap and it is working very well. I think it will be suitable for this small test-project I am doing (Will post code soon - it is a simple AStar in StandardGame demonstration program)
In my main project I will seriously consider using inheritance - will see how it will work out.
Thanks again
there s a couple of ways doing this.
it all depends on the relationships between ur game objects. if they have some sort of heirarchical structure, inhheritance would be the best idea. simply store an enum field in the super class (Clickable or something).
or u can use instanceof to do a run time type checking. consider it is used in the underlying java byte code, it is probably at least as fast as enum comparasion.
instanceof? I would have never dared use it without such a direct advice. I have always been told and read on forums that instanceof is slow and certainly not a good way of identifying objects. But I take your word for it.
Anyways inheritance seems like a good way to go. I still have to decide on my game object relationships… so far I have jut created various testcases. Till now I have always worked with Java 2 so I am not very familiar with Enums and Generics etc, but I guess I have to read up on them at some point. Oh yes… Futures too
Perhaps I should do another testcase comparing enums and instanceof performance - both as learning experience and also because 'seeing is believing'.
If you go for inheritance, I'd recommend just extending Spatial so it has extra methods for getting hold of your Domain object. Not actually making your Domain object a subclass.
For clarity (ignore poor naming and any syntactic mistakes! ;)), use:
public MySpatial extends Spatial {
public DomainObject getMyDomainObject() {
return domainObject;
}
}
Instead of:
public DomainObject extends Spatial {
domain methods and logic...
}
Yeah, thats close to what I would do also. Instead of using a DomainObject though, you could just cast to the desired object and manipulate it directly…
(Maybe thats what neakor already said though…)
i simply ask for its parent, the results parent, and so on, until i get something which is an instance of the baseclass of all my objects in the game.