I believe I found a minor bug. When obtaining the static Quaternion identity you are able to modify it. I’m not sure if this is by design or not, but I’m assuming its the latter.
I hadn’t worked with Java in a bit and I’m fairly new to jMe, so when creating a camera control I wrongly initialized the Quaternion I needed as Quaternion quat = Quaternion.Idenitity;. Needless to say any changes I made to the variable ended up changing the static Quaternion.Identity, and I didn’t find out until another module tried to obtain Quaternion.Identity and gave me the wrong values. It is a minor problem that I solved easy in my code, but I can see how others might find that problematic.
Thought I’d point that out in case it was by accident on the developers’ side.
I’ll note that it also applies to many of the others like Vector3f.
I only found out because my Vector3f.UNIT_Y was suddenly not of unit length which caused unusual problems with the camera lookat method. Pretty much pulled the program apart trying to find how that happened.
This is no totally true. There is always the possibility to extent the desired classes overriding the needed methods to create an immutable version (at least for quaternions where members are all private). Am I wrong?
The solution is providing an accessor method and make the constant private or protected. The accessor would either provide a clone or a new instance of the constant since actually providing the object wouldn’t be much better.
Structured Java programmers don’t usually leave variables public unless they absolutely must. Though in all reality most people don’t follow those rules (including myself most of the time).
It’s a minor thing, though I thought I’d point it out in case others get into a similar problem or to be fixed if the devs get the chance.
Or just use
Quaternion quaternion=new Quaternion();
The quaternion will equal the Quaternion.IDENTITY.
The proof for this is here:
What’s the point of keeping a reference to a constant with
Quaternion quat = Quaternion.Idenitity;
when the constant itself is the reference.You should not do this,ever.
This wouldn’t be a geat solution. Currently, accesing those constants doesn’t create new instances each time (depending on the usage and the environment it wouldn’t be the best to create a new one). Additionally, I think that the meaning of constant isn’t only to provide a value that is “equals” but a one that is “==” (if not, it isn’t a “constant”, at least not OO talking).
Anyway, as many others already said, the correct usage if the instance is meant to change is Just creating a new instance (.clone() or new). The proposed solution wasn’t to fix a bug or an issue engine-side but to avoid missusages dev/user-side.
The problem with all of the “solutions” is that they present down sides for EVERYONE but upsides for the few that occasionally make the mistake.
A far easier “solution” is to saddle those folks with an app state that checks every frame to see if the values are still what they are supposed to. Then it penalizes no one except the people making the mistakes.
Though it won’t tell you where you’ve misused them… at least you’d know.
The only thing is wrong here is : Quaternion quat = Quaternion.Idenitity;.
My explanation is (if I am wrong please correct me):
You want use quat as a variable . But in your command line it is a pointer like thing (there is no pointer in java).
Now quat is pointing to the memory address of the CONSTANCE Quaternion.Idenitity.
When you put new value to quat you put new value to the place store the Quaternion.Idenitity hence change the value of Quaternion.Idenitity.
My suggestion : try Quaternion quat = new Quaternion.。。。。。;
Remember quat is a Quaternion class.
BTW:
I think it is something about instantiation in JAVA and you are familiar with C++?
Finally, I am also not a good programmer,If I AM Wrong please correct me .
You probably meant “Ardor3D”. I like Renanse’s solution to this problem, I find it smart and I don’t think that not driving the Quaternion class final has a huge impact on the performance. It’s really difficult (but not impossible) to modify Quaternion.IDENTITY by mistake in JogAmp’s Ardor3D Continuation; if you used a cast on it, you would violate the interface.
I haven’t looked at Ardor3D and I don’t plan to. I have trouble seeing how a “solution” to this “problem” could do anything positive without hurting performance at least a little.
JME is not designed to hold every newb developers hand. It’s designed to be efficient and you have to know your ass from your face most of the time.
If you want jME math with immutable constants use Ardour3D 
