next »

[Lobotomia]

Hi,
i'm working on shoot of my FPS Game,
i think that is a good idea to add an attribute to identify if a node have an owner.
I explain this, in my game, when i shoot to a Model (but also to a Cube or a Sphere or other) i want to decrease health of Enemy, then how can i do this?
If there is an owner (Object) is possible to cast this value and do what a developer want.

Is possible to add this?

[Marvin Fröhlich]

You can always apply a user object to any scenegraph node through the setUserObject() method.

Marvin

[qbproger]

I've been meaning to comment on this...

Right now every SceneGraphObject has its own UserObject HashMap.  This seems heavy on memory, as each SceneGraphObject must allocate an extra 4-8 bytes even for a null pointer (if my understanding of Java memory is correct http://www.javaspecialists.co.za/archive/Issue029.html.)  Not only that but a HashMap isn't really a lightweight object.

What I've done in my project is created what I call "XithDataStore" it stores a WeakHashMap (so no memory leaks) from the SceneGraphObject to "XithData."  The XithData object is with a bunch of setters and getters.

To maintain backwards compatibility, if the user were to do a setUserData(key, value) it could create the HashMap and store that in the WeakHashMap.

qb

[Lobotomia]

You can always apply a user object to any scenegraph node through the setUserObject() method.

Marvin

I have seen thet Model does'nt have this, must i, in this case, use a TransformGroup?

[lonesomeStranger]

Model has getUserData() inherited from SceneGraphObject

[Lobotomia]

Model has getUserData() inherited from SceneGraphObject

and SetUserData.
Solved with this.
Thank you

[Marvin Fröhlich]

I've been meaning to comment on this...

Right now every SceneGraphObject has its own UserObject HashMap.  This seems heavy on memory, as each SceneGraphObject must allocate an extra 4-8 bytes even for a null pointer (if my understanding of Java memory is correct http://www.javaspecialists.co.za/archive/Issue029.html.)  Not only that but a HashMap isn't really a lightweight object.

What I've done in my project is created what I call "XithDataStore" it stores a WeakHashMap (so no memory leaks) from the SceneGraphObject to "XithData."  The XithData object is with a bunch of setters and getters.

To maintain backwards compatibility, if the user were to do a setUserData(key, value) it could create the HashMap and store that in the WeakHashMap.

I have thought about this the whole day since I replied to the initial posting, because it is indeed as you say. But I couldn't find a better way. The way, you describe looks like a very good one and could easily be implemented for SceneGraphObjects' user data storage. I will definitely do this tonight.

Marvin

[Marvin Fröhlich]

Right now every SceneGraphObject has its own UserObject HashMap.  This seems heavy on memory, as each SceneGraphObject must allocate an extra 4-8 bytes even for a null pointer (if my understanding of Java memory is correct http://www.javaspecialists.co.za/archive/Issue029.html.)  Not only that but a HashMap isn't really a lightweight object.

What I've done in my project is created what I call "XithDataStore" it stores a WeakHashMap (so no memory leaks) from the SceneGraphObject to "XithData."  The XithData object is with a bunch of setters and getters.

To maintain backwards compatibility, if the user were to do a setUserData(key, value) it could create the HashMap and store that in the WeakHashMap.

I've rethought this. And it won't work as a default implementation as back storage for all SceneGraphObjects' user objects for two reasons:

1. The key for a user object is an object. So we can't prefix it with a node local information. Therefore we cannot use one big map for all SGOs to store arbitrary data. Of course this will work like you did it. But this can't be implemented directly in the xith API, since we cannot assume a certain storage type.

2. The WeakHashMap removes entries from the map when no other pointer exists to the mapped object. This is an absolute no-go and I am pretty sure, that this is even not the behavior, that you need in your app.

The current solution is not that bad, since the HashMap is instatiated when it is needed (not earlier). So there's just this one null pointer per SGO (8 bytes), that I really wouldn't worry about. A node is a lot bigger than just 8 bytes. So this is just a small piece of the cake.

Of course I am very open, if you have a better solution, that will actually work.

Marvin

[qbproger]

I've rethought this. And it won't work as a default implementation as back storage for all SceneGraphObjects' user objects for two reasons:

1. The key for a user object is an object. So we can't prefix it with a node local information. Therefore we cannot use one big map for all SGOs to store arbitrary data. Of course this will work like you did it. But this can't be implemented directly in the xith API, since we cannot assume a certain storage type.

There wouldn't be a need for a default key anymore.  In one big map, the key would be the SGO itself.  Then if the user uses setUserData(key, value) xith would create a HashMap and put it into map as a value.  If they just do setUserData(value) it would store it directly as the value in the WeakHashMap.

2. The WeakHashMap removes entries from the map when no other pointer exists to the mapped object. This is an absolute no-go and I am pretty sure, that this is even not the behavior, that you need in your app.

The current solution is not that bad, since the HashMap is instatiated when it is needed (not earlier). So there's just this one null pointer per SGO (8 bytes), that I really wouldn't worry about. A node is a lot bigger than just 8 bytes. So this is just a small piece of the cake.

Why would the WeakHashMap be a problem for anything?  I haven't gotten any null pointer exceptions as a result.  If there are no more pointers to the object besides the WeakHashMap it gets collected.  This is the same behavior as the current implementation.  The HashMap in a SGO doesn't stick around after the SGO has been collected.

Why would you want a HashMap to keep that memory from being collected?

I'm not sure if my response to the first part is clear.  Let me know if it's not.
qb

[Marvin Fröhlich]

I was wrong. I was hoping to come back from work to be able to post here before you correct me . Of course this will work as you described it. But it won't work like the current implementation. If the user stores a user object through setUserObject( Object ), previously stored objects (in the HashMap) aren't discarded and objects stored by key don't discard the no-key user object. So, if we move the your solution we would at least break the API, which is something, I would like to avoid for the future, if not necessary. And the additional memory for the pointer to the HashMap or the HashMap itself have ever been a problem so far. So I would like to stick with the current implementation as long as someone really proves, that this is an issue.

Marvin