GUI - don't limit control.linkWithMesh() to root level

[royibernthal]

It'd be great if meshes linked by control.linkWithMesh() would not be limited to the root level of adt, so that controls that are parented any number of containers would be valid for linkWithMesh().

I suppose this would require a further translation of projectedPosition in AdvancedDynamicTexture/_checkUpdate() from the global coordinates system to the control's local coordinates system before calling control._moveToProjectedPosition().

 

Deltakosh - What do you think about creating localToGlobal() and globalToGlobal() functions in adt? These could be useful generic functions, as well as naturally solve this issue. I'm not sure how to best implement such functions, so I guess this is a feature request

[Guest]

If you link a control with a mesh, you want it to not be controlled by anything else. So no parenting or you will inherit from parent transformation as well (which will break everything)

[Wingnut]

On 4/21/2018 at 4:31 PM, royibernthal said:

controls that are parented (-to) any number of containers

My dog got scared when you said that, Royi.    Copy-of control, probably fine.  Same control... being a child of multiple containers?   That might crack the planet. 

(Wingy grabs a hard hat and a roll of Gorilla tape, just in case.)  I could easily be wrong, though.  Interesting subject.  I can tell Royi is neck-deep in dev... talking about moveToProjectedPosition() and _checkUpdate()  [mesh-tracking funcs for linkedMesh].  He's codin'-up a GUI masterpiece.   

Why did I need to comment?  I dunno.  Mental problems, I suspect.

[royibernthal]

Deltakosh - What if I have adt -> container -> button, and I'd like the button to track a mesh? For that it'll have to be translated into the coordinates system of the container. That way we fix parent transformation that "breaks" this.

Let me know if I'm still missing something.

 

3 hours ago, Wingnut said:

Same control... being a child of multiple containers?

I'm talking about nesting 

[Guest]

But if you want your button to track a mesh, why do you want it in a container. What could be the use case?

[royibernthal]

In my case I'd like the control I'm tracking to be rendered in between other controls that are parented by a container. In other words, I need to be able to set the z of a tracked control in an environment of nested controls.

[Guest]

So it is not position related and we don't need a toLocal/toGlobal API.

You only want to control the rendering order (I can get that). So we could reduce the constraint to be at root level for sure as long as it is clear that you cannot inherit from parent position.

Furthermore inside a container you will be clamped to parent's bounding box which could be weird if the mesh move outside of container limits

[royibernthal]

18 minutes ago, Deltakosh said:

So it is not position related and we don't need a toLocal/toGlobal API.

In my case it's not position related, but in order to keep the positions calculations and logic intact, I thought a simple globalToLocal would do the job, instead of limiting position in some unnatural way when a control is linked to a mesh, unless you have something better in mind.

 

20 minutes ago, Deltakosh said:

Furthermore inside a container you will be clamped to parent's bounding box which could be weird if the mesh move outside of container limits

It seems to me like something obvious that the programmer will have to take into account, in my case the container is simply fullscreen.

[Guest]

Os why not:) as long as we make it clear I can remove the constraint. Let's see that for 3.3

[royibernthal]

So all I need from you is a globalToLocal function in Control class (and maybe also localToGlobal just as a completing util function). The rest I could do myself, though there won't be much left for me to do 

[Guest]

We don't even need them. The linkToMesh will overwrite position as soon as I'll remove the constraint