Jove 2.0: DX11 Rendering System (Alpha Release)

Aieth seems to be really busy with life and related stuff these days, but I'm sure he will have some sweet updates for you as soon as possible

 

Nothing else other than that it is a lot of work An efficient GI solver isn't easy to write. It's around 5000 lines of code, which is very math heavy. It takes time to find and eliminate errors, and it's difficult to debug due to the extreme amount of data generated. If I dumped the entire process to a file to analyze it, it wouldn't fit on my 2TB drive.

It's progressing I took a small detour from lightmaps to work on some post processing. I'm going to split Jove into two parts, the rendering itself and the post processing. This has two benefits. It becomes a lot easier to integrate other post processing effects into Jove (just add them between the JoveCamera script and the JovePostProcessing script. It will require minimal shader modification though, not sure about how much yet). The second benefit is that I can sell the post process pack as a separate asset, which I intend to do, to help finance the development. So I'm gonna fork off the post processing into a separate asset, containing

• Bloom
• Lens dirt
• Tonemapping
• Automatic Exposure
• Depth of Field
• Chromatic Aberration
• SSAO
• Grain

Jove users will recognize most of the effects. Depth of Field and Chromatic Aberration are new though. Here's a screenshot of the DoF effect.

 

something tells me that picture has GI...

 

Will the lens dirt support a world space windscreen or is it just going to be screen space only?

 

It's from the fork running in regular Unity 5, so yeah

Lens dirt has been available since day 1 It's screen space only, since its based on the bloom texture. If you wanted it on say the windows of a racing car, that would be possible to implement by rendering to a mask (RenderTexture) and then using that as the lens dirt texture. It's not terribly tricky to do, but does require some shader experience

 

Aieth, are you planing to do some kind of beta testing of your future GI solution?

 

I didn't see motion blur in your post processing list. And do you have an updated feature roadmap for Jove now that post proccessing will be seperate?

Edited out part about GI as it's up to Aieth what he wants to work on.

 

Keep in mind that Realtime GI is still the most requested thing of the Unity community. Enlighten is not realtime, unfortunately, and most people (who showed their GI creations) didn't do a single thing in terms of "releasing something". Of course Realtime GI is not an easy thing to implement and some techniques are really performance-heavy (thus need optimization), but why announcing something you just can't handle? Why excite first just to let hopes down in the end? I'm sure Aieth could do it. Jove itself is pretty impressive already

 

BGI = Before GI
A Skin Shader Comes to my mind...

 

A suite of Jove character shaders would be awesome. Skin, eyes, hair, the whole nine yards!

 

That depends on what you are referring to as the GI solution. What I've been posting pictures of is a version of lightmaps, lightmaps compatible with Jove (regular Unity lightmaps are not, they cannot hold the wide range of values used by the photometric system Jove uses). I'm definitely going to need testing of that once it's "finished".
If you are referring to dynamic GI nothing like that is in the works, although I have a plan I want to investigate at some point. That is a long way off though, and it won't be a cheap system

I agree. It's a shame it isn't just a few hours work

 

Aieth, take a look of KineBLur, is DX11 and opensource.

https://github.com/keijiro/Kineblur

 

The issue with motion blur (and temporal AA for that matter) isn't the shader stuff, that's fairly easy to do and would take me a day or two. The issue is integrating it into Unity in a performant matter. You need per object velocity rendered to a buffer, and that requires passing unique data per rendered mesh. I currently know of no way to do that in Unity. The only way I've seen people solve the issue, is by rendering all dynamic objects a second time using Graphics.DrawMeshNow, which means main thread only stalling everything else. If I find no other way I might consider that approach, but I'd really prefer not to have to (at least for Jove, it's probably unavoidable for the standalone post process).

 

Well, with permission you could just integrate the free Lux shaders for skin, hair, and so on.

If it's easy to adapt a shader to Jove ... then maybe it wouldn't take long.

 

I think if it were that easy, it would have already been done.

 

Also is the post processing going to be like the one you talked about in this thread?
http://forum.unity3d.com/threads/ssrr-request-from-community.297961/#post-1971462

Where all the effects are combined and done in a single pass instead of seperately?

 

Anyone know a fix for the busted compute shaders in the latest unity? Jove and many of my other dx11 assets don't work very nicely right now

 

Yeah, lots of dx11 related stuff broke past 5.1... Compute shaders erroring and crashing on compile. I also filed a bug report about textures not being bound correctly when even a regular shader also reads from compute buffers, but it didn't get any attention yet. There are some hacky workarounds for some of those, but I was hoping it would get fixed instead...

 

Wow that looks nice. Which BRDF are you using ?

So it dosnt work with deferred ?
Also if Jove is great with tons of lights, Deferred should not be that important after all right ?
"- Hundreds of dynamic point lights at a time "

 

It is not exactly "working" with any existing pipeline, technically. It's a new system entirely replacing the standard ones, not a set of surface shaders or an image effect bolted to something like standard forward. It's good with hundreds of dynamic lights because Jove is using deferred approach, yes.

Overall it's like adding an entirely new, third option to Unity in addition to versatile but limited standard forward and standard deferred modes.

 

As far as I remember, it's GGX for specular and Oren-Nayar for diffuse. Nothing much special about the rest like visibility and fresnel terms. Maybe with the exception that GGX is also precomputed into the mips of reflection probes and a lookup table is used for the view dependent terms (Aieth should have sources on that). That means the ambient light is reflected more accurately than if the image is simply blurred in the style of a certain mathematician from the 18th century. Something that Unity does even now, afaik. Uglyyy!

 

Kind of, what can be combined without quality loss is combined. It's always a choice between quality and speed, and I'm leaning towards quality.

Unfortunately no I've recommended all the projects I'm involved with to stay on Unity 5.0 for the time being.

Jove does use deferred, except it implements its own. Unity 4 didn't have full deferred when Jove started. Also, as far as I know, the standard deferred is still not flexible enough to do all that I want it to do.
Jove uses GGX as the specular and a derivative of what is usually known as the Disney Diffuse model, with energy conserving approximations. Jove also uses a preintegrated BRDF for its ambient light, which affects the final looks quite a bit.

 

Is this your video?

I was watching it with my jaw dropped and instantly remembered this scene from this thread.

 

It's the same evermotion archvis scene but much swankier than mine!

 

Is it like open to download to anyone or what?

 

+tinyman no, this scene is comercial from Evermotion.

 

No Jove, same scene.

 

Wow the unreal version is so much more realistic in comparison. Probably has to do with their superior post processing and better lighting. Which is kinda sad because they're both baked, I guess Unreal has the better lightmapper.

 

The guy making that demo is probably a tad better than me at it anyways, but comparing them is just silly, the U4 has post process out the wazoo and has a much more developed renderer behind it - i was just trying to get as many of the jove features i could out of one scene - so back then thats no SSR, complex lighting (Single directional lighting for shadows) no realtime reflection probes, i had to ask for a lightmap shader and do the lightmaps in vray and so on.

Evermotion are a great archvis and model source and sell their material individually as well as in larger packs - that one was from an Archinteriors pack, i think the individual price for it was fairly reasonable

Oh and err.. something to note - that video only covers 1/3rd of the entire scene, they seem to have just blocked off the rest

 

What's the plan for Jove right now? Wait for Unity to fix the issue or issue guidance on how to do it? Try and get Jove to work w/ 5.1 as is?

 

I dont believe Aieth or anyone has a proper sollution for the serrors in 5.1 and this probably goes for any dx11 compute plugin. Guess we have to wait for unity :/
I guess Aieth is either working on GI or something else. Maybe we can get the first post to be updated with a roadmap? Or maybe a bit more info on what plans Aieth has with Jove.

 

Can someone brief me on recommended color values? Ideally, I need something similar to the information provided by this official chart on the stock PBR system Unity:



Greatest points of interest:

• What is the correct range for albedo colors of dielectrics and metals?
• If there is no correct range and realistic fractions of naive 0-255 range are remapped to full color range already (for example, maybe realistic albedo color range of ~40-240 is already remapped to 0-255 in Jove), then I'll need reference values for common materials adhering to that remapping (plastic, steel, concrete, and so on).
• Same question of smoothness: what are correct ranges for metal and dielectric smoothness maps? If there are no correct ranges and physically correct set of values is stretched to 0-255, then I need reference values for common materials.

 

Getting a minor error on Unity 5.0.3p3. Easy to reproduce, just try enabling Debug Render on any point light. Here is the log:

Code (csharp):

1.  
2. NullReferenceException
3. UnityEngine.Material..ctor (UnityEngine.Shader shader) (at C:/buildslave/unity/build/artifacts/generated/common/runtime/ShaderBindings.gen.cs:167)
4. Jove.JoveLights.get_emissiveMaterial () (at Assets/Jove/Scripts/JoveLights.cs:319)
5. Jove.JoveLights.RenderDebug () (at Assets/Jove/Scripts/JoveLights.cs:346)
6. Jove.JoveRenderer.DebugBeforeRendering () (at Assets/Jove/Scripts/JoveRenderer.cs:117)
7. Jove.JoveRenderer.Render (Jove.JoveCamera camera, UnityEngine.RenderTexture dest) (at Assets/Jove/Scripts/JoveRenderer.cs:76)
8. Jove.JoveCamera.RenderToDest (UnityEngine.RenderTexture dest) (at Assets/Jove/Scripts/JoveCamera.cs:1260)
9. Jove.JoveCamera.OnRenderImage (UnityEngine.RenderTexture src, UnityEngine.RenderTexture dest) (at Assets/Jove/Scripts/JoveCamera.cs:1265)
10.  

 

Another strange issue: point lights seem to require nonsensical luminous power values that contradict the documentation. Here is a quote from the docs:

Here is a screenshot of two lights. Tiny centimeters-wide spot in the middle is a light with the flux of 1750 lumens, and relatively small light to the right had to use the flux of... 800 000 lumens to reach that look. Doesn't make much sense. Maybe there is a wrong multiplier used somewhere?

 

Correct range for albedo colours for dielectrics are 30-240 sRGB range, although 40 is probably more preferable than 30.
With metals there isn't really and certain range they should be in as the albedo (in metalness workflow) determines the specular for metals and the actual albedo for them is handled by the shader, (example, aluminium is 245 sRGB for the metalness workflow albedo, spec workflow would use this value for specular).
I have a self made spreadsheet for some common values if you want. The values in the sheet are based off Quixel megascan values, in sRGB.
https://docs.google.com/spreadsheets/d/1qVv5QlrxrLhfZjPRHBEk2u-w_T8X563m8EStQOBk8rg/edit?usp=sharing

Hope you find it helpful

 

Thanks! Although I have some things I'd like to confirm.

Is that Jove-specific information confirmed by Aieth, or general "most PBR environments do that" rule? I'm asking because, for example, Jove could have easily remapped physically plausible range of dielectric albedo from 30-240 to 0-255 to relieve some compression artifacts - there are no losses in doing that. Other shaders often do that for other values. Understandably, I'd like to know if anything like that takes place with albedo/specular (_MainTex) and smoothness to be sure I'm not making maps that are off base.

 

General sRGB 0-255 environment, which I believe is what Jove uses.
Sometimes you might want to go out of the golden rule range to get a better texture because even if it isn't 100% physically accurate, if it looks better it is better. If you want to go under 30 for Albedo it would be for micro occlusion which you sometimes can't just get from a simple AO texture (example being if you want something 100% black, like a hole in a weapon and no light should reach it you would make albedo and gloss/roughness 100% black, not physically correct but it looks a hell lot better than just AO).

 

Jove does not remap albedo colors. The only thing it remaps to a more plausible range are reflectivity values of dielectric materials. That means that yes, as far as albedo colors go, the same values should work as for most other PBR environments.

About the error, thanks for letting us know It's easy to overlook that when refactoring shaders. For a quick fix, simply change the string in the reported line (319) of JoveLights.cs from "Jove/Forward/Emissive/Unlit" to "Jove/Emissive/Unlit"

Tiny Man, what our artists with dirty metals is that they often apply the dirt, but keep the surface completely metallic. For very rough surfaces like dirt is, there is not much difference between metals and non metals and the transition is much nicer. That means we break the recommended albedo range for metals quite often, but that only applies to pure, clean metals anyway.

 

Thanks, that's great to hear!

You mean that new feature using the A channel of the _MainTex allowing you to sway reflectivity away from previously hardcoded value of 0.5 for dielectrics?

And speaking of reflectivity, small question: I made a shader which packs everything into one RGBA texture map - for materials that have no use for RGB albedo/specular, reflectivity override or translucency. It contains dielectric albedo/metallic specular in R, metallic in G, smoothness in B and occlusion in A. Am I correct in plugging a fixed value of 0.5 into the input.reflectance in that case?

Code (csharp):

1.  
2.                     DeferredInput input;
3.                     input.color         = mainTex.xxx;
4.                     input.reflectance     = float (0.5);
5.                     input.metallic         = mainTex.y;
6.                     input.occlusion     = mainTex.w;
7.                     input.translucency     = float (0);
8.                     input.smoothness     = mainTex.z;
9.                     input.worldNormal     = worldNormal;
10.            
11.                     JOVE_DEFERRED_FRAGMENT(i, input)
12.                     return PackGBuffer(input);
13.  

Great, replaced that now. I have found some new issues now, can you look into those too?

• Checking the "BETA: Jove Scene Camera" option in the Jove Manager component completely locks the editor few seconds after it comes into effect in some cases described below. I can move the scene camera for a tiny moment and everything is rendered correctly, but then the editor hangs. I have tracked it down to Scene and Game view being used during the same session. Use only Scene view, hide Game view (parent it to same layout area as Scene view and make it's tab inactive), never enter Play mode - then scene view camera works for as long as you want. Replace Scene view with Game view by entering it's tab - editor hangs after a few seconds. Alternatively, keep both Scene and Game views on separate areas of Editor window layout and enable that option - after few seconds you'll get a locked editor. Maybe there is some sort of a conflict between editor Scene view Jove camera and old traditional Jove camera, a race condition or some failed attempt to use a shared resource or something. Anyway, that makes scene view feature unusable at the moment, unfortunately. I gave the Editor 15 minutes to recover as it sometimes does after hanging on NREs, but it didn't, so it's probably something more problematic. I have no editor logs as Editor hangs before any errors are written into Editor.log.

• Exiting the editor sometimes crashes it. Here is the full Editor log mentioning the Jove .dll. I'm not yet sure what specific steps trigger it - last session to cause it featured me entering an empty scene with Jove Manager, Jove Camera and some lights, then loading of the standard demo scene, then baking of "EnvProbe Red" environment probe without changing it (a few times), then exiting the editor.

Aside from that, I'd appreciate a comment on intensity values of lights behaving weirdly (described here).
Just in case and to recheck:

• I'm using Unity 5.0.3p3
• Project settings are correct (linear, DX11, forward, etc.) and Jove import generated no errors whatsoever

 

As I said before its okay to break the pbr range if it makes a better texture and image at the end

 

Yes and yes.. 0.5 is the default before mapping.. which becomes 4% reflectivity - a valid value for most dielectric materials.
That's quite an interesting setup you have there by the way.

The code to make it work is full of hacks and guesses, hence the beta. Aieth might have a solution though.

The stack trace does point to the JoveRendering plugin... I'll forward this to Aieth. I unfortunately don't have access to the source code.

I found this to be quite weird as well, but I think the math checks out. Here is a screenshot of, from left to right, a completely white surface directly facing a directional light with 1000 lux and a debug render of a sphere, spot and rectangular light all with surface area equal to one and 1000 lumens.



As you can see, they look more or less equally bright, as they should. That means the outgoing luminance of local lights matches the illuminance from a directional light. I suspect there might be a slight error though, because the brightness does not seem to match exactly, but it seems close enough.

So, the outgoing luminance is correct.. so what about illuminance from local lights?


I've set the spot light to have as narrow range as possible, so it directly transfers all of its energy onto a surface of the same area. You can see the surface looks roughly as bright as both the light itself and the surface lit by the directional light in the background. The sphere light is a whole another story though... due to its nature, it only transfers a small fraction of its outgoing energy to the surface and the vast majority of it escapes. I can't be sure if the actual amount is correct (well, the code seems fine), but from looking at the picture it's roughly what I would expect.

What you have there appears to be ambient illumination from a sky during a clear day... which, according to wiki, can reach up to 25k lux. The point light source does not have even a tenth of the luminance and if you factor in all the light that did not reach the surface at all.. I'm not surprised anymore that it looks so dim. I can't speak for the accuracy of the reference values Aieth has in the documentation though...

Anyway, what I DON'T think is correct and will proceed to bug Aieth about ( ), is this: http://i.imgur.com/m6Elnvn.png This is the same spot light as before, but higher up. Where did all the light go?
It seems the inverse square distance falloff is not scaled by the angle of the spot and rectangular lights. It should have less effect the smaller the angle is and thus the energy is dispersed into a smaller area. As the angle reaches zero, this area becomes constant and so should the intensity with distance. It's the same with lasers - you can shine them much further than a regular light without loss of luminance over distance.

 

Yeah, I have monochrome environment materials like those, so it works great!



Of course, you get more compression artifacts by going with R instead of RGB for albedo, but it's nothing too bad. And I think it's possible to use the color with that setup, even. After all, every material (like paint coat or rust or wood or whatever else in your texture) might have it's own very specific smoothness range. So, it's possible to write a shader with no additional textures and just one additional color property, which will apply the color of your choice to areas of the texture with the smoothness range of your choice using multiplication over R lerped between 1 and your color using range match. Perfect for stuff like peeled paint over monochrome surfaces, for example.

To expand that idea further, you can probably even use two color properties, and determine which one gets multiplied by R from the texture. So instead of lerping between 1,1,1 and your color to have monochrome materials with colored spots, you can have base color with overlaid spots of different color - perfect for stuff like chrome under peeled paint and so on.

And to expand it again, it's easy to introduce metalness based cutoff. That way you still have one texture and two color properties, but can do even more complex materials, like brown plastic overlaid by blue paint with uncolored chrome rivets peppered around.

In any case, having just one texture is feels great and is extremely convenient.

I'm attaching the shader in case someone in the thread wants to use it. It also has an option to override any of the values, so it frees you from having to do tons of test textures to test various attribute combinations. Drag the smoothness slider to smoothness value you want, drag the "smoothness source" slider to the right to make the shader use that value instead of one from the texture, done. Enables quick iteration on materials too.

Oh damn. I turned off the main directional light in that scene specifically to rule out that enormous intensity of the sun drowns the lights, except I completely forgot about global environment probe with a daytime capture still throwing huge amounts of illumination onto everything. That explains it, values make sense then. Looking forward to that spot fix too, of course.

Also, tube lights rock, the implementation is incredibly well done!

 

I'm attempting to make a decal shader for Jove based on the single sided transparent shader sample included into Jove, and I'm currently having an issue I'd appreciate some help with. Decals are supposed to draw above other surfaces even in situations where standard materials will z-fight. Docs suggest that's achieved using "Offset -1, -1", and that seems to work to a degree - with an exception of this situation:



When the camera is facing the surface, certain rotations see the decal moved behind the surface. The distance to the surface plays absolutely no influence in this, which suggests it has nothing to do with insufficient offset or lack of depth precision. How can I fix this?

Edit:Looks like I attached the platforms slightly inside the wall accidentally, so offset couldn't compensate. Fixed it now.

 

@Dolkar
Also, found a small fix for Jove Scene Camera Movement component. It will lose EditorApplication.update on every solution change at the moment. That's easy to fix by replacing Awake method in that component with the following:

Code (csharp):

1.  
2.     private void OnEnable ()
3.     {
4.         EditorApplication.update -= UpdateInEditor;
5.         EditorApplication.update += UpdateInEditor;
6.     }

 

Hmm.. the latest version Aieth sent me has no Awake method and instead adds and removes the event in OnEnable and OnDisable respectively... so I suppose it's fixed already?

 

Might very well be. Speaking of latest versions, can you remind me what would be changed in the next release?

 

Found another issue - duplicating a GameObject with Jove Camera component (Ctrl+D on scene hierarchy selection) or creating an empty GameObject and attempting to attach a Jove Camera component on it when another Jove Camera instance is already present in the scene causes the editor to lock up. Unfortunately, it has not recovered like it does with simple NRE errors so I have no logs. The issue can be reproduced in the demo scene from the package.

Stuff like shadow sharing setting in the Jove Camera component implies that multiple cameras working at once are supposed to be supported, so I guess it's a bug.

 

I'm going to update Jove to run on 5.1.1 now that some of the issues have been fixed.

I'll get to it soon, I have so many things on my plate these days It's coming!

There's no remapping going on, except for reflectivity which is mapped into a [0.0, 0.16] range (where 127 (187 sRGB) gets remapped to 0.5). Smoothness is correct in the full range, unfortunately I don't have any real life materials to compare it to (and it would just be an estimate anyway, just like the official charts from Unity are just "close enough" estimates).

An input reflectance value of 0.5 gets remapped to 0.04, which was the previous hardcoded value. It is decoded as
reflectance = input * input * 0.16
Meaning it tops out at 0.16 and goes all the way to 0 (use that only for cavities to kill highlights in cracks)

The multiple cameras worked before. It doesn't work in my version either now. Not sure what broke or when it broke, I'm going to look into it.

The light thing is functioning as intended. While you removed your directional light, the default IBL is still as bright as a real sky. Imagine going outside a regular day and lighting a light bulb. It doesn't illuminate anything, it's simply not bright enough.

It's still undecided. I have a few things I want to do, but we'll have to see what makes it in. The issue being that experimental features are hard to predict time wise, the lightmaps have taken far longer than I thought they would and it's still nowhere near ready I'm afraid. The math being used is already around 5000 lines of code, and debugging the massive use of frequency projections is very time consuming.

What I can guarantee is in the next version is this:
A split of Jove into two separate pieces, the renderer and the post process. I'm going to sell the post process separately as well. Going to try a trick to make converting other post process effects to run in Jove very simple, but not promising anything on that front.
This also includes depth of field and chromatic aberration.

What I want to put either into the next version or the versions after that. Lightmaps and local shadows are started and are in various stages of completion.
Lightmaps
Sky occlusion
Local light source shadows

That should be the same bug that causes issue with the scene camera, the probe baking and the crash on exit. For some reason multiple cameras stopped working. I have a suspicion as to what causes it, I'm going to look into it. Thanks for the detailed reports.


A small personal update. I recently went through a really rough breakup, so work motivation has not been at an all time high. I'm also in the middle of moving to Estonia to cofound an indie studio. If anyone is interested in the project, here's a facebook link https://www.facebook.com/OverstepGame?fref=ts

 

Sorry to hear about the breakup, @Aieth. The indie studio venture is exciting! Best of luck in getting that underway. Good to hear from you and to get an update on progress.

 

Thanks for the detailed answers, and keep up the great work!

Good luck with the move best wishes to you, I'm hoping everything will go smoothly!