If it returns a new Vec3, then it isn't getting assigned to anything. And if it doesn't returns a new Vec3, it looks like a global static method that does something on other static stuff. Which kinda looks ugly since if other thread dares to touch the same Vec3 static, bad things could happen.

It's common practice among Java game developers to keep an internal temporary vector in some classes to avoid newing them all over the place. Given the number of them often needed in a single frame, it can put a bit too much pressure on the GC in some cases. I've seen different approaches to how they're implemented. Most commonly its as a normal class member in the class that needs it. I assume that Marcus has implemented one in this case as a static member of his Vec3 class. Of course it isn't thread-safe, but I seriously doubt that's an issue in for him. Static members and methods that mutate state are common in Java, so any Java programmer worth his salt knows when to use them and when not to. If he needed multi-threaded access, he would have chosen a different approach.

As far as I know, in Java, if something is static, its static to that class in that applicaton, so no "thread globals" (unless I misunderstood what you're saying).

This what I meant by thread local (not to imply I have any idea how Vec3.newTemp is really implemented):

public class Vec3 {
 
public Vec3() {
    x = y = z = 0.0f;
}
 
private float x, y, z;
 
private static final ThreadLocal<Vec3> temp = new ThreadLocal<Vec3>() {
    @Override protected Vec3 initialValue() {
        return new Vec3();
    }
};
 
public static void newTemp(float x, float y, float z)
{
    Vec3 v = temp.get();
    v.x = x;
    v.y = y;
    v.z = z;
}
}
 

I never knew such thing existed (its no surprise since I never delved beyond the "extend Thread or implement Runnable" in Java). Looking at the Javadocs, it looks like a pretty nice feature.

It's common practice among Java game developers to keep an internal temporary vector in some classes to avoid newing them all over the place. Given the number of them often needed in a single frame, it can put a bit too much pressure on the GC in some cases. I've seen different approaches to how they're implemented. Most commonly its as a normal class member in the class that needs it. I assume that Marcus has implemented one in this case as a static member of his Vec3 class. Of course it isn't thread-safe, but I seriously doubt that's an issue in for him. Static members and methods that mutate state are common in Java, so any Java programmer worth his salt knows when to use them and when not to. If he needed multi-threaded access, he would have chosen a different approach.

I know, probably the most used static around is a Random instance. But it sounds weird to place it directly on the Vec3 class instead of, as you said, the class that needs it.

I mentioned threading because from what i've read around, in voxel engines its pretty common to do multi threaded stuff (ie, generating chunks in a secondary thread), I have no idea if Minecraft follows such practices though.