Light position exported in world coordinates instead of relative to drawable location

[Kozzren]

When exporting a sollumz light parented under the drawable empty, and with the ymap as well, its world position is no where near relative to the drawable ingame. The only way for it to work is have it 0,0, but this really isnt good practice for large maps with many lights needed.

[ook3D]

def create_light_xml(light_obj: bpy.types.Object, armature_obj: Optional[bpy.types.Object] = None):
    light_xml = Light()
    light_xml.position = light_obj.location
    mat = light_obj.matrix_basis
    set_light_xml_direction(light_xml, mat)
    set_light_xml_tangent(light_xml, mat)

    if armature_obj is not None:
        set_light_xml_bone_id(light_xml, armature_obj.data, light_obj)

    set_light_xml_properties(light_xml, light_obj.data)

    return light_xml

its setting the position to the light object position, perhaps its not relative like you said.

[alexguirre]

Ok, so this is actually a bit of rabbit hole. The problem is caused by the light object parent inverse matrix.

When parenting an object to another object moved away from the world origin. The parent inverse matrix is set such that the child object keeps the same location vector and doesn't move in the world space.

This causes Object.location to not return coordinates relative to the parent, instead its origin remains the same as before it had a parent (normally world coordinates). See, in this case, Object.location matches Object.matrix_world instead of Object.matrix_local.

When the parent object is placed at 0,0,0, the parent inverse matrix of the new child objects stays as the identity matrix and then Object.location matches Object.matrix_local, which is why this issue isn't too common. Mainly happens when you are editing the drawable while placed in a ymap.

For now, the user can workaround this with the Clear Parent Inverse operator and re-positioning the object, or by setting the parent object through the object properties panel.

We should review where else are we using Object.location and possibly replace it with Object.matrix_local. Pretty sure all Sollumz code was written assuming Object.location was in coordinates relative to the parent, but with the parent inverse matrix that's not always the case.