Well, I’m biased… to me there already are Vec3d, Vec3i classes in an external library that can release whenever it wants. I’m biased because it’s my library.
…bonus is that it’s also already compatible with all of my other libraries (SiO2, Sim-ethereal, etc.)
JME doesn’t need these classes. The stuff locked up in the blender loader should stay locked up in the blender loader. It’s very likely that project will be deprecated someday because it receives almost no support and is basically an impossible task to meet the goals. The hope is that gltf will replace the need for it anyway.
So if you want to contribute some stuff to sim-math then that could be cool.
I’m not sure I’m 100% keen on swizzle methods, though. In my experience, half the time people will forget they are there and just use the relatively short equivalent… and the other half of the time we’ll have missed the combination that they actually want.
My autistic senses are tingling. Why not Vector3d and Vector3i, just as the other vector classes are named?
That’s totally understandable. I might use your library. However, you have an AaBB class and I have my own class named AABB, which can be really confusing.
Hmmm I think those numbers (from the main post) are reasonable and short : 2 and 8.
It’s alright, anyway, school just started out of nowhere for me and I am quite overburdened. The school didn’t contact me to give me my schedule and didn’t transfer my emails to the right person, so someone emailed me this morning to ask where I was
On another note, keeping this simple might leave me with some free time to work on my project (colony simulation).
Because they are not JME classes, Vec is shorter to type than Vector (not really a consideration though), and it more closely matches shaders.
Yes, you are falling into the trap that old Sun code did… then they end up with potentially crazy class names like TCPHTTPSMPTAdapter or whatever. Modern Java convention is to camel case acronyms like words so that they are easier to read. (Edit: note that Sun started doing this later in Java… I didn’t make it up.)
(Mine is called AaBBox, by the way… Axis-aligned Bounding Box. Aa B Box.)
2 seems fine. 8 I would need to see the exact adjusted proposal recognizing that you can’t change any of the existing methods without breaking someone’s code.
Edit: wait… what exactly would “transformVectorLocal” do? It’s not modifying the transform is it?
It’s supposed to transform locally a vector, so without creating a new vector.
I can’t find it but, in this thread, I think someone mentioned that it was because the equivalent of transformVectorLocal existed in the vector class. I’ll need to verify that when I’ll have the time.
someObject.xxxLocal… means it modifies someObject, ie: local.
Normally, for what you want to do you’d be able to pass a target vector… which if the method supports it could be the same vector you are transforming.
I don’t think JME has a naming convention for modifying an object that is passed to it… but it does use the transform(someThing, target) thing all over the place. Actually, Transform already has such a method.
The last time I implemented vectors in Java, I made them immutable. It takes most of the naming issues off the table. I think you should consider it, if you haven’t already.
Yes, well… it removes the naming issues because there is no longer any way to be optimally performing… since you end up creating lots of garbage no matter what. If you just want to add values to many many thousands of positions every frame, those extra allocations really do add up.
Vector objects are for convenience, readability, and maintainability. For optimal performance, use scalar primitives like float/int/double. But then you wind up with verbose code full of variables like positionX, velocityY and so on.
Obsession with performance leads to coding miracles like this one:
Yes, it works, but before modifying it in any way, one would probably completely rewrite it.
Performance only matters when it’s visible to the end user. In a real-time Java game, that typically means stutters caused by garbage collection. And there’s a solution for that, namely -XX:+UseConcMarkSweepGC.
It’s not even really about the GC in this case. It’s about the fact that allocating a vector (or many) can take as much time as the simple math operations being performed.
Well, in theory G1 is better than CMS - hence why they’re deprecating CMS and bringing in G1.
It’s been a while since I last read up on the details of the two, but as I understand it G1 may in some cases have worse latency during stop-the-world collections, but tends to have better throughput.
