I was thinking about the best way of doing collision detection in jme. The best way I could come up with is have the root node intersect itself. The problem with this is that you can’t tell what entity or class the spatial returned has to do with without having a slow map.
One possibility to fix this problem that I could come up with is add a HashMap into spatial. This map could be null unless used making it take up almost no room. The hash map can fix many other problems that are in jme including the problem with the cloth test. Anther advantage of adding the HashMap is that it would allow custom properties passed to the .jme format.
What information would this map contain? You mention having the spatial know what object it’s related to. Since objects can change ownership during the game you’ll need some accessors for that particular value as well. I suppose you could also put in other named properties and that could be useful although if I was going to have variable properties for an object I would be putting them in my game object and not in my spatial.
You would be able to change the value. Let say you have a property in the hash mat called
Hmm, I’ve rethought the question from a more general viewpoint. I think a developer having the ability to add a property to a Spatial to support the type of framework they want is very important. My current system is designed to work around the fact that I don’t want to make non-standard changes to my local copy of the jME library. By having the hash I can implement any number of special systems and still function with the standard jar. How do I change my vote?
Why is intersecting the root node with itself better than trying to intersect the moving object with what it should hit? This is actually a faster solution as well because there are many things that you know cannot intersect the “moving” object (like the sun for instance), so you don’t test it.
In theory if the node is sorted by bsp or portals then intersecting the root node with itself would be faster. Intersection is just one place where this would be helpful, although it is probably the biggest one.
Hey Badmi, just wanted to let you know we are actually exploring using a properties list, hashmap or some such structure in Spatial for core purposes (and make it available for other purposes at the same time,) so your request is possible, although we’re not specifically targetting it for collision at this time.
Also, how would your proposal fix the cloth test?
Umm…wouldn’t this be at a distadvantage to BSPNodes? Because BSP nodes need to be as light as possible and introducing a hashmap which could potentially fill up alot of space just use alot of memory?
Or would this properties list only be available to children? And thus only essential information be stored in there? Information not settable by users…
Im curious! 
DP
The hash map could be null unless being used thus taking up very little room. It would defeat the purposes to not let the users set it.
well, then a supreme confusion is going to arrise if the user is going to be able to set it.
* Oh hold on, i have an hashmap in spatial. I’l just set all my health/damage parameters/particle systems that can be fired/UIProgressbar for my health inside that properties! Jme is great, Jme is wonderful. Jme makes everything sooo easy!
Hehe, me being sarcastic there…This will only bloat spatial, making everything less memory effecient. And an extention of Node could provide the same. Or even better, a solid entity class!
DP
I think the entity class is a good idea. Just my humble opinion.
There are some times when information must be stored inside the spatial such as collision detection. The main use for this HashMap would bee telling the spatial what entry owns it. I do not think that jme should stop putting in advance features just because they could be misused.
what entry? whats an entry? do you mean entity? If so, this can be solved in many other ways. Look how i solved it in my GameSystem.
Can you please explain to me more about collision system. I dont see the reletionship between a properties in spatial and colliding with itself?
DP
Let say I have a root node that has a portal system and 1000 objects. I want to see what objects have collided. If I use your method I will have to do 1000000 tests. Any game doing this would not be in real time. If I have the node collided itself because the node would be sorted by portals I would have much less tests. Now when I get my list of results I need to know what entity the spatials represent. How should I fined out? The hash map inside the spatials would let me know.
forget about entities for a minute, because that has already been solved in a different way.
Tell me how adding a properties map inside spatial can solve collision detection with the node itself. Besides, i thought it can already do that?
DP
"DarkProphet" wrote:
Tell me how adding a properties map inside spatial can solve collision detection with the node itself. Besides, i thought it can already do that?
It can. The HashMap would be used to make the response meaningful.
badmi, you really have to start to explain yourself better…
meaningful responses?! I really dont see the connection. So what your saying is if obj1 collides with obj2, the hashmap can store some type of response to that? In terms of what? a controller? or some god like angelic code that will bring a soul into that spatial and say hey, you should be doing this…
Badmi, please explain yourself better. Spatial is a very important and is at the core of jme, so unless you can explain yourself better to me and give me a concrete example of when this could be very useful and can only be used in that way (i.e. external mapping is seriously not an option), then im afraid im against this proposal for external use of any hashmap in the spatial class.
DP
What I mean is that once I learn that spatal 1 collides with spatal2 I need to know what entities own the Spatial to intact a response. For example if I have each spatial owned by an entity, and I know that spatial 1 collided with spatial 2 I need to know what entity to change. This is where the HashMap in spatial comes it. I can add a key to the HashMap called
right ok.
Let me clarify something for you. If you are going to be using Entities, you will never touch spatials. Because Entity is the highest object in the tree and should encompass everything. From graphics to sound, to physics to ai. Collision detection also happens on the Entity level.
Entity entity1 = playerEntity;
Entity entity2 = alienEntity;
CollisionResults cs = new CollisionResults();
if (entity1.collides(entity2, cs)) {
// hey, i know both entities! do something!
}
The method "collides" will do all the dirty work for colliding the spatials contained in the entities, producing either a boolean value indicating whether they have. Or providing a more detailed account using collision results.
Take it as a rule of thumb. Low level objects should never ever know about higher level objects. Its that simple. You should never store an entity in spatial, but you should store a spatial in entity.
Badmi, please see my game state system. It solves all of the things you have mentioned here. I dont want you to use it, but I came across the same problem as you have, and i managed to solve it without chaning ANYTHING to jme.
DP
I dont want you to use it
We can't use your entity class? That's okay since I wanted to make my own to learn but just wanted to clarify. [/code]