Neos-Metaverse / NeosPublic

A public issue/wiki only repository for the NeosVR project
193 stars 9 forks source link

Native floating origin support (For large worlds) #2648

Open Aerizeon opened 3 years ago

Aerizeon commented 3 years ago

Is your feature request related to a problem? Please describe.

Currently, items placed far away from spawn will encounter visual glitches and movement impercision due to floating-point errors.

Users will begin seeing UI rendering issues, even on their dashboard and local UI elements.

Near the edge of the world size limit, the UI becomes almost unusable, and models are heavily distorted.

Relevant issues

No response

Describe the solution you'd like

A native implementation of a floating origin system, which allows for a much larger useful world size.

This, combined with some creative culling of objects, can allow for worlds that are larger and more detailed.

Describe alternatives you've considered

It may be possible to implement this in logix, however managing state and relative transforms of users is complex and less performant than a native implementation.

Calculating user transforms, especially those who are in VR with a significant playspace offset, is difficult.

Additional context

No response

shadowpanther commented 3 years ago

The link is broken, here's the proper one: https://wiki.unity3d.com/index.php/Floating_Origin

Aerizeon commented 3 years ago

@shadowpanther Thanks. The new forms system hates mobile, and was doing all kinds of weird things to the text.

Frooxius commented 3 years ago

Support for large worlds is something we plan on adding in the future, so you can have potentially infinitely spanning worlds, but we are not fully decided on the solution for it yet.

I don't think this exact implementation would work or mesh well with Neos and how it and its subsystems work. Generally we discourage asking for specific technical solutions, but rather focusing more on the underlying problem (in this case being able to have large worlds and running into floating point errors).

Currently the general idea is to allow splitting sessions into "chunks/domains" as well as allowing multiple of those to be loaded in parallel and positioned relatively to each other. Each chunk/domain could have its own coordinate and that could be used to keep the actual coordinates near the center, while also keeping coordinates within the chunk within a small range.

This is a pretty major feature though, that will require some significant engineering, but would solve this problem, as well as class of others and open up some new possibilities. However it's very early for that right now.

As for the floating origin system, I don't think we'd implement it directly. Some principles will be there, but right now it's a bit too early and the focus is elsewhere for the time being, so a lot of things around this and how we approach it can change.

shadowpanther commented 3 years ago

Karel mentioned seamless fencing recently: https://discord.com/channels/402159838827905024/468504846522384394/843803915698569276

Frooxius commented 3 years ago

Yes. That'd be part of the chunks/domain solution. The main performance would be one session, while you'd have another session with your friends on top of that. The performance session would be streamed and "read only" as a result, meaning you won't be able to change it, but you could do lots of stuff on top.

Aerizeon commented 3 years ago

This still feels like it would constrain the effective size of a "region", since you'd still run into floating point errors unless the user's transforms were reset somehow

Frooxius commented 3 years ago

Yes, the size of the region would be limited by design, but the size of the overall world would be theoretically infinite. The transitioning between those regions would also be made seamless, so the coordinates would get recalculated as you move between them.

This is necessary, because if the transform moved too far, you would still loose the precision in pose anyways, even if rendering wouldn't be glitchy.

The solution isn't designed and engineered at this point and it's not something we focus on right now, so I wouldn't go too much into the technical details since this isn't the current focus and we need to spend some time engineering them in the first place.

Once this becomes the major focus, we can get more in depth into it, for now I'd just keep track of this for general interest and as something on the long term roadmap: https://github.com/Neos-Metaverse/NeosPublic/projects/1