TerrainQuad SetHeight vs GetHeight


It seems to me that the getHeight and setHeight methods aren’t consistent with each other.

When you call getHeight the vec2 given is translated by the world transform but the vec2 in setHeight isn’t.
Is there any reason for this?

Looking at the source: getHeight(vec2):

public float getHeight(Vector2f xz) {
        // offset
        float x = (float)(((xz.x - getWorldTranslation().x) / getWorldScale().x) + (float)(totalSize-1) / 2f);
        float z = (float)(((xz.y - getWorldTranslation().z) / getWorldScale().z) + (float)(totalSize-1) / 2f);
        if (!isInside((int)x, (int)z))
            return Float.NaN;
        float height = getHeight((int)x, (int)z, (x%1f), (z%1f));
        height *= getWorldScale().y;
        return height;

and setHeight(Vec2, f) calls:

public void setHeight(Vector2f xz, float height) {
protected void setHeight(List<Vector2f> xz, List<Float> height, boolean overrideHeight) {
        // offset
        for (int i=0; i<xz.size(); i++) {
            int x = Math.round((xz.get(i).x / getWorldScale().x) + halfSize);
            int z = Math.round((xz.get(i).y / getWorldScale().z) + halfSize);
            if (!isInside(x, z))
            locations.add(new LocationHeight(x,z,height.get(i)));

        setHeight(locations, overrideHeight); // adjust height of the actual mesh

A heightmap should have values between 1 and 0 - and it’s keeping in-form with that. This allows you to change the scale as and when you wish - and it will return correct results. If it saved scaled results it would cause all manner of havoc.

Yes I understand that and setting the height is fine currently.
I’m more concerned with the vector2f translation because one does world to local translation but the other doesn’t you can’t do something like:
chunk.setHeight(vec2, (chunk.getHeight(vec2) + 10)/world-class)