As a developer it is annoying to get the world cframe of an attachment
Every other property has a world space version. CFrame is excluded. Kinda weird.
As a developer it is annoying to get the world cframe of an attachment
Every other property has a world space version. CFrame is excluded. Kinda weird.
That suggestion is unrelated?
o o p s
I tried using Attachment.WorldCFrame
the other day and was genuinely surprised it didn’t exist.
This has been a standard in any game engine that uses a scene graph implementation (which attachments essentially do) so this would be really good to have added.
Examples of implementation in other libraries / engines:
http://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_node.html#a58997cd5600d78e6579bba77f2bc8fa7
(Note: Unity uses position
as the position derived from parent matrices)
https://docs.unrealengine.com/latest/INT/BlueprintAPI/Utilities/Transformation/GetWorldTransform/index.html
Attachments are used for defining a cframe relative to an object. That is their fundamental purpose. They are made easy to place, orient and move. There are tools for this in studio. Attachments are used for creating rigs, for defining datapoints for trails, for attaching accessories to characters, and for other various reasons in the engine. Developers use them too in their own systems too. Unfortunately, developers must program using this redundant computation to achieve what seems to be their primary use.
attachment.Parent.CFrame * attachment.CFrame
As a developer, it is expected that there would be a WorldCFrame property readily available to read.
Usecases