21-11-2019, 06:50 PM
(This post was last modified: 21-11-2019, 10:59 PM by josemendez.)
Hi Bill!
Thanks for the deep feedback! Very few people take the time to think about architectural decisions and build constructive criticism this way, so I really appreciate it.
We weighted pros and cons very carefully when deciding to switch to this architecture, here are the points we considered (some of them are "answers" to yours):
- This design is identical to Unity's UI architecture: their Canvas is our Solver, and UI panels our Actors. It's tried and tested, and for most users, a familiar architectural design.
- Unless I'm missing something, you can edit ropes fine in blueprint mode. However you won't get visual feedback on the final rendered mesh, only on the path shape (the path spline and the thickness handles are still rendered when no solver is present).
Anyway, there's ways to have a custom prefab stage root object, so in the near future we could add a ObiSolver to the stage root every time you edit a prefab actor without much effort. Looking into it! Edit: seems an easy way to define your own root object for prefab mode is being worked on: https://forum.unity.com/threads/creating...ts.574795/ Edit2: see post below for a working solution
Also, being able to easily scale/move/rotate the entire simulation using a transform (as if it was rigid object) was an extremely common request among users, and a major source of complaints in support. While it was possible in 4.X by using local-space simulation, setup was not very intuitive, it was *very* easy to get wrong (by enabling local mode but forgetting to parent the actor to the solver), and supporting both local and world space modes required a lot of internal back-and-forth transforming that wasn't cheap in terms of performance.
Allowing an actor to work only when parented to a solver results in an intuitive way to transform the entire thing (that is impossible to set up wrong), unifies both code paths leading to more robust and maintainable code, everything is expressed in the same space which simplifies the API, and on top of that improves performance a bit (not much, but enough to be welcome).
If I understood correctly, the use case you describe is:
- You have a custom component A that wants to activate/deactivate the attachment, so it must have a reference to it.
- Since the attachment must be on the actor object, you need component A to declare a reference to an attachment, so that you can drag/drop the attachment to A.
And the proposed solution:
- Attachments can be added to any object, and have a reference to the actor they attach. So you can create a custom component A that expects an attachment in the same object it is added to.
- Then you have to set up the attachment's reference so that it points to the actor it has to attach.
In both cases you have a reference to an object, and the work you do (both in editor and scripting) is basically the same: you have two components, and one of them must have a reference to another object. The only difference lies in how you write "A": as a component that accepts a reference to an attachment, or a component that "requires" an attachment in the same object.
Also consider what happens when the same actor has multiple attachments. With your solution, attachments could be pretty much anywhere in the scene, and having to look for them all over the place doesn't sound nice. Currently they're all in the actor's inspector, and you can easily see all transforms the actor is attached to listed in the same place, which is pretty neat. Also works in the same way as Unity's joints, so again a familiar design.
This is the same design most existing Unity components have: if a component primarily acts upon or modifies an object, it should be added to that object. Allowing it to be added to any object in the scene, and then referencing the actual object it works on it's a bit messy imho. By your logic, it should be possible to add joints to any object, and have them expose two references to the objects it joins. Or allow MeshRenderers to have a reference to the transform used to transform the mesh.
Let me know your thoughts!
Thanks for the deep feedback! Very few people take the time to think about architectural decisions and build constructive criticism this way, so I really appreciate it.
We weighted pros and cons very carefully when deciding to switch to this architecture, here are the points we considered (some of them are "answers" to yours):
- This design is identical to Unity's UI architecture: their Canvas is our Solver, and UI panels our Actors. It's tried and tested, and for most users, a familiar architectural design.
Quote:It makes it impossible to create rope prefabs and to edit them in prefab mode, which is now core in production for unity 2019+: the ropes do not have a solver in this, so it can't be edited properly. But most of my work, and I suspect most of the users will be in the same scenario, revolves around nested prefabs.
- Unless I'm missing something, you can edit ropes fine in blueprint mode. However you won't get visual feedback on the final rendered mesh, only on the path shape (the path spline and the thickness handles are still rendered when no solver is present).
Anyway, there's ways to have a custom prefab stage root object, so in the near future we could add a ObiSolver to the stage root every time you edit a prefab actor without much effort. Looking into it! Edit: seems an easy way to define your own root object for prefab mode is being worked on: https://forum.unity.com/threads/creating...ts.574795/ Edit2: see post below for a working solution
Quote:It makes it hard to link to a solver when being in a multiscene scenario, which is I think very common in current Unity's workflow- Not any harder than before, I think, since you cannot have objects from scene A referencing objects from scene B anyway. Linking to a common solver in 4.X would require to manually set the "actor.solver" property, then calling a custom API method (actor.AddToSolver()). This is arguably more confusing, verbose and error prone (most people forgot to call AddToSolver()) than simply reparenting a transform. In an ideal world, actors in different scenes should use their own solver. In the case where you need to have actors from different scenes interacting with each other, the workaround isn't more difficult than it was before.
Quote:It forces a hierarchy logic that is often not desirable, especially so when the solvers are not colliding with each other.- Character clothing and soft bodies (both of which are huge use cases in Obi) almost always require local space simulation to be of any use, so the cloth/softbody must be a child of the solver, even in 4.X. We couldn't really find a use case where having actors grouped under a solver meant big trouble.
Also, being able to easily scale/move/rotate the entire simulation using a transform (as if it was rigid object) was an extremely common request among users, and a major source of complaints in support. While it was possible in 4.X by using local-space simulation, setup was not very intuitive, it was *very* easy to get wrong (by enabling local mode but forgetting to parent the actor to the solver), and supporting both local and world space modes required a lot of internal back-and-forth transforming that wasn't cheap in terms of performance.
Allowing an actor to work only when parented to a solver results in an intuitive way to transform the entire thing (that is impossible to set up wrong), unifies both code paths leading to more robust and maintainable code, everything is expressed in the same space which simplifies the API, and on top of that improves performance a bit (not much, but enough to be welcome).
Quote:I have another similar problem concerning the new attachment system: because it must be a component on the same game object as the obi actor, it makes the architecture not very flexible and not easy to use with the classic drag and drop for fields. If I have a custom component that wants to activate or deactivate that attachment in runtime, linking them in the editor becomes an annoyance.
Would it be possible to make it a component that can be added anywhere with a reference to the obi actor it constrains? this would be much more flexible.
If I understood correctly, the use case you describe is:
- You have a custom component A that wants to activate/deactivate the attachment, so it must have a reference to it.
- Since the attachment must be on the actor object, you need component A to declare a reference to an attachment, so that you can drag/drop the attachment to A.
And the proposed solution:
- Attachments can be added to any object, and have a reference to the actor they attach. So you can create a custom component A that expects an attachment in the same object it is added to.
- Then you have to set up the attachment's reference so that it points to the actor it has to attach.
In both cases you have a reference to an object, and the work you do (both in editor and scripting) is basically the same: you have two components, and one of them must have a reference to another object. The only difference lies in how you write "A": as a component that accepts a reference to an attachment, or a component that "requires" an attachment in the same object.
Also consider what happens when the same actor has multiple attachments. With your solution, attachments could be pretty much anywhere in the scene, and having to look for them all over the place doesn't sound nice. Currently they're all in the actor's inspector, and you can easily see all transforms the actor is attached to listed in the same place, which is pretty neat. Also works in the same way as Unity's joints, so again a familiar design.
This is the same design most existing Unity components have: if a component primarily acts upon or modifies an object, it should be added to that object. Allowing it to be added to any object in the scene, and then referencing the actual object it works on it's a bit messy imho. By your logic, it should be possible to add joints to any object, and have them expose two references to the objects it joins. Or allow MeshRenderers to have a reference to the transform used to transform the mesh.
Let me know your thoughts!