Hi
I’ve created a walkthrough which works great in desktop mode, but in vr mode non of the collisions work. This isn’t ideal because it means I cant restrict the user to an intended area. For example users can float through walls and floors to non populated areas of the scene.
I suspect this may be a deal breaker for my client.
Cheers
Michael.
The suggested approach for the VR mode is not to stop the camera movement when the head virtually collides, because physically the head is still moving, and displaying a still camera image could cause motion sickness.
What can be done for this issue is to somehow discourage the user from colliding with objects (mostly crossing the walls). In the case of Shapespark it could be making the non-populated room completely dark or hiding the room in the view destined for the VR mode. Do you think such a solution could work for your case?
hmm, I see your point. It’s a tricky one.
My main concern is that because i’m lighting the inside of the building with the sky light only, the exposure outside the building is incredibly bright, compared to the inside, so will look terrible if people accidentally wander through a wall. So I’m splitting the exterior and interior into two seperate VR files. Perhaps you could add a portal material which can be assisnged to windows panes?
This way you could add the portal material to the windows, and then have a multipler slider to control how much it amplifies the light coming from the backface (light travels in the direction of the normal). Then you could have one light setting for entire scenes and still get similar exposure outside and inside.
Turning down the skylight and instead lighting the internals with many lights is slower to render and not as realistic i’ve found.
But yes, an outer boundary would be good too, which displays just blackness, or a starfield with a “go back to scene” warning in semi transparent flashing green text perhaps.
Thanks for the feedback and ideas. Amplifying the light when it comes through a portal is an interesting idea. A somehow similar approach would be to allow for transparent area-based emitters - in this case the light intensity would not be multiplied but summed.
I beleive cycles has a portal light already. Perhaps a naming convention could be used so that on import objects named portal could be replaced by portals?
Yes, this is one approach that could be taken. Another is to introduce a material property that would make all objects with this materials amplify/sum light intensity. In this case creating additional portal objects might not be needed, since it could be enough to set this additional property for window glass material, for example. And if one required a portal in some other place than windows a “portal” could still be added by creating a planar object and applying such a material to it.
That would be even better wojtek (the same as how fstorm works), i’m not sure cycles has a portal material though?
If it does though definitely would be great, as this will also mean non rectangular objects can act as portals, such as round windows, or curved glass.