Dec 2019 - saberThing updates and Oculus Quest
SaberThing updates from the demo release until now:
Displacement moved from cpu to gpu:
Since July the biggest update has been to the displacement feature which melts or gouges a trench into a cuttable object. In past releases this was done entirely in the mesh by tessellating where more detail was needed and then displacing afterward. This created some complex meshes that would trip up the cutting mechanism, but capping in particular, and would result in holes appearing in the cut meshes. I've kept the tessellation but moved all of the displacements to the shader which has allowed me to crank up the depth which looks much cooler. It moves a lot of the computation from the cpu to the gpu which seems to stabilize some of the framerate dips.
Here is the latest video in my youtube archive where according to the description, I discovered a fix to the shadows. Ostensibly, after you displace points in a vert shader you also have to update the shadows. This is a glitch that I noticed but as far as knowing that something didn't always look right, but I didn't know what I was seeing until I was working on another project that I'll talk about in another post:
That's the PC/SteamVR version...
But lately I've been looking into the possibility of porting to Oculus Quest and maybe even Oculus Go...
The road to an acceptable version of the game was a bit bumpy. When the project began I had stripped down saberThing to an ugly but functional version that runs on the Quest, but only if I compiled as a "development build" for some reason... And I was getting maybe 60fps with all of the mechanics dialed down and background geometry turned off. The big disappointment to me was that I couldn't get the saber to glow due to the postprocessing stack not working with the Lightweight Render Pipeline.
I ended up choosing high framerates due to the use of the Lightweight Render Pipeline over the beauty of the Post Processing Stack. Over the next couple weeks I was able to settle on Unity version 2019.1.2f1 , Lightweight Render Pipeline package version 5.7.2, and Oculus Integration 1.41... Actually, other versions of Oculus Integration work, but while we were jumping through hoops to get an alpha uploaded into the Oculus store we downgraded to 1.41, only to discover that we unintentionally released for Oculus Go/GearVR.
Let's be realistic about the Lightweight Render Pipeline for a second. As soon as I installed it all I saw was pink everywhere and the Oculus controllers didn't show up. All of this is due to the fact that the LWRP doesn't support standard surface shaders which is what everything in my scene was using. There is a command somewhere in the menus that converts all of your shaders to LWRP except so many of my shaders are custom that I needed to go through one-by-one. Maybe I should just show you the latest video capture:
Apologies for the out-of-sync audio which is how it comes out of the Oculus Quest recording feature. I'm in too much of a rush to fix it :( I have to get over my perfectionism to get these blog posts done before the end of the year ;)
So, this version benefits from all of the tricks I picked up while working on the freelance gig I referred to earlier. After nailing down the Unity version and package versions, and after fixing the development build requirement (I think it just required a reimport of everything)... for the longest time I assumed that Fixed Foveated Rendering on the Oculus Quest was installed correctly. I mean, it was added via this one line of code:
OVRManager.fixedFoveatedRenderingLevel = OVRManager.FixedFoveatedRenderingLevel.HighTop;
The thing is, it doesn't do anything, not if you're using LWRP anyway... So, literally last weekend (dec 14) I hit google hard to figure this out and the technique that worked for me involved hacking the "ForwardRenderer.cs", and the hack looks like this:
#if FFR_HACK
bool createColorTexture = false;
#else
bool createColorTexture = RequiresIntermediateColorTexture(ref renderingData, cameraTargetDescriptor)
|| rendererFeatures.Count != 0;
#endif
credit goes to many good folks at the unity forums on this page:
https://forum.unity.com/threads/fixed-foveated-rendering-on-oculus-quest-not-working.686662/
Just find the matching line of code and replace it with the hack code above. You'll also want to add "FFR_Hack;" to your Scripting Define Symbols in the player settings to enable the hack. This just makes it easy/convenient to switch the hack on and off.
but there's just one more thing you need to do...
So, to sum things up, this is my recipe for porting saberThing to the Oculus Quest:
Unity 2019.1.2f1
Lightweight RP 5.7.2
Oculus Integration 1.41 (but can probably go higher)
Embed Lightweight RP and employ FFR_HACK to get Fixed Foveated Render to work
Rewrite custom surface shaders to vert/frag shaders - in progress
and when stuff breaks consider running "reimport all" before exhausting other resources
I'm also constantly considering ways to restore either the Post Processing Stack or to write my own screen shaders to get the bloom effect back on to the lightsaber.
One last thing:
If you do decide to develop for the Oculus Quest, to get started quickly you will have to select Oculus Go/GearVR when you register your project on the Oculus Developer Hub because they do not allow Oculus Quest development until after they've evaluated your pitch document and decided that you are worthy. It's inconvenient and annoying.
And that's why there is an alpha version of saberThing on the Oculus Go Store (available by invitation only)... oh, it doesn't work on the Oculus Go (yet) because I never mapped the controller to work with the Go. But if it's possible I'll definitely release something there.
Here is the latest video in my youtube archive where according to the description, I discovered a fix to the shadows. Ostensibly, after you displace points in a vert shader you also have to update the shadows. This is a glitch that I noticed but as far as knowing that something didn't always look right, but I didn't know what I was seeing until I was working on another project that I'll talk about in another post:
That's the PC/SteamVR version...
But lately I've been looking into the possibility of porting to Oculus Quest and maybe even Oculus Go...
saberThing for Oculus Quest
For a long time I didn't bother trying to port to the Oculus Quest because I assumed it would be nearly impossible. I thought I was already pushing my "VR Ready" PC too hard. What changed my mind is I received a call from a company that wanted to hire me to make a saber game for the Oculus Quest... Actually, the way it went was I agreed to help them make a saber game and then they called back to say "Oh, by the way, it's going to be on the Oculus Quest". After shitting my pants I decided to devote all of my time to see if the port would be possible.The road to an acceptable version of the game was a bit bumpy. When the project began I had stripped down saberThing to an ugly but functional version that runs on the Quest, but only if I compiled as a "development build" for some reason... And I was getting maybe 60fps with all of the mechanics dialed down and background geometry turned off. The big disappointment to me was that I couldn't get the saber to glow due to the postprocessing stack not working with the Lightweight Render Pipeline.
I ended up choosing high framerates due to the use of the Lightweight Render Pipeline over the beauty of the Post Processing Stack. Over the next couple weeks I was able to settle on Unity version 2019.1.2f1 , Lightweight Render Pipeline package version 5.7.2, and Oculus Integration 1.41... Actually, other versions of Oculus Integration work, but while we were jumping through hoops to get an alpha uploaded into the Oculus store we downgraded to 1.41, only to discover that we unintentionally released for Oculus Go/GearVR.
Let's be realistic about the Lightweight Render Pipeline for a second. As soon as I installed it all I saw was pink everywhere and the Oculus controllers didn't show up. All of this is due to the fact that the LWRP doesn't support standard surface shaders which is what everything in my scene was using. There is a command somewhere in the menus that converts all of your shaders to LWRP except so many of my shaders are custom that I needed to go through one-by-one. Maybe I should just show you the latest video capture:
Apologies for the out-of-sync audio which is how it comes out of the Oculus Quest recording feature. I'm in too much of a rush to fix it :( I have to get over my perfectionism to get these blog posts done before the end of the year ;)
So, this version benefits from all of the tricks I picked up while working on the freelance gig I referred to earlier. After nailing down the Unity version and package versions, and after fixing the development build requirement (I think it just required a reimport of everything)... for the longest time I assumed that Fixed Foveated Rendering on the Oculus Quest was installed correctly. I mean, it was added via this one line of code:
OVRManager.fixedFoveatedRenderingLevel = OVRManager.FixedFoveatedRenderingLevel.HighTop;
The thing is, it doesn't do anything, not if you're using LWRP anyway... So, literally last weekend (dec 14) I hit google hard to figure this out and the technique that worked for me involved hacking the "ForwardRenderer.cs", and the hack looks like this:
#if FFR_HACK
bool createColorTexture = false;
#else
bool createColorTexture = RequiresIntermediateColorTexture(ref renderingData, cameraTargetDescriptor)
|| rendererFeatures.Count != 0;
#endif
credit goes to many good folks at the unity forums on this page:
https://forum.unity.com/threads/fixed-foveated-rendering-on-oculus-quest-not-working.686662/
Just find the matching line of code and replace it with the hack code above. You'll also want to add "FFR_Hack;" to your Scripting Define Symbols in the player settings to enable the hack. This just makes it easy/convenient to switch the hack on and off.
but there's just one more thing you need to do...
Embedding Packages:
You can't just start hacking into package code if it's owned by the package manager because it will just remove your changes the next time you open up unity. You actually need to go into your file system and copy the package code from the Library directory into the Packages directory. This is a mostly undocumented feature called "embedding" and after you do this, the Lightweight RP should show up as "in development" in the package manager window:So, to sum things up, this is my recipe for porting saberThing to the Oculus Quest:
Unity 2019.1.2f1
Lightweight RP 5.7.2
Oculus Integration 1.41 (but can probably go higher)
Embed Lightweight RP and employ FFR_HACK to get Fixed Foveated Render to work
Rewrite custom surface shaders to vert/frag shaders - in progress
and when stuff breaks consider running "reimport all" before exhausting other resources
I'm also constantly considering ways to restore either the Post Processing Stack or to write my own screen shaders to get the bloom effect back on to the lightsaber.
One last thing:
If you do decide to develop for the Oculus Quest, to get started quickly you will have to select Oculus Go/GearVR when you register your project on the Oculus Developer Hub because they do not allow Oculus Quest development until after they've evaluated your pitch document and decided that you are worthy. It's inconvenient and annoying.
And that's why there is an alpha version of saberThing on the Oculus Go Store (available by invitation only)... oh, it doesn't work on the Oculus Go (yet) because I never mapped the controller to work with the Go. But if it's possible I'll definitely release something there.
Comments
Post a Comment