Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1374752 Posts in 65013 Topics- by 57240 Members - Latest Member: DonutProductions

March 28, 2020, 04:28:33 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsDesolus: A Surreal First Person Puzzle Game
Pages: 1 ... 18 19 [20]
Print
Author Topic: Desolus: A Surreal First Person Puzzle Game  (Read 63091 times)
Mark Mayers
Level 5
*****



View Profile WWW
« Reply #380 on: December 22, 2019, 12:27:22 PM »

It looks like this project has been around for a while, but I'm just finding it now. It looks fantastic! Definitely going to be keeping an eye on this one.

Toast Right
Logged

Desolus Twitter: @DesolusDev Website: http://www.desolus.com DevLog: On TIG!
clickbecause
TIGBaby
*


View Profile
« Reply #381 on: January 24, 2020, 02:46:20 PM »

Hi Mark,

Amazing work! I stumbled on this devlog while doing research on GPU based "portal" implementations. I'm working on a project that revolves around some similar ideas (periods of time instead of alternate universes). Would you be willing to talk a bit about how your universes are organized? For example, are both universes located in the same physical space and only rendered differently? Or are they actually discrete terrains that are offset in world space? Are they both present in the same Unity scene file?

I've been throwing tons of ideas at the wall and found a few promising solutions, but you are soooo much further ahead of me and I would love to learn from your experience implementing this idea. Thanks!
Logged
Mark Mayers
Level 5
*****



View Profile WWW
« Reply #382 on: January 26, 2020, 03:06:22 PM »

Hi Mark,

Amazing work! I stumbled on this devlog while doing research on GPU based "portal" implementations. I'm working on a project that revolves around some similar ideas (periods of time instead of alternate universes). Would you be willing to talk a bit about how your universes are organized? For example, are both universes located in the same physical space and only rendered differently? Or are they actually discrete terrains that are offset in world space? Are they both present in the same Unity scene file?

I've been throwing tons of ideas at the wall and found a few promising solutions, but you are soooo much further ahead of me and I would love to learn from your experience implementing this idea. Thanks!


Hey! Thanks for reaching out.

I've talked a bit about how the rendering works in Desolus in previous posts, such as this one from last March.

The very first prototype of the alternate universe mechanic which is the basis of the game was back in May 2016.
This was a simple stencil buffer mask done with shaders.

However, recently I've been moving over to Unity's Scriptable Render Pipeline and completely building one from scratch.
The new pipeline is almost finished (I'll post about it over the next week or two), but it changes the rendering system a bit.
I talked a bit about my motivations to switch to SRP in the last DevLog entry.

Over the years though the portal rendering in Desolus has become pretty sophisticated, as the technology needs of the game improved.

I'm not sure exactly how deep down the rabbit hole you would like to go.
However, I would probably start out with researching shader tutorials on the stencil buffer.
Logged

Desolus Twitter: @DesolusDev Website: http://www.desolus.com DevLog: On TIG!
Mark Mayers
Level 5
*****



View Profile WWW
« Reply #383 on: January 26, 2020, 08:01:07 PM »

Update 150: 01/26/2020

SCRIPTABLE RENDER PIPELINE, PART II

(PART I)

Over the last month I've made a huge amount of progress in creating my own Scriptable Render Pipeline for Desolus.

At the beginning of January, I completed my lighting model and added shadows to Desolus.
Since then I have been porting all of my shaders over to HLSL, and have been building the rest of my SRP.  

---

FINISHING OFF THE LIGHTING



Earlier this month I finished off my BRDF lighting model for Desolus.
The lighting model is superior to Unity's standard shader, as I'm using my own custom BRDF which I discussed in the previous post.

You can see the gradient of metallic and specular values of materials in the above image.
Compared to last update, I fixed a few mathematical errors in my code which led to incorrect lighting.

Although the function is tweaked with a art-directed values (like the small amount of Fresnel) it's still primarily physically based.
This physically based rendering workflow allows me to create a diverse set of materials, simply by tweaking the metallic and specular properties.

---

CREATING SHADOWS



Implementing shadows was a large amount of work (about 3 days of programming).
However, I was able to implement a version based on Catlike Coding's SRP series.

Again, I would highly recommend Catlike's SRP documentation series, and Unity's own SRP documentation is practically non-existent.

These shadows are high-quality cascaded shadows, with tweakable resolution and shadow filtering.
Because they are still using some of Unity's API, they integrate into the existing shadow functions which can be set per directional light.

---
Logged

Desolus Twitter: @DesolusDev Website: http://www.desolus.com DevLog: On TIG!
Mark Mayers
Level 5
*****



View Profile WWW
« Reply #384 on: February 25, 2020, 12:58:25 PM »

Update 151: 02/25/2020

SCRIPTABLE RENDER PIPELINE, PART III

Most of the time between January and February 2020 was spent on further implementation of the scriptable render pipeline.
Fortunately, it's almost done!

Below is a step through of how everything in the game is rendered so far.

---

SHADOW MAPS



Rendering shadows in games can be fairly complex, but fortunately I had ample amount of reference.

Desolus is currently using an 8k resolution shadowmap, with four cascades.
Additionally, I am using a 7x7 Percentage Closer Filtering algorithm to drastically smooth shadows.

You can read more about implementing shadows in the reference link.

Inspecting the shadow maps in Unity's frame debugger is pretty neat, they're almost like architecture prints

---

DRAWING GEOMETRY



After the screen is cleared from the shadow pass, I draw normal geometry to the screen.

Drawing geometry in Scriptable Render Pipeline is considerably more efficient with draw calls, due to Unity's 'SRP Batcher.'

As you can see from this screenshot, I am drawing a considerable amount of modular geometry on screen.
Normally, this would result in a great deal of draw calls.
However, because of Unity's SRP batching system, the draw calls are highly optimized to reduce CPU load.

You can see the lighting of my BRDF model at work here. I gave the architecture in Desolus a slightly metallic property.

Additionally, I opted instead of using Unity's fog model, to use Inigo Quilez's fog.
This model is significantly better, as Unity's fog is not based in world-space distance and instead based in view-space distance.
Using this fog model, rotating the camera doesn't distort the fog color.

---

DRAWING INSTANCED GEOMETRY (PARTICLES)



Desolus uses my own custom implementation of TC Particles, which is written by my friend Arthur Brussee whom I worked with on Manifold Garden.

I have been using the particle system since the very first builds of Desolus.

TC Particles is highly performant and allows for GPU particles which run in a compute shader.
Although the system is a bit old, as it was created in 2014, it was considerably ahead of its time in that Unity was still using CPU particles.

I briefly contemplated migrating to Unity's VFX graph (as it also supports GPU particles).
However, the VFX graph is DEEPLY coupled with Universal Render Pipeline and High Definition Render Pipeline, and I would rather not deal with porting it.

Instead, I opted to port TC Particles from Unity's old pipeline to my own custom SRP.

For anyone else porting similar systems, there are a few critical differences between Unity's old API and the new SRP API.

  • Functions like OnRenderImage() and Camera.OnPreCull() no longer work.
    If you're designing your own SRP, you must manually place when to call your functions.
    Honestly this is a good thing, because the order of events is considerably less ambiguous and you have manual control.
     
  • Unity's 'Graphics' functions no longer work.
    For example, instead of using Graphics.DrawMeshInstancedIndirect, you MUST use the Command Buffer version instead.
    For each camera, pass in your Scriptable Render Pipeline's command buffer, and have it call this function if the object isn't culled.
     
  • All shaders must be written in HLSL, instead of CG, but you probably already knew this.

TC Particles processes everything in a compute shader, draws instanced geometry with C#, and then renders the result in a shader.
Fortunately, the existing code was modular enough in that it was primarily only changing over the API as described above.

Overall, the port took several days. However the code was written well enough that it was a clean and successful.

---

POST PROCESSING: COLOR CORRECTION



Another challenge with Scriptable Render Pipeline, is getting post-processing working.
To begin, I looked into Unity's own Post-Processing Stack. However, I opted to implement my own stack as the Desolus post-processing is fairly minimal.  

After all of the normal and procedural geometry is drawn, I begin rendering my post-processing stack for Desolus.
Currently, there are only two effects (Color Correction and Bloom), as the Fog is done within the fragment shader.

Despite the relative simplicity of these effects, there were a few challenges.
As I mentioned previously, in SRP the Unity graphics functions such as OnRenderImage(), no longer work. Additionally, there is no Graphics.Blit function.

A reasonable substitute for Graphics.Blit is CommandBuffer.Blit.
However, due to the restrictions with Unity's Blit (specifically with the stencil buffer, as discussed previously, I created my own 'Manual' Blit function.
This function simply binds the camera's color/depth textures to a material, sets the render target, and draws a static triangle mesh with the image effect material.

You can see the Blit in action in the frame debugger, under 'Draw Mesh.'
One draw is used to copy the current camera's color/depth buffer to a temporary texture with the image effect, and another to copy back to the render target.

After creating this, porting the color correction script was fairly simple. I've been using ColorCorrection.cs for ages, and the Desolus colors are graded very precisely.
Porting this involved transferring the old C# code to my new SRP post-processing stack, and copying over the animation curve vales.
Additionally, I translated the old Unity CG shader into HLSL.

It worked well! The port ended up being super clean, with a very small amount of code difference.

---

POST PROCESSING: BLUR AND BLOOM



A bit more challenging to port than the Color Correction effect, was the Bloom in Desolus.
After attempting a direct port of Unity's 'Optimized Bloom' and having it be considerably bugged, I almost gave up.

I began implementing my own bloom shader, after a bit of research. I successfully implemented this with my SRP, but the results were sub-par compared to my old bloom.
Additionally, from a production standpoint, I knew that *yet again* would I have to spend a considerably amount of time on color-grading.
The Desolus color grading process in total takes me about 10-15 hours to do, as it's very meticulously adjusting color curves and bloom values.

Knowing this, I got a bit of rest and tackled the problem again.
I ended up successfully porting over both the old CG shader, to HLSL and the old C# code to the SRP API with a bit of focus.

The bloom shader itself is a 'fast' Gaussian Blur which progressively down samples the image based on a certain number of iterations.
I have my bloom set to 8 iterations, with a billinear downsample for each texture.
This results in a large amount of 'Draw Mesh' calls from the custom Blit, but since Desolus is meant for desktop PCs, the performance impact is negligible.

Overall, this was also a clean port, albeit a bit more difficult.

---

FINAL IMAGE (SO FAR)



Although the basics of my SRP seems to be complete, I am still lacking a few critical features.

From a visual standpoint, there is no volumetric lighting.
My next set of work will be porting my existing volumetric lighting system over to my SRP, which could be challenging.

Also, most importantly, there is no rendering set up for portals between universes yet.
Although I (theoretically) perfected my approach in the old Unity pipeline, it's going to take a bit of work to implement in SRP.

Fortunately, I have total control over the rendering process so I won't have to fight Unity. Crazy

---
Logged

Desolus Twitter: @DesolusDev Website: http://www.desolus.com DevLog: On TIG!
amasinton
Level 0
***



View Profile
« Reply #385 on: February 28, 2020, 03:47:37 PM »

Fortunately, I have total control over the rendering process so I won't have to fight Unity. Crazy

---

Thank you for this in-depth discussion of how you built your SRP in Unity.  So many insights!  And it looks so so so good!  

With your experience and skillset you have really been able to seize the many, many good things 2019.3 offers, adapting your project to take advantage of the excellent performance and control opportunities of the new system.  You don't have to fight Unity, bend it to your will, as much any more because you have so much more control.  Very well done, indeed!

It seems like 2019.3 is a turning-point where Unity now favors users with deep engine and rendering knowledge over users with art and design knowledge.  In order to take advantage of the power that Unity offers, you now need to be able to create your own SRP, or you need to be able to re-structure your architecture to use ECS/Burst, etc.  You sort of make your own engine within the engine.  Is that concerning or liberating to you?

Thanks for your thoughts and keep up the inspiring work!  
Logged
Prinsessa
Level 10
*****


Ava Skoog


View Profile WWW
« Reply #386 on: February 29, 2020, 01:20:46 AM »

Aaaaa looking forward to reading this a bit later!!

Game is so pretty <3
Logged

Mark Mayers
Level 5
*****



View Profile WWW
« Reply #387 on: March 09, 2020, 07:01:46 PM »

Fortunately, I have total control over the rendering process so I won't have to fight Unity. Crazy

---

Thank you for this in-depth discussion of how you built your SRP in Unity.  So many insights!  And it looks so so so good!  

With your experience and skillset you have really been able to seize the many, many good things 2019.3 offers, adapting your project to take advantage of the excellent performance and control opportunities of the new system.  You don't have to fight Unity, bend it to your will, as much any more because you have so much more control.  Very well done, indeed!

It seems like 2019.3 is a turning-point where Unity now favors users with deep engine and rendering knowledge over users with art and design knowledge.  In order to take advantage of the power that Unity offers, you now need to be able to create your own SRP, or you need to be able to re-structure your architecture to use ECS/Burst, etc.  You sort of make your own engine within the engine.  Is that concerning or liberating to you?

Thanks for your thoughts and keep up the inspiring work!  

Hey! Thank you so much for your enthusiasm Smiley

I think that SRP is honestly an absolute godsend for games like Desolus.
The rendering in Desolus is too specific and niche, I really had to write it myself.
Instead of creating convoluted solutions which work around Unity's pre-existing architecture, I can make my own specific solutions.

Fortunately with Universal Render Pipeline or High-Definition Render Pipeline, I think others will benefit in other ways.
URP and HDRP are are built with the public SRP framework, which means there are fewer 'black box' situations.
You can also extend URP or HDRP yourself, with certain features like custom render passes.

Although it's ostensibly more complex, I appreciate the flexibility and choices Unity is giving developers.
(That being said, URP and HDRP have a longgg way to go right now, before they are production ready.)

Aaaaa looking forward to reading this a bit later!!

Game is so pretty <3

 Toast Right Toast Right Toast Right
Logged

Desolus Twitter: @DesolusDev Website: http://www.desolus.com DevLog: On TIG!
Pages: 1 ... 18 19 [20]
Print
Jump to:  

Theme orange-lt created by panic