Sinespace Pursues The “Second Life Of VR”

Sep 20, 2018
69
#2
A VR person talking to another person who may or may not be in third person seems to entirely destroy all immersion on the side of the VR user... just saying.

Like, what's the point of even looking them in the face, they aren't there...
 
Sep 20, 2018
23
#3
I think that neglects the fact that users are going to come in on a lot of devices - mobile in particular at least in the short/medium term I think will outnumber desktop and VR by a heavy margin. (If you look at what people actually are using - there's been a pretty big shift in the way general consumers access the internet over the past decade)

We're about accessibility - yeah some users wont be in VR there, but there's some pretty neat ways we can still bring the user 'there', the webcam capture thingie we've got is still one of my favourite toys (see the end of this vid: ) and a good way of bringing desktop users into the environment more physically without needing any expensive gear (standard laptop cam works - although some facial coverings like glasses can obscure the tracking)
 

Nadeja

New member
Sep 21, 2018
20
#4
I think the immersion is a good point, but I agree with Adam. And it's true regarding the mobile too: IMVU has 10+ million downloads on Adroid, Roblox 100+ millions! I don't know on iOS, but they should be further many downloads. However, I wonder if an optional icon that tells who is running Sinespace in first person view could help? Maybe next to the avatar name. Maybe optional.

Talking about first person view and immersion, in Sinespace it would be nice if my avatar could be visible to me, when I zoom up to first person view. :) To understand what I mean, on Second Life / Firestorm, you have an option that makes your own avatar visible when you go in "mouselook" first person view. Then if your avatar follows your point of view, as you turn the cam by holding the right mouse button down, that would be even better IMHO. I think at it as an option, so who likes it, enables it, else turns it off / leaves it disabled.
 
Last edited:
Sep 20, 2018
23
#5
We've toyed with keeping avatar visible in first person view in the past - the problem is more stuff on the head/face/etc can occlude and get in the way of the screen. If we brought it as a optional feature, it'd definitely have to be default-off as the results aren't always pretty.
 
Sep 20, 2018
69
#6
I know, cough.. other games.. *cough* solve this issue by scaling the head bone down to zero locally only, That way head geometry never gets in the way of the camera.

Makes shadows and reflections require a separate pass so they aren’t headless
 
Sep 20, 2018
23
#7
Yeah that's a decent way of solving that problem - clever! Only problem is indeed the shadowpass, we're avoiding forward rendering where that'd be simpler; so it might be easier to instead slot in a generic invisible head, otherwise we'd have to have a second copy of your av in hiding (which is fine, but a bit render-expensive)
 

Nadeja

New member
Sep 21, 2018
20
#8
What happens if you try to move the camera offset further away in front of the the avatar eyes in first person view then? Maybe calculating the size of the head and whatever accessory in front of the eyes just once, when you save your look. Is something like that possible?
 
Sep 20, 2018
69
#9
What happens if you try to move the camera offset further away in front of the the avatar eyes in first person view then? Maybe calculating the size of the head and whatever accessory in front of the eyes just once, when you save your look. Is something like that possible?
That does not feel good in VR, out of body experience and your shoulders/arms are not where you expect. Can’t get away with fudging things as much in VR.

If you look down your feet would be in back of you. Hard to tell on a computer monitor, but obvious in VR where you have a proper sense of volume, size, distance, and position.

Source: SL does this (first person view floats about 1.5 feet in front of avatar’s face) and it felt very bad in Vr when SL actually supported VR.
 
Last edited:

Argent Stonecutter

Emergency Mustelid Hologram
Sep 20, 2018
381
Coonspiracy Central, Noonkkot
Joined SLU
Sep 2009
SLU Posts
20780
#11
I just tried to get into Sinespace in VR, now I have a headset, and it was a complete disaster. You need to download a beta client, it takes FOREVER to start up, and another FOREVER to download enough of the room to see, and I didn't wait a third FOREVER for all the avatars to rez in.

the only way you seem to be able to move is short distance teleporting.

Turning your head may or may not turn your point of view.

Sometimes your point of view turns based on where your right controller is pointing.

I couldn't even.

I have a Samsung Oddysey Plus, my computer has 64G RAM and two six-core Xeons and a gtx 1070 founder's edition. My network is super fast now, with little latency: I can fly across as many sim boundaries in SL as I want without getting thrown offworld or losing my plane. It's not me.
 
Sep 20, 2018
23
#12
Heya Argent, I haven't tested the Oddsey+ but that sounds like something with the controler inputs is FUBAR. There's a rework of our VR controllers in the next public release, which I am hoping will iron out a few issues - although this sounds like a new class of problem; albeit due to the fact we're using SteamVR, this sounds more like a SteamVR picking up the wrong controllers.
 

Argent Stonecutter

Emergency Mustelid Hologram
Sep 20, 2018
381
Coonspiracy Central, Noonkkot
Joined SLU
Sep 2009
SLU Posts
20780
#13
The controller issue is probably an easy fix. You need to use the WMR API or use the touchpad for moving because there's a problem with the thumbsticks mapping in SteamVR.

HiFidelity uses SteamVR and it's fine, again, you just have to use the touchpads.

SteamVR works fine in the SteamVR home, VRChat, High Fidelity, everything else I've thrown at it.
 
Sep 20, 2018
23
#14
We're currently in the process of switching to a more agnostic API - should help there I suspect, but we've been avoiding the WMR native API since it's really geared towards UWP apps (which unfortunately, try as we might, throws up more issues than we'd like.)