-
Notifications
You must be signed in to change notification settings - Fork 925
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
[feature request] Implement floating origin on geolocation ar #499
Comments
@marcusx2 I see what you mean. As it happens the older location-based components (not However, in the light of what you have said, I can add it back to I am slightly concerned about updating the world coordinates of the objects, though, as this may impact performance particularly if you have large numbers of objects. Perhaps that can be added in as an optional feature? So, for the next release I will optionally restore the original behaviour, i.e. world origin is the initial GPS position. To avoid breaking existing code, however, it will not be the default, it will require a flag to be passed in. |
Hello @nickw1 , thank you for your reply.
This would certainly help a lot and fix most cases. It would only break if the user started using ARJS too distant from the entities anyways. On this case the world position of the camera would end up on gigantic values as the user finally arrives at the locations and the problem would happen again.
As an optional feature it would be great, I don't mind. Like I said, having an optional threshold to reset the camera to world origin and the other entities to correct relative world position would be great! (e.g. threshold is 5000, which means world position is 5000 on either axis). Of course if an entity relative to the camera is on a distance bigger than the threshold, it wouldn't even show up! Will you implement floating origin as well? |
Maps service has this feature too. |
@nickw1 is this change hard to do, can you guide me through it? If you can send me the modified version with just this change I'd greatly appreciate it. If it's not something trivial then never mind, I can wait until next release. Thanks! |
@marcusx2 it's actually quite easy but I haven't had the time this week. I will do it as soon as I can. |
Hopefully a movefloatingorigin method can also make it to a next release together with |
OK what I think I'll do is implement #498, #499 and #502 for the next release (bugfix release 3.4.4), keeping this as an optional for the moment (but will probably make it the default in 3.5). Your other issues are a little more complex, and perhaps less critical, so will leave these to a later release. |
I think you mean you will implement initial gps position at world origin for the next release, but not the floating origin(movefloatingorigin method) which is this issue. It's because implementing initial gps position at world origin is the first step. I'd say #498 is the most critical, then comes the rest. Ok I understand. Thank you very much, looking forward to the next bugfix release! |
#508 allows the initial GPS position to be used as the world origin. The floating origin however will require a rewrite of part of the code so I'm proposing postponing it for the 3.5 release, and at that point, introducing a breaking change of making the initial GPS position the world origin by default. |
bump |
1 similar comment
bump |
What is the current behavior?
Currently, the world position of entities(and the camera) when using ARJS' aframe geolocation AR can have values on the millionth scale. From my tests, it can vary between(more or less) -20million to 20million. The problem with this is for other frameworks that wants to use ARJS solely to retrieve the position information for placement and have floating point precision problems. Take a look at this issue. It's exactly what I'm facing. I successfully managed to use ARJS' geolocation (aframe version) to position objects in another framework such as PlayCanvas, but I am running into this problem.
Ideally, I'd like a feature where the camera's world position stays at (0, 0, 0), and there's a threshold property that when met, centers the camera to 0, 0, 0 again and repositions the entities around it. See this short video (from this plugin, consider that the avatar shown is the camera and everything around are the aframe entities. What moves are the entities around the camera, not the camera itself) which showcases exactly what I'm looking for. Example camera's position is (20000000, 0, 0) and entity is (20000001, 0, 0), camera becomes (0, 0, 0) and entity (1, 0, 0). The distance stays the same but now the values are small and avoid the floating point precision problem.
I am currently implementing this floating point origin to fix the issue I'm having, but I think it would be nice if this feature was available out of the box for ARJS' geolocation AR so that it can be easily used by other game frameworks that have problems with floating point precisions (which seems to be literally every other game framework except aframe lol).
Other useful resources
https://docs.unity3d.com/Packages/[email protected]/manual/Camera-Relative-Rendering.html
https://www.youtube.com/watch?v=qIxifMcvYTs
https://manuel-rauber.com/2022/04/06/floating-origin-in-unity/
https://www.reddit.com/r/Unity3D/comments/ijwfec/the_further_you_are_from_000_the_messier_stuff/
https://www.alanzucconi.com/2020/08/03/floating-point-arithmetic/
@nickw1 what do you think?
The text was updated successfully, but these errors were encountered: