Transforms are useful

[reeseschultz]

The example of dividing a transform in the docs misunderstands the point (no pun intended) of a transform. Quote:

What do you notice? Exactly... you iterate over all Transforms to update the position... and later you iterate over all transforms to update the rotation. This is a no-go, why do you iterate over Transform if you really just need to access the Rotation from it?

This will slow down your query since the CPU needs to load more data into the cache, unused data. Since when you iterate over Transform to update its Rotation, you also load the Position with it... which in this case is not necessary and slow.

This isn't wrong, but I'm concerned that the way it's presented could set some impressionable Arch users astray. I'll explain why.

In the simplest, most trivial case, a transform as one component is in fact wasteful but only when:

1. Everything has a referential frame in world space because there is no hierarchy
2. The renderer lacks geometric complexity

Even for simple games, however, that's almost never the case. Normally frequent transformations are demanded between local and world space, so it's invaluable to have a transform with access to the position, rotation, and scale as local members. Otherwise those constituents, as separate components, must 1) be separately queried, and 2) have their values passed to some function every single time a transformation occurs. This is annoying when implementing logic for a game, because focus must constantly downshift to a level of abstraction that is not game-oriented.

What's ultimately being advocated for in the docs doesn't just lead to parameter spaghetti, but also it's more error-prone. Since the position and scale would be something like Vector3s or Vector2s, accidentally mixing them up would be easy. It's obviously less error-prone to handle this in one place, with supporting unit tests for that one place, abstracting the parameter passing away, rather than essentially testing correctness every single time this commonplace operation is performed.

---

In my opinion, the example should discuss approaching the transform as a tradeoff. I want to emphasize that I don't believe the docs are wrong, but they're not even-handed with respect to this concept. People are not wrong for choosing tremendous convenience over slightly better performance. We also shouldn't assume what people are developing with Arch--you never know, they might be building an API with developers as the audience. Even when I'm my own audience, I need some convenience to get things done.

If nothing I've said thus far is convincing, then just look at any game engine. Bevy, ECS extraordinaire, uses transforms. In fact, its Transform is local-space by default, whereas the separate GlobalTransform is world-space. Notice all the convenience functions that go along with them? It's because you need them to be productive.

I'd be happy to help modify the language of the docs to something more judicious.

[genaray]

Hmmm I had not thought about that at that moment. But you are right. Instead, it should be described as a trade-off. Can you think of a better example of what the seperation could be? ^^