I’d like to configure the transforms system to accomplish the following behavior:
child.position = child.localPosition * parent.localToWorld;
child.rotation = child.localRotation * parent.localToWorld;
child.scale = child.localScale;
(scale and localScale are non-uniform)
There is a ParentScaleInverse component, but from what I gather in the documentation that applies to both the child position and scale. I want to affect scale only. Any ideas?
At that point you should split the parent into two, one with Translation and Rotation, and the other as a child that has the scale.
That doesn’t give me the behavior I want. In my game, players build a (potentially giant) space station by connecting modules together. Some modules can expand or contract (hence the scale). When module A (the parent) contracts, module B (the child) needs to move with the contraction but not scale itself.
Now, if the model of module A were attached as a child, changing that child’s scale would (visually) contract or expand module A… but module B would not move.
I’ve now hacked together a custom system that bypasses the TransformSystem entirely and directly writes to LocalToWorld. That works for now, though I probably need to optimize it for the final game… it’s a bit of a worst case scenario for parallel processing, though, since almost every entity is a parent to another entity. Game behavior trumps processing speed, I suppose! 
Still, if anyone has a cleverer idea than this… I’m all ears!
Sounds like you need anchoring, not parenting. Same issue would surface with rotating modules for better visual variety, if you’d like to track anchor’s position but keep attached module’s rotation intact. Or when you’ll bump into multiple anchors, for example for destruction and system integrity model.
Sorry. I was thrown off by your dismissal of ParentScaleInverse. It should do exactly what you want.
You are correct!
Unfortunately, Unity crashes after about 950 entities when each new entity is made a child of the previous entity. 
Do you need that much parenting, though? It’s excessive.
Not in my games! Here is a station that someone built in Stable Orbit, the predecessor to the game I am currently working on:
Station modules are connected using parent-child relationships and those can get pretty deep. I cannot ignore those relationships, because they are important for gameplay. Parts of the station connected to a centrifuge module will spin (and, in the new game, generate gravity). Also, one of the disasters in the game is a failure of the connection between two modules causing part of the system (i.e. everything connected to one side of the connection) to break off.
If there is one thing that players have been asking for, it is the ability to build even larger stations. Stable Orbit pretty much grinds to a halt with stations as large as the one depicted, but that is with a gameObject-based hierarchy. Hence, I am looking at ECS to get me to performant and bigger stations in the new game.
So far, it’s looking good. I can get to 100K parent-child relationships easily with my custom system for managing the transforms (despite it being incredibly naive and unoptimized), with the main slowdown caused by rendering (mainly the cost of converting the float4x4 LocalToWorld values to matrices in arrays for Graphics.DrawMeshInstanced). It would be great if Unity’s TransformSystem just handled it… but it looks like I can manage without, if needed.
Why are you using custom rendering instead of the Hybrid Renderer?
Because I am careful about the dependencies I introduce in my project. Don’t want to pull in stuff unless I absolutely need it. At this point in time, I’m not yet convinced I need the hybrid renderer.
Well considering the Hybrid Renderer directly uploads the matrices to the GPU in a parallel Burst job, and considering it does a bunch of other performance-sensitive things like instanced properties and frustum culling also using parallel Burst jobs, I would argue that unless you are using built-in RP, you are just reinventing the wheel here.
@ I’ve made a game called “Rocket Science”. You can build any spacecraft here attaching parts to each other. And I implemented this system using a flat hierarchy. Yes, you need a bit more work to make a connection failure logic, but there will be no problems with insanly deep hierarchy.
I’m aware of that. I may very well adopt the hybrid renderer further down the line… but it is also a big package that does a lot of things I don’t want. I’ve learned that hard way not to throw things into my project willy-nilly.
How do you keep the hierarchy “flat”? Or do you simply mean you are using a different mechanism from Unity’s standard parent-child relationships to keep the modules of the spacecraft in your game aligned relative to each other? Are the connections between modules “static” or do you also have moving sub-sections? I.e. I may have 100 modules in a row, then a centrifuge with four arms of 10 modules each and then yet more centrifuges attached to those arms. And the whole contraption can move too. One way or another, I am tracking parent-child relationships between the transforms of all those modules…
