If you use Unity every component/script you add to a scene is based on a Transform, surely this is a waste as all transforms will need to be updated every frame?
What if each Unity scene had a non transform component hierarchy, in a way they do in the form of Canvas elements, lighting properties, physics and layer properties all of which are part of the scene but not associated with it structurally.
What if you could add your Game.cs script to the root of the scene and know that it has no impact, or you can add empty none transform components to game objects that are just scripts and can be built up into hierarchies of their own with no impact on the 3D transform of their game objects?
It could allow scriptable components to be lighter, no need to have a transform component.
If you have components that don’t rely on transforms, just group them together on to one object and the overhead should be negligible. Hell, I’m pretty sure the performance overhead for this sort of thing is next to nil anyway until you reach absolutely massive numbers of transforms.
Agreed with @Murgilod , you could have multiple behaviours attached to a single object so you’re only adding a single extra transform. Or even a single behaviour that acts as a “controller” for subsystems.
As long as you dont have mesh renderes on the transforms there is close to zero overhead. As far as I can tell atleast. I did a quick POC because we have first person hand riggings on our items with 5 fingers 3 joints 15 transforms + 1 for the hand = 16. And maybe 8-16 different riggings for each item. So around 256 transforms. Plus the items other transforms so maybe 300 total. Zero overhead as far as I can tell
Yea, a couple of extra transforms is really a non issue, probably not even measureable. If you are talking about hundreds, that’s a design issue and any performance impact would be the least of your problems.
Scriptable objects stored as assets on occasion glitch out, though. Basically, if you duplicate a scriptable object with ctrl+D in porject view, it seems it on occasion start losing or resetting data. Not sure if the issue still happens in 2017.1
I can see the benefits as scene meta data would be directly linked to a scene e.g. physics, input, lighting, etc and allow for different scenes to have different meta data configurations.
It might save me ten or fifteen seconds a month. I really don’t think its worth the effort of inventing a new workflow just to get rid of the cost of a handful of transforms.
Yea, there really isn’t any point to it. As mentioned above there are several ways to do it already, obviously the simplest being attaching it to a gameobject. There wouldn’t be any advantage to adding another place to attach stuff, in fact it would just add complications, order of execution, there would have to be new api to communicate with it which would add a bunch of new stuff to the engine which would have to be tested and maintained. An extra transform is literally no cost, whereas adding a whole new feature is, and it would more stuff to troubleshoot. It is the extreme end of micro-optimization. I am all for new features that have a benefit, but this is just an “alternate” way of doing things, which is completely unnecessary. The overhead of new engine components would most definitely more use more resources than an empty transform.
I guess we could disable the ones not currently used and enable them when used