Problems and ideas related to NoClip locomotion #1141
Replies: 5 comments 4 replies
-
Maybe that'd be something for a "NoClip-lite"? So you'd have true NoClip with zero collider interaction for developing things without triggering systems or such, and a "general use" NoClip, where movement is the same and only static character colliders are ignored. |
Beta Was this translation helpful? Give feedback.
-
We could introduce additional locomotion systems, but NoClip fundamentally means that it doesn't clip - in other words, it doesn't interact with colliders and triggers. The reason we dismiss this is that you're asking us to make NoClip into something it's fundamentally not and typically such decision lead to "design smell/rot", which we try to avoid wherever possible. The bigger underlying problem here is that current culling systems are using triggers for culling, which is not ideal - it's just the only thing you can do right now. Instead, we should address this, rather than working around the limitation and changing different part of the system to compensate. Better approach for this that keeps the design "clean" is we introduce a separate spacial query system (probably still using same physics acceleration structures) for culling purposes, which can be active at all times, regardless of locomotion mode. If you think about it, there are other fundamental issues with using the character collider for culling:
From the sound of it, once we implement such system for culling, that would resolve your major problem with NoClip. You also have option of customizing NoClip in the meanwhile too - technically you should be able to add a character collider to the template parented under it. |
Beta Was this translation helpful? Give feedback.
-
For worlds you design, my suggestion is driving a small collider to the local user's view position, and use that to detect which "culling zone" the local user is in. This works regardless of locomotion and should be a good solution with the tools currently present in the game. I'd avoid systems that require modifying the default locomotions if possible, since that makes them dependant on those locomotions and might break once users introduce custom ones. |
Beta Was this translation helpful? Give feedback.
-
Right now you can use bounding box protoflux nodes to check if a user is within a certain zone. It even works in noclip. |
Beta Was this translation helpful? Give feedback.
-
Also what Frooxius said about parenting a 'fake' character controller to the user would work too and this is something we did in Transposer to allow collider-based culling to work when your view is moved to another location. |
Beta Was this translation helpful? Give feedback.
-
The NoClip locomotion module is great and I think it could be even better. It's particularly useful for development work, but also a very popular locomotion module to use in other contexts (e.g. social sessions where obeying physical constraints isn't important). Users in NoClip are separated from large parts of the physics system, particularly colliders. This is usually good, however I find there are many situations where I only want to ignore some colliders. As such, I think there is room to improve the current NoClip locomotion, or to create something new, which would enhance the user experience.
The problem
I find the NoClip feature of ignoring all colliders to be a problem when one wants to do something based on where the a user is. The physics system is specifically designed to handle this kind of situation efficiently. However, often one wants such a system to work when a user is in NoClip as well. Therefore, one is sometimes forced to use sub-optimal and/or more complicated approaches to accommodate that requirement.
Culling systems as a specific example
The most obvious case in point - culling systems. These are usually implemented such that certain parts of a world hierarchy are deactivated based on a user's position (potentially alongside other factors). The simplest and most efficient way I know of doing this is to use primitive colliders with the ColliderType field set to Trigger in tandem with ColliderUserTracker components. One can then use the values exposed by ColliderUserTrackers to determine which parts of the hiearchy are active for specific users. In order to make such culling systems work for NoClip users it is necessary to either add additional complexity and/or to use a less efficient method of position checking.
In the past I have seen some Resonite team members dismiss the incompatibility of NoClip and ColliderUserTracker-based culling systems by stating that NoClip is for development and in development everything needs to be visible. However, in my experience, it is important that culling systems can be implemented during the development process (i.e. at a time when users may be using NoClip a lot). I have been through at least 2 world builds (Rocky Retreat and Deep Dreams) where the world is large enough that a culling system was required to keep framerates tolerable during development. In both cases we had to use a less efficient option than we would have liked.
Related to this is the preference for allowing use of NoClip in non-development contexts. Again, user position-based systems can be an issue. For one world we published, we received comments from multiple users that they would like to use our world to hang out, but that they didn't because it was incompatible with NoClip. Obviously we would prefer to be able to accommodate those wishes while still using the most efficient systems available. I have heard it argued that NoClip is intended for development only and that users should therefore not expect to be able to use it in social situations (and that therefore incompatibilities like the one described are non-issues). I disagree with this. In my opinion, it would be better to support users in the ways they wish to experience VR even if those are not what was originally intended. Interestingly, I note that the Resonite team appears to have struggled with this very issue in the official cloud Home; a workaround seems to have been implemented there to make certain features compatible with NoClip.
Ideas about a possible solution
For me, I think the main benefits of NoClip over physical Fly are:
On the other hand, I find that usually I still want to interact with Trigger colliders while in NoClip. I suspect that this is many other users' experience as well.
I would be interested to hear from other users whether they have similar experiences and from the development team as to what might be feasible in accommodating these preferences.
Beta Was this translation helpful? Give feedback.
All reactions