22-11-2019, 03:29 PM
(This post was last modified: 22-11-2019, 03:40 PM by josemendez.)
I really appreciate your insight on this. Very useful conversation to have. 
Personally, I think the UI architecture design is quite good, and fits Obi like a glove: you have a manager object, and a lot of managed objects that need to have a reference frame to perform their stuff in. Having every object reference the manager and then juggling with transforms to express data in the correct space (like we did) is an option. but somehow having them all as a child of the manager seems a lot cleaner to me, as you kill two birds with one stone: all managed objects now have a common clear reference frame, and also an implicit reference to their manager. Its simple, elegant, works well and does not leave margin for half-done setups.
While technically we could let actors reference a solver that could be anywhere, that would make the local space/world space issue to return, as each actor could potentially be simulated in its own space. Not good from usage simplicity, code simplicity, or performance standpoints. Will think of alternatives to this.
Yes. If you unparent it, it removes the actor from the solver. If you reparent it to a new solver, then it adds it to the new solver. All this happens internally and you don't need to know about it. Going back to the UI example, you don't need to know that a Canvas keeps a list of all canvas renderers below it and dynamically updates it when reparenting them, but it does. All this is transparent to the user.
An actor is managed by the first solver up its hierarchy, at all times. Simple rule. If no solver can be found, the actor is not simulated.
You cannot have a reference to an external object within a prefab (just like you cannot have inter-scene references), so if you want things to work out of the box when instantiating the prefab, you'd need to have both the solver and the rope as part of the prefab. At this point, I don't see the difference between having a solver at your prefab's root, or having all ropes in your prefab reference the solver (that must also be within the prefab).
If the solver lives outside your prefab (in the scene, or an unrelated prefab), then at runtime you will have to either find all ropes in your prefab and set their references to the solver, or simply reparent the whole thing under a solver. If you have multiple ropes per prefab the former is a bit of a chore, the latter is much simpler.
I'm not entirely sure I grasped your use case though, so let me know if this doesn't make sense to you.
I was thinking of only 1 attachment in my example, sorry. Yes, in the case you have multiple attachments per actor this is the way to do it. You'd need to lock one inspector to be able to drag the specific attachment you need. However this is true with pretty much everything in Unity: if you have multiple colliders per object, and you want to reference a specific one, the same workflow is required.
I think I get the point. If it would make things easier, I can create a second attachment "flavor", that would be added to the target transform and have a reference to the actor (instead of having a reference to the target, and being added to the actor). That way you could have the attachments in the objects the actor is attached to, and have them reference the actor that lives anywhere else. How does this sound?
Not really. This would require the actor to keep track of all attachments referencing it, which makes me feel a bit dirty from an architectural point of view. Ideally the actor should not know anything about attachments. Just like a rigidbody knows nothing about the joints affecting it.
(22-11-2019, 02:18 PM)Bill Sansky Wrote: While I agree that it is familiar, the UI architecture is quite problematic the new prefab architecture, and I'm not sure the two are really comparable: to me, actors like obi actors are meant to be flexible in the hierarchy so the user can do whatever fits his usage. The UI architecture itself is quite criticized in Unity's forum, so I'm not sure it's necessarily the best example.
In my personal case, it is quite problematic. Now I understand I can just call AddToSolver and ignore the architecture, but couldn't I just have an ObiSolver field so I could manually set it in the inspector like it used to be, and that would be found by default in the parent on Reset?
Personally, I think the UI architecture design is quite good, and fits Obi like a glove: you have a manager object, and a lot of managed objects that need to have a reference frame to perform their stuff in. Having every object reference the manager and then juggling with transforms to express data in the correct space (like we did) is an option. but somehow having them all as a child of the manager seems a lot cleaner to me, as you kill two birds with one stone: all managed objects now have a common clear reference frame, and also an implicit reference to their manager. Its simple, elegant, works well and does not leave margin for half-done setups.
While technically we could let actors reference a solver that could be anywhere, that would make the local space/world space issue to return, as each actor could potentially be simulated in its own space. Not good from usage simplicity, code simplicity, or performance standpoints. Will think of alternatives to this.
(22-11-2019, 02:18 PM)Bill Sansky Wrote: So does it means that Obi will automatically add the actor to the solver as soon as it's reparented? What if I unparent it, what happens then? That's also confusing to me then: nothing indicates a runtime handling of this here, and if there is it's not necessarily easy to understand (at least to my standard)
Yes. If you unparent it, it removes the actor from the solver. If you reparent it to a new solver, then it adds it to the new solver. All this happens internally and you don't need to know about it. Going back to the UI example, you don't need to know that a Canvas keeps a list of all canvas renderers below it and dynamically updates it when reparenting them, but it does. All this is transparent to the user.
An actor is managed by the first solver up its hierarchy, at all times. Simple rule. If no solver can be found, the actor is not simulated.
(22-11-2019, 02:18 PM)Bill Sansky Wrote: I understand, but that also means that you can't configure your obi actor with your own logic and objects together under prefabs: I use obi rope together with cable connectors that can drag and drop, and a whole logic to pool them and save/load them: it makes much more sense project-wise to have the obi actor part of the same prefab, and it also makes it much easier to debug: I suppose I could change the parent of the rope only on runtime, but I find it confusing.
You cannot have a reference to an external object within a prefab (just like you cannot have inter-scene references), so if you want things to work out of the box when instantiating the prefab, you'd need to have both the solver and the rope as part of the prefab. At this point, I don't see the difference between having a solver at your prefab's root, or having all ropes in your prefab reference the solver (that must also be within the prefab).
If the solver lives outside your prefab (in the scene, or an unrelated prefab), then at runtime you will have to either find all ropes in your prefab and set their references to the solver, or simply reparent the whole thing under a solver. If you have multiple ropes per prefab the former is a bit of a chore, the latter is much simpler.
I'm not entirely sure I grasped your use case though, so let me know if this doesn't make sense to you.
Quote:It is not similar: in your case you are required to:
It's just really not a convenient workflow. Moreover, it doesn't scale well: let's say I would have 20 attachment on one rope, that means 20 components on the same objects: it's both very hard to navigate and also not readable.
- Open your obi actor inspector, and lock it
- Open a second inspector for your object that requires a reference to an attachment
- drag and drop the component on the second inspector
- Unlock / close the inspector
I was thinking of only 1 attachment in my example, sorry. Yes, in the case you have multiple attachments per actor this is the way to do it. You'd need to lock one inspector to be able to drag the specific attachment you need. However this is true with pretty much everything in Unity: if you have multiple colliders per object, and you want to reference a specific one, the same workflow is required.
Quote:This is really easy to do with the custom search on the scene or using the new Quick Search feature. I would also say that with a proper naming convention, it's really easy to find.
On the contrary, trying to track which component is problematic in a list of 20 or so on the same game object is much harder, because the object pinging won't work, and the reference fields won't indicate which component is used.
It is in any way less messy than having multiple components of the same kind of a singular objects: I try to make my game objects respect the single responsibility principle as much as possible, and I find it much easier to operate and navigate, especially that it allows you to use all the navigation features of Unity (pinging, logging, searching...) and to apply any naming convention you may want (contrary to adding many components to the same object since now the object has a lot of responsibilities and a single name, and no ability to ping it or log it properly)
I think I get the point. If it would make things easier, I can create a second attachment "flavor", that would be added to the target transform and have a reference to the actor (instead of having a reference to the target, and being added to the actor). That way you could have the attachments in the objects the actor is attached to, and have them reference the actor that lives anywhere else. How does this sound?
Quote:On the top, you could have read-only inspector fields on your ObiActor component that show all the current attachment, so that it is easy to track them from the editor: this way you'd have the best of the two worlds.
Not really. This would require the actor to keep track of all attachments referencing it, which makes me feel a bit dirty from an architectural point of view. Ideally the actor should not know anything about attachments. Just like a rigidbody knows nothing about the joints affecting it.