-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add globalPosition
getter/setter to Transform
#1032
base: main
Are you sure you want to change the base?
Conversation
Deploying js-sdk-toolchain with Cloudflare Pages
|
Test this pull request
|
|
||
helperArray.length = 0 | ||
let currentTransform = null | ||
if (transform.parent !== undefined) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not going to work for network entities.
We should include some logic here for that, like if the entity is marked as sync, look for the network parentEntity instead of the transform.parent
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can take two path for this, as it doesn't work with AvatarAttach nor Billboard neither:
a. We add the disclaimer comment to get noticed when this accessor is approachable or not.
b. We proper implement all the possibilities and get this feature reliable.
In case of a) we can move forward with the current implementation and add the comments
In case of b), my question is, is there any mechanism to get the globalPositon so far? Because what I saw in Utils library, this is not implemented. The current getWorldPosition
and getWorldRotation
doesn't take into consideration the scale
.
This is a PoC to have
Notes:
AvatarAttach
Also, this research is to have a test for performance and if it's a viable option to implement further in more components (like the ones with oneOf and make their interactions seamless)
Transform is like a very fetched components, the most representative scene to compare the performance (measured with OpCode count executed) is the
cubes
scene where:These metrics doesn't say anything about the property added. Instead, it shows how expensive it is to add the a value patcher to implement custom non-data properties.
This would be very useful to add something like:
.move()
,.rotate()
, etc.textureSource
(getter and setter without going deeper due to the particular $case.play()
... and so on.
This approach takes distance from the pure-ecs one, but it provides quality of life for developers. They should be taken into consideration and evaluate the pro/cons each case.