Well I precompile my models to j3o to reduce the load time for the application.
That all works fine, however whenever I rebuild them they get different checksums, so when synching after that every file is reuploaded, even if the content is identicall.
The culprit seems to be the references used by the exporter (in this case the xml one, i assume the binary has the same behaviour)
<com.jme3.scene.VertexBuffer ref=‘com.jme3.scene.VertexBuffer@618454755’/>
The memory address/hash of course changes with each execution, so the question is, if it is possible to find another scheme for the referenes that could work without breaking anything.
My initial suggestion would be to change this part
[java]
String refID = el.getAttribute(“reference_ID”);
if (refID.length() == 0) {
refID = object.getClass().getName() + “@” + object.hashCode();
el.setAttribute(“reference_ID”, refID);
}
el = appendElement(name);
[/java]
with one that just uses a incrementing integer for each object, and writes that instead.Also storing Object->Id in a Hashmap for further use.
So Basicall it would replace the memory based address/hashcode with a order dependent id.
Pro:
-> Same model would result in same j3o if no other changes are made.
-> This would benefit any kind of delta updater (for customers) and ressource sharing tool (for developers)
Contra: So far I see none, is there anything dependend on the hashcode being used?
As its about not storing the same object twice the object id is pretty ideal for this. But why do you rebuild your objects when nothing changed anyway? oO
Well I dont know if something changed like in the compile tool. (it does much preprocessing as replacing materials find additional maps ect. and occasionatily it gets a change, but often there only affect very few models)
For example on of the altest chagnes is a dupliate texture elemination, that relinks to only one instance on the fly, but wic models use actually duplicates I cannot exactly know before.
Objects can technically return whatever they want from hashCode(). Returning 0 every time is technically a valid hash code as they are not guaranteed to be unique. They only must be the same if two objects are .equals() equivalent (which returning 0 every time satisfies even if stupidly). For the things that fall through to the system identity hashcode, it’s probably unique enough but for anything that generates its own hash code (like Vector3f) you will get collisions.
So while it’s still a little unsafe, if identity hash code is really what you want then it’s probably better to use System.identityHashCode() specifically. Or build up an ID table of some other form of ID (as Empire suggests) that would never collide.