Jove 2.0: DX11 Rendering System (Alpha Release)

Here's a small teaser for the upcoming depth of field. Note that the screenshots are taken using Joves post processing applied to a standard Unity 5 render (have yet to add the depth of field into Jove itself, refactoring ahoy). First image is without any post processing, second is default settings using Jove post processing.

 

Looking great!

Speaking of post processing - can you add a configurable SSAO downsampling multiplier or a switch disabling it? It's obviously not the brightest idea from performance standpoint to render SSAO at a higher resolution, but it would be nice to have this option for folks with very powerful rigs (for example, widely used Nvidia HBAO runs at full screen resolution by default - it isn't performance friendly, but some people have the hardware to deal with it, as far as I see), and for stuff like offline video and screenshots for architectural visualization where realtime performance isn't that important.

Maybe the a multiplier/switch for fog too (ofc, rendering your fog at full screen resolution or even at half the resolution would be an insanely demanding task, so again, proposing this mostly for stuff like architectural visualization).

 

By the way, can someone point me to a way to fetch depth of an opaque background surface (e.g. from Jove Standard deferred shader) from inside a custom forward transparent shader? I'd like to use an idea opposite to stock Unity soft particle shaders - instead of fading opacity of a transparent shader when depth difference nears zero, I want to fade opacity as depth difference with background diverges from zero. This will be a great addition to a decal shader, because it will make decals disappear in areas where they encounter wall cavities and wall plane changes.

 

If it's not writing to the depth buffer you can sample it using one of these function in DeferredGBuffer.cginc

Code (CSharp):

1. float SampleDepth01(float2 uv)  //Depth / Farplane
2. float SampleDepth(float2 uv)      //Depth

If it is then your best bet is to use the half resolution depth buffer. It's used by post processing but is also available for shaders for this purpose (since you can't read and write to the same texture).

Code (CSharp):

1. float SampleHalfResDepth(float2 uv) //Depth

The SSAO is going to get an upgrade, Dolkar has a fancy one fairly finished.

 

@Aieth, so, I should do something this in a forward Jove shader, if I'm understanding correctly?

Code (csharp):

1.  
2. v2f vert(a2v v)
3. {
4.     v2f o;
5.     [...]
6.     o.pos = mul(UNITY_MATRIX_MVP, v.vertex);
7.     o.projPos = ComputeScreenPos (o.pos); // added to v2f struct as another TEXCOORD
8.     [...]
9.     return o;
10. }
11.  
12. float4 frag(v2f i, SCREEN_POSITION_ARGUMENT) : COLOR
13. {
14.     [...]
15.     float depth = SampleDepth (SCREEN_POSITION_ASSIGNMENT);
16.     float transparency = mainTex.w * (1 - saturate (depth - i.projPos.z));
17.     return float4 (scatteredLighting, transparency);
18. }
19.  

I'm referencing stock soft particles from Unity, and intending to use the reverse of that idea (no depth difference - full alpha, present depth difference - full alpha), so just to remind, here is how they were done there:

Code (csharp):

1.  
2. float sceneZ = LinearEyeDepth (SAMPLE_DEPTH_TEXTURE_PROJ(_CameraDepthTexture, UNITY_PROJ_COORD(i.projPos)));
3. float partZ = i.projPos.z;
4. i.color.a *= saturate (sceneZ - partZ);
5.  

My code above isn't really working so far - I'm probably misunderstanding something about the way you're supposed to check your position against depth.

And great to hear about SSAO, by the way! Can you or Dolkar elaborate on the changes there for a bit?

 

@bac9-flcl

It's an entirely new algorithm for the SSAO. It's not as much about changes as everything is new Dolkar has a thread somewhere, I'm sure you can find it via his profile.

As for the depth, the issue would be that SCREEN_POSITION_ASSIGNMENT needs to be SCREEN_POSITION_UV_ASSIGNMENT. Omitting the UV gets you coordinates in the [0,ScreenSize] range while you are looking for [0,1]

 

Oh damn, that's beautiful.



I take it by "fairly finished" you mean that he has tackled the secondary detail pass (the dark sharp outlines) he had planned to add after the AO thread was posted?

Oh, that improves things! Almost there. Here is what I get in those three components (shader isn't unlit in those examples, I just dumped values into channels of ForwardInput struct, so nevermind how stuff is affected by lighting - I'm just illustrating the differences between them).

▼ projPos.z


▼ SampleHalfResDepth


▼ SampleDepth


As far as I see, fetching a difference between SampleHalfResDepth and projPos.z should be the way to get the mask I want. Here is the alpha multiplier I get from their inverted difference right now:



The only remaining issue is relatively narrow and inconvenient range of resulting mask. We're now well into the field of elementary questions about math, I guess - but what's the least verbose way to remap the alpha multiplier to 0 for areas with difference equal or greater to the threshold? Not sure how to go about that, it's not the case where you can get a contrasting mask reaching both 0 and 1 just by crushing everything with a power operation.

 

I'm pretty tired now, but are you sure projPos.z is that you are looking for? That gets you non linear hardware depth, the macro SCREEN_POSITION_DEPTH_ASSIGNMENT gets you linear depth in the [NearPlane, FarPlane] range.

 

Okay, multiplying the results of subtraction before saturation does the job, I get a mask with proper contrast. Here is what I ended up doing:

Code (csharp):

1. float transparency = mainTex.x * (1 - saturate (_DepthMultiplier * (depth - i.projPos.z)));

Which turns this:



Into this if _DepthMultiplier is set to ~4:



Only problem is, results change radically depending on the camera distance. Move just slightly closer and the multiplier of 4 is incorrect now:



I guess that's happening due to depth values changing in a non-linear way depending on the distance of a surface to the camera, which shifts the size of the difference as you move it closer to the surface. How can I factor this into the shader correctly, as an additional multiplier to the difference?

Edit: Oh, you are right! SCREEN_POSITION_DEPTH_ASSIGNMENT is exactly what I needed:



I was confused by stock soft particle shader which seemed to use projPos with no distance-based artifacts and subtracted it from a depth value extracted from "linear" inline, so I assumed it was linear as well. But everything works now, thanks a lot for your help!



Now I can be even lazier with my decal geometry, never cutting cavity holes into them ever again

 

Pretty much everything is already done... The thing is, that screenshot was still using Jove. When I ported it to Unity, along with adding a detail pass and optimizing it on the way, I noticed that both Unity's depth and normal buffers have way too low precision and cause (to me) unacceptable artifacts with such a large effect radius. That, combined with the realization that bent cones are just not possible to implement in stock Unity 5, made me slowly lose my interest in continuing the development as a standalone Unity asset - it'd just become yet another AO.

Either way, porting the optimized code back to Jove isn't too time consuming, so whenever I stop being held captive by vicious deadlines, I'll go ahead and do so. Bent cones will probably come a short time after.

 

Got curious and took a look at it. It does indeed use projPos.z which seems odd. A closer inspection of the vertex shader however reveals this

Code (CSharp):

1. COMPUTE_EYEDEPTH(o.projPos.z);

So what you have in projPos.z is not actually the z component of the projection coordinates. Could use some better variable naming

 

Any progress on solving the issue with multiple cameras?

 

I'm afraid that's probably gonna take some time. It could be any number of issues causing it. I'm going to take some time to do a much needed refactor of the CPU side code, it is sorely needed. In the process I'm going to hunt down a few bugs, the multiple camera being one.

 

If I'm interpreting this correctly, that means Dolkar's SSAO implementation (which looks fan-freaking-tastic btw!) will only work with Jove, right? If that's the case, will the existing SSAO solution be part of the standalone post-processing effects package?

 

We'll see. The new SSAO is Dolkar's work, so I just do with it what he allows me to. We work together but towards different goals, I sell Jove as a product and he is using it with the indie team he is a part of. The same thing can be said for the existing SSAO solution, it's Dolkar's work, not mine
For now I'm not going to include SSAO into Scion, since SSAO is somewhere in the middleground between post process and main lighting pass. Plus there are already several good SSAO effects on the asset store, and SSAO benefits very little from a combination with other effects. The only thing it can reuse is downsampled depth, but if you do it fullscreen like Dolkar's new effect there is no synergy at all. It's the same computational cost as a separate asset anyway.

 

Ah ok, good to know. Yeah I've been perusing other SSAO implementations, and they seem very competent. I'm just partial to the work you and Dolkar have done, when it comes to top-of-the-line visual fidelity at a reasonable performance "cost."

 

(BTW, in case you missed it, when Aieth speaks of Scion he means ... Scion.)

 

Is Scion going to be included with Jove for existing Jove customers or will we have to buy it separately if we want to use it to offer both DX9 and DX11 versions of our products?

 

I am going to be splittinf Jove into two parts. Jove as the renderer and Scion as the post process and then include that into the Jove package. So Jove users will get it for free. Its gonna take some time to do the refactoring though. In the meantime I will hand out download links to all Jove users that want it, just PM me your invoice. Im deeply appreciative of all those that have purchased Jove in the current state, it has helped me immensely with being able to develop. It would not feel right to not give out Scion for free to you guys.

 

That DOF looks fantastic! Looking forward to your jove spin-off as a stop-gap to a fully functional and game-ready Jove!

 

Me too, hoping by maybe Christmas (being the time I return to Australia to my 980) this year we'll get that new cubemap thing you were talking about.
Could we maybe get a current roadmap for Jove as the old one is gone and doesn't really apply anymore.

 

Anyone tried importing the project to 5.2 beta builds or 5.1.1p4? Maybe compute shader import issue is solved by now. Unity 5.0 isn't really nice to work on, it has some serious issues, including erroneous removal or corruption of your project files in some cases.

 

When i add effects on my camera the screen goes dark. Why is that?

Here is a screenshot.

 

could be that you don't have dx11 enabled or using the wrong lighting type, some common mistakes that stop jove from working.

 

The screenshot isn't loading. Jove still doesn't run properly on anything but Unity 5.0, I'm working on upgrading it. Does the demo scene work for you?

 

Sadly in the demo scene it happens the same thing it just goes weirdly dark with some colors from the lights.

 

....is it just me or is that DoF using a gaussian filter? It is meant to be bokeh at the end of the day, right?

 

What Unity version are you on and is it set to DX11?

It's just you It's a flat circular kernel

 

I'm using unity 5.1.1 p2 but i'm not sure if my player settings are correct here is a screenshot

 

@macodys
Compute shader import is broken in Unity 5.1, unfortunately, so it's impossible to use Jove on that version of Unity at the moment. There are two options - rolling back to the latest 5.0 version (5.0.3p3) or waiting for a patch that will fix compute shader importing on Unity 5.1.

 

Hi,
Thanks for the fast reply and for your answer. I'll try to go back to unity 5.0 and see if it works thanks

 

Make a backup of your files or make sure all your changes are pushed to version control system you are using before doing that, of course.

 

From my experience rerolling unity version, everything goes well except for your scenes, they pretty much break. So do backup (lucky I did )

 

Will do thanks

 

If thats a generalisation about compute shaders in general, I'm afraid its not true. I have plenty of compute-shader based assets that work in 5.1. There were some specific issues with particular elements of compute shaders which affected certain assets, but the ones I know about (affected TC particles asset) already got fixed in a 5.1 patch release.

 

Just got to wait for Aieth to patch it I guess.

 

As far as I understand, it hangs and terminates the import process on certain long compute shaders, which won't affect all assets with compute shaders. I'd say that can be called at least a bit broken

From what I see in the changelogs, it was fixed in 5.2.0b1. Hopefully they will backport that fix into 5.1 sooner rather than later.

I'm not sure it can be patched, after all afaik it's not an compile error pointing to specific fixable issue but outright refusal to import some shaders on the Editor side.

 

Just tried Jove 2 in the latest unity 5.2 beta. It appears to render correctly again so I think it is an issue with unity 5.1. Initially when you import jove it gives an error and the game screen is black. If you move the camera though and then press play it hangs the editor for a while and then appears to compile all the shaders correctly.

It still isn't perfect as it does crash sometimes when doing that compiling but I guess it is still a beta. I would hold off modifying it too much to make it work with unity 5.1. I think the issues are with unity changing their shader compiler rather than with Jove. To be honest I think the shader compiler in 5.1 is just broken or has a lot of issues.

 

I'm probably going to start porting it over to 5.2 right away. From what I've been told 5.1 seems more trouble than it's worth.

 

Anything else you might have done to get it working? I get the following (I'm assuming it's the same error you were talking about):

Moving the camera, entering/exiting play mode, restarting Unity - nothing gets me anything other than a blank game screen.

 

As I've said, the only way to get it to work without access to 5.2 beta is to use the last Unity 5.0 (5.0.3p3).

 

Sorry, I should have mentioned I'm running 5.2.0b3

 

Well then, that's disappointing and means that Unity devs haven't fixed the issue with long compute shaders importing after all. Unity 5.0.3p3 is the only version that can be used at the moment then.

@IanStanbridge might be able to chime in though, maybe he found some bizarre set of steps that beats Unity shader importer into submission, as according to him, Jove started working in 5.2 beta.

@Aieth, how is the progress on fixing the error linked to multiple cameras/scene-game view switching/probe baking?

 

I made a post in the general forum a bit ago which got a few answers as to what was causing problems ill dig it up

 

here you go, might help http://forum.unity3d.com/threads/the-latest-unity-5-1-rc-and-compute-shaders.328738/

 

Jove is definitely working for me in 5.2 b 3 . Just reopened it to make sure it wasn't all a dream. To get it to work I did the following. Import Jove into a new project. Jove will import but give errors. Next open the jove demo scene and move the camera in the editor window so that it isn't looking at all the objects. Just move it so you can only see the sky for example. The game window will still be black at this point with the compiler errors. Now press play, the editor will then hang for about 1 minute and then it will start working.

Also I initially compiled it with the lighting still set to gamma because that was how unity was set by default. I switched to linear and it still works though, not sure if that would have any effect. I think the error is simply that the shader compiler is timing out. I was guessing that they had changed the compiler to try and compile any shaders that still needed compiling when you press play in the editor.
What is the spec of your machine though I have an i7 with 16 gb ram. I am guessing that the slower the machine the more chance there is for it to time out so that might be the issue.

The shader compiler still is far from perfect but my point was mainly for aieth in saying that the fact it did compile would suggest the issue is with the compiler rather than Jove.

 

I'm in the middle of refactoring everything to make more sense. I have a pretty good idea of what is causing those issues and they are going to be fixed in the process

 

Ok, it's working in 5.2 for me now. Loaded up the demo scene then loaded mine back up and something started working. Still spamming errors about JoveSSRBlur, but it's at least rendering . Not sure if it's rendering totally correctly, as we changed a few things to get it looking decent using 5.1 deferred, but at least something is showing. Still getting the IntegrateSH error as well, but doesn't seem to keep it from running.

 

Hey Aieth when do you think we will see maybe a camera overlay effect, so camera 1 renders the scene and camera 2 renders a first person weapon and the weapon is overlayed on camera 1?

 

That was already possible in the previous versions as far as I remember.