Go.set_parent vs gui.set_parent

Questions
#1

Hello, guys!
I’m not sure, if it is a bug or not.
Is there a difference between go.set_parent and gui.set_parent in terms of transforms and coordinates behavior?
I have some code that works for me, when I use it in gameobject’s context. But when I move this code to gui part, it stops working.
I’m shooting flowers at the rotating circle. When the flower reaches the circle, I’m calling go.set_parent with keep_world_transform set to true. And my flower starts rotating with the circle. Nice, as I expect it to. I refactored my code to get rid of the gameobject part and move it to gui.
When I call gui.set_parent again with keep_scene_transform set to true, the flower attaches to my circle, but loses its rotation part. It is expected behavior or bug?

UPD: I created the minimal project to demonstrate gui.set_parent behavior.Test01.zip (392.9 KB)

#2

The documentation mentions:

keep_scene_transform - optional flag to make the scene position being preserved

#3

If this is true, then I would say, it is not intuitive :cry:
You probably need this for some reason, but I cannot invent the example, where this behavior (with only position preserved) is needed.

Kinda bad thing, that after every gui.set_parent I should calculate the angle, translate to parent’s position, rotate my object, and translate is back to get new position. And this all is because of the wiping rotation part. This kinda look ugly.

2 Likes
#4

Sure, I agree that it is strange. May I ask why you moved it from game objects to GUI nodes in the first place?

#5

Well, first of all, It is about “what you see is what you get” in gui editor. I’m prototyping now, so I tested game logic (well, more or less). Now it is time to prototype visual look. And it is much easier to do in gui editor.
Second, the code becomes easier to understand and work with, if it is not split in two files - script for gameobject and gui_script. Calling some function in one module is easier, than sending messages forth and back.
Third, when prototyping, I really like all those little things, that work out of the box in gui. Like setting color to box node (so I can set it green or red for good or bad feedback, etc). Or making box node disappear, via animating alpha component of the color of the node. I know, I can do this via shader, but it requires more work from me, I guess.

1 Like
#6

I think the the reason why rotation isn’t kept correctly had something to do with how adjustments/anchoring worked together with how we represent transforms internally in the GUI… Sadly I can’t for the life of me remember the exact reason. :frowning: I can try to dig into it a bit when I have time, but in honesty I don’t think it is something that we can solve in a short period of time. Hopefully you can work around it, or keep game stuff in the collection world?

3 Likes
#7 
local function on_flower_move_complete(self, node)
	self.ready = true

	--WORKAROUND: we manually calculate new_pos and rotation
	--Vector math: Translate-To-Parent's-Center * Rotate-By-Angle * Translate-Back-To-Child * pos
	local p1 = vmath.vector4(320, 500, 0, 1) --bottom point
	local p2 = vmath.vector4(320, 700, 0, 1) --circle center
	local tr_vec = p1 - p2
	local rot = vmath.matrix4_rotation_z(self.angle)
	local target_pos = rot * tr_vec + p2
	local new_pos = vmath.vector3(target_pos.x, target_pos.y, target_pos.z)

	gui.set_position(node, new_pos)
	gui.set_rotation(node, vmath.quat_rotation_z(-math.pi+self.angle))
	--End of WORKAROUND

	gui.set_parent(node, gui.get_node("circle_parent"), true)
end
1 Like
#8

Guys, thank you for your replies!
I posted the workaround, that works for me, in case someone ever needed it.

1 Like