Jove 2.0: DX11 Rendering System (Alpha Release)

I got a mighty HD4000, dx 11 laptop on my hands right now, see how it goes

 

Is that possible that you can update the demo on the first page?

 

Just as my unity license expires, unity 5 comes out and has pro features free (well not all features but I should be able to run jove on it).

 

Yes I will upload a new demo this week. For some reason Unity refuses to compile compute shaders while targeting webplayer under Unity 5 and I have no idea why. So I'll replace that webplayer with a downloadable standalone demo instead.

Lucky break huh

 

Hi! First off, Jove looks great, and thanks for making a DX11 only asset, it is great to see (as someone targeting DX11 only)!

Just had a few questions, not sure if they're gonna be updated with the new main post, but here goes:
-Performance:
Would be great to actually see side-by-side profiler comparisons between Jove and Unity 5, on varying levels of scene complexity, even better if you could do at least one benchmark for each major PC GPU vendor (Intel/AMD/NVidia). I wouldn't expect Jove to perform as well as Unity 5 ofc, but it'd be very nice to just have those benchmarks available before purchasing.
-What exactly does Jove break/fix?
Eg: Unity 5 doesn't render billboards in linear lighting properly, or regular trees in deferred properly. Does Jove change the way any of the default shaders 'work'? Do any custom shaders/image effects work with Jove?
-Does Jove support both Spec/gloss & Metalness PBR workflows (like Unity 5s standard shader does)?

 

Performace, as Aieth has said countless times before Jove has a greater overhead than default unity, thus in an empty scene would be less performant. Although Jove has greater peformance in scaling as everything is done in 1 pass (pretty sure I recall that), so a complex scene will likely perform better on Jove than Unity (i.e. hundreds of lights etc. etc.)

What excactly does Jove break/fix, Jove is a completely new rendering solution for unity and doesn't use the unity rendering pipeline but a custom one made by Aieth thus things that are not supported yet likely to work currently (i.e. terrain, although it's still possible just not as flexible as default unity terrain). Custom shaders can work if you can modify them to work with Jove's pipeline (which will be a lot easier in the coming update). Image effects pretty limited although Jove comes with a bunch (only effects that change the image itself i.e. colour correction can be used. Things like god rays, nope)

Jove uses Metalness that are slightly different from unity.

Dunno if all is 100% accurate, just top of my head.

 

Thanks for the reply. Will have to pass just because of the separate shaders & metalness, would be interesting to see actual perf stats as well.

 

You should wait till Aieth can give the proper rundown for you, with your questions before passing Jove.

 

I don't know that much about PBR but couldn't someone write a batch converter to go between the two workflows? To convert between different maps/channels?

 

The biggest differences are that Jove is a clustered renderer and I think it still uses a more advanced direct lighting model than unity 5 deferred so has higher quality direct lighting. The initial performance hit using Jove is far higher than Unity so in an empty scene Jove might be 10 times as performance heavy as Unity's standard shader but it scales much better so in a performance heavy scene it can be an order of magnitude faster and still look better as well as providing SSR. For example in a half million polygon scene with 8000 lights it renders in 4 ms . Asking Unity to do the same but with only 3000 lights takes 36 ms . With a decent graphics card Jove seems to only really be limited in performance to how fast unity can batch draw calls on the cpu. Jove isn't feature complete yet though as it is still in beta and doesn't do shadows from point lights.

 

I know the feature is list quite out of date by now. A lot has changed and I have yet to do a nice writeup on it. I know I should, I just really want to push to patch 2.3 before that As some of the replies have touched on, there are a lot of subtle differences and some not so subtle.
Performance wise, the most important decision that was made at the start was that lighting is done in a single pass. Functionality wise the most important decision is that every point inside the view frustum can be shaded. What does this mean in practice though? For one, it means it scales well. By jamming more lights or special effects into the scene you don't pay for extra full screen passes. I know the importance of this is hard to understand unless you've been programming pipelines yourself, but it really helps with reducing bandwidth. And bandwidth is the most precious resources in a modern GPU. As soon as I have time I'm gonna sit down and do a big writeup on Jove and exactly what it means, I know its confusing at the moment
But to answer your questions:
-Performance
Such a comparison would be like comparing apples and oranges. However I do agree that it would be nice with some more scientific performance measurements, and it is something I want to do.
-Fix/break
As others replied, it isn't as much a matter of fixing or breaking as it is writing the best possible future proof graphics pipeline I can. Everything Unity does is done with mobile GPUs in mind. Everything I do is done with only high performance computers in mind.
-Spec workflow support
Simply put, no.
Not simply put, there is a huge performance gain from metallic workflow. It reduces 3 required channels to 1, and saves a lot of bandwidth. It is possible to run Forward+ specular shaders in Jove (and there is one coming in patch 2.2), but for the sake of performance it is better to use the metallic workflow.

Yeah that's possible. It is however easier to go from metallic to specular than vice versa. I'll add that to my list of stuff to do It won't be perfect though, if you've foregone reality and given color specular to dielectrics etc.

 

@Aieth I know the order of implemented features has shifted quite a bit. Do you have a sense for what you want to implement in the next few dot releases? I'm not asking for timing for now but it would be great to see an updated list like you had in the first post before.

Also, is fully real-time GI something you are planning on implementing in the nearish future? That feature would open up some interesting possibilities with procedural, runtime-generated scenes. I confess I have no idea how feasible/infeasible it is, both from a programming and performance perspective.

 

2.2 - A whole bunch of stuff. I *should* be able to submit it tomorrow. Short feature list
- Temporally reprojected SSR (multiple bounces! Yay!)
- Photometric lighting system (physically based lighting values)
- Automatic camera exposure
- Stable bloom, no more flickering (ever)
- A new numerically integrated ambient diffuse BRDF (fancier ambient diffuse)
- A new analytical diffuse BRDF (fancier direct light diffuse)
- New area light types, tube and rectangle
- All area lights properly wrap around objects based on the size of said area light
- Builtin vignette and grain effects
- A probe override shader, so that you can force an object to use a specific cubemap
- A simple water shader to act as a placeholder
- A shader that blends up to 4 textures based on vertex colors + heightmaps
- A detail normal shader
And then a whole bunch of bug fixes and minor improvements which I can't think of at the moment.

For 2.3 I'm limiting the scope to
- Lightmaps


I have some ideas for a real time GI. This is down the line though and not the near future. And I'm probably going to target such a system at todays high end hardware, starting at GTX 900 power. So it would be pretty but not commercially viable for a year or two.

 

Thanks for the list and insight! Yeah, seems like true real time GI at the visual quality that Jove maintains would be computationally taxing.

 

Sorry, another question: Is anti-aliasing slated for after 2.3 then? I think you talked about it briefly a couple pages ago, and I thought it might be in 2.3, but not sure. Thanks

 

Hi Aieth have you fixed the light radius 0 bug I found ? Are you going to send the beta to your beta testers first before submitting it ? Also have you finalised how to make custom shaders for Jove yet , you mentioned a while ago to hold off making shaders as you were changing how they worked in Jove ?

 

I plan on focusing each patch on just one feature, so patches won't be as far apart as they have been previously. So yeah, 2.4 is local light shadows and then hopefully better AA in 2.5.

Yes, that is fixed. I'll upload the final version for all the beta testers as soon as I upload to the asset store (since that takes time for approval). The shaders are final now, you are free to start making shaders using the ones in the beta as a template Documentation is to follow!

 

Thanks! I'm a huge fan of the smaller, focused, frequent patches. We get the goodies faster that way.

 

Is exposing the depth buffer for better compatibility with other products planned for the near future? No worries if it's not, just curious.

 

@Aieth Thanks for the response! I'll definitely keep my eye on Jove - part of the reason I had a look in the first place is that we do actually have some bandwidth issues - SSAA + lots of image effects can be pretty taxing. And yeah, more scientific perf stats would be great, it gets a bit old reading how well stuff performs with "9000 lights"

 

Thats the plan

Yeah it is. I've got an idea how to do that and I'm gonna investigate it. It is possible it doesn't pan out, but I'm hoping it should.

Yeah it is on my very long list of things to do Hopefully I'll get to it in the not too distant future.

 

Was this the system that was talked about in the frostbite papers? Also how are these values applied to the lights? Is it dependent on their size or some other factor?

 

Yes it is that system. You control local light sources by the luminous power setting, it is brightness measured in lumen, the same measurement used for all common household lamps (at least in the EU, dunno about America). The sun and sky are measured in Lux, but if you use the dynamic sky you only get to control the sun as the sky is dependent on the sun.

The diffuse part of the light is independent on the lights size, only affected by the luminous power settings but the specular is dependent. A small light source will have a bright small highlight while a large light source gets a large dim highlight.

 

hi aieth. is there possible to do shader or maybe script which can allow semi transparent particles cast semi transparent shadows and ricive semi transparent shadows aswell?

for clear understand i want to make such effect like here

1:43 time

 

I'm not sure which part of the movie you are thinking about? I can't see any transparent objects receiving transparent shadows.
The technique I'm using prohibits this I'm afraid. Transparent objects can only cast and not receive transparent shadows. There are other techniques that support both, but they are quite a bit more expensive.

 

im talking about part at 1:43. advanced particles.

 

I don't think there is any self shadowing going on there though. What you're seeing is their GI system affecting the color of the particles. I'm hoping they publish some info on how they're doing it, cause it looks great

 

hmm... i thought there is some shadows there. but seems you right. there is only light inside particles.

man... my dream go down again (( but thaks for open my eyes.

 

There's definitely opaque shadows from the spotlight, but no transparent ones Otherwise there's liquid simulations with self shadowing that I wanna look into at some point, but its very far down the line

 

With my current pc master race rig (school laptop, with hd4000), within the demo scene I get a constant 12fps with all effects on (fog, SSAO, noise, vignetting etc).
Remember this is a hd4000, on board graphics card with 64mb of vram. Suprised it even ran Jove with all effects on.

 

Has 2.2 been submitted?

 

I think I'm having a bunch of overheating problems, is there any way to throttle or warn based on CPU/GPU temp?

 

There is a bunch of external tools for monitoring and controlling the clock, but that's not exactly something Unity has authority over.

 

At the moment the problem is what actually starts taxing the cooling could be arbitrary other than the shadows seemingly hogging the processing in the profiler, it would be nice to get a vague idea on what to dial down first, using afterburner or whatever is kind of missing the point as using external monitoring software is, as you say, beyond the remit of Unity - is a target audience advised to install afterburner too? I get freezes on saves quite regularly, not sure if that's totally Jove, but i'm getting hard crashes/BSODs fairly regularly which certainly isnt the fault of jove, its just endemic to the gpu being run so hard (jove is the only thing i've ever used that had my cards fan very audible) but would also be easier to avoid with an overview of whats most likely to heat it up, especially in relation to how fundamental it might be considered to be to image quality, like shadows are pretty fundamental, but very taxing, are there other areas where demands can be reduced?

 

Lazygunn that sounds like an issue with your graphics card rather than Jove. Most games will often use all of a gpu. I would actually be annoyed if Jove decided not to use it all automatically. If you want to throttle it you should do it in the graphics driver. If your machine is blue screening though it sounds like a hardware or airflow issue. Check the temperatures on the gpu and log it before a bluescreen. It is unlikely to be going beyond the temperature though as usually it will clock down the gpu in hardware itself to avoid damage. The only time a card should ever have to resort to cutting the power is as a failsafe if its fan fails or if the heatsink has worn out on it. Either that or there is no airflow so the machine detects that increasing the fan isn't reducing temperature and shutsdown as a precaution. It is more likely to be a power supply issue than a heat issue causing the restarts though as most hardware runs far below its thermal damage level now unless you have manually overclocked it. If you gpu is regularly going over that safe level replace it. If the restarts are happening below that temperature it is probably your power supply if no info is given on the bluescreen.

 

Hmm, suppose, like i say it wasnt jove as such, but additionally nothings worked my card so hard before (its a 580 and never rises more than a whisper on anything else) - i'm aware of gpus automatically throttling when overheating but would just be curious as to WHERE this work was being done, still, nevermind, although its not jove-specific i can show off jove making something in-progress looking quite pretty soon, so at least i'm getting a feel for the various aspects of it

 

hey @lazygunn you can also enable V sync in your quality settings to "every V blank". I notice when I disable vsync on my end (not Jove related) while my fps shoots through the roof it also sounds like my computer is going to launch into outer space.

 

That's actually quite a good suggestion, cheers justin

 

By the way, it might be worth bundling a Quixel DDO export profile with Jove, as some artists use it (well, some modern workflows pretty much require you to use DDO or Substance Designer to author the maps, so it might be reasonable to say it's not "some" but "a lot") and not having to shuffle channels manually to create an attribute map would be a good draw for some people.

Afaik it's pretty simple to create your own profile dictating what files are exported and what their channels are used for, I'll look at it later this evening.

 

I couldn't agree more and would very much appreciate any resulting profile! Using dDo was getting very fiddly when i was making the strut pieces for the thing i was messing with lately

I can't remember if a guide to adapting shaders was posted before, but would anyone be able to recap? What I have is a fairly large need for an almost cut'n'paste POM/Relief/Quadtree displace/Tessellation shader segment as it would speed up intended environment work up enormously - particularly using texture libraries like GameTextures where you'd want to create relief detail straight out of the map. That would solve my principle apprehension before going into the environment modelling i had planned (I have a bunch of the props, fixtures, panels etc etc but it's things like larger floor and wall surfaces that could be very quick to look pretty good with aforementioned shader feature).

I know it's a stretch asking for particular shaders right now but that would be handy - if anyone can help, much appreciated. Furthermore i'd like to take the preintegrated skin shader and adapt it to Jove, as it uses a custom lighting model i figure it should be good education, and this was probably explained recently so if anyone can link, again appreciated. If I can adapt a few existing well developed shaders to Jove then I think it's entirely reasonable to find a good approach to quickly getting shader forge shaders into Jove, and then, possibly an approach to have a plugin for shader forge that avoids hand editing if possible

 

Youtube is taking an age to process the video so heres a link to a video you may or may not find worth your time, early progress on a pals game with me doing art duties, jove sure does make things look pretty (and heres hoping the download works and my bandwidth isnt obliterated) http://www.pourfoi.co.uk/wp/stuff/CubeTest2.mp4

 

It's seems as though everyone is jumping on the PBR workflow, I just don't understand why it's not standardized where one PBR shader can work in any PBR renderer... and vise versa.

Maybe it's me that's just too simple but I just scratch my head and wonder why everyone seems to have there own way to do PBR but nobody can play nice?

 

I would liken it to implementing other rendering effects such as anti-aliasing or depth of field. There are different approaches to implementing physically-based lighting, all of which achieve roughly the same objective visually but in different ways. No single approach is "right," hence the varying methods.

 

It's like any standard, there are usually multiple standards based on implementation. Unity originally went with a Specular based PBR setup as it gave more control and the ability to make non-realistic textures. While metallic is generally limited to realistic only materials but has the advantage of using less textures/channels.

The only annoying part that could be really corrected would be the channels used for the methods. ie. Metallic shaders could always use the green channel on the AO map for Metalness or something similar.

 

They are very much standardized, channels being ordered differently are not that important. BRDFs being similar, understanding of roughness being similar, normals using the same tangent basis and so on are important, differences in that would've forced you to redo a lot of stuff.

 

Jove's metalness workflow is similar to other metalness workflows in other shader solutions, you just feed pretty much the same maps in a way Jove specifies - the point in making a dDo profile is that once you've made your materials it will export them automatically packed into jove-friendly textures, saving quite a lot of very tedious work

Here's the youtube flavour of the above terrible link, hopefully Aieth doesn't mind this being a repreentation of Jove, it's at least in a gameplay-ish context

 

On the subject of putting grayscale images into the different color channels, I recently learned out to do that manually in Photoshop. You use the "Channel Merge" feature in RGB mode, which lets you choose from any open grayscale, flattened images (dimensions have to match) and assign the R, G, and B channels.

 

Not yet, I was running through the last bug tests when I encountered some issues. Fixing those issues led to discovering a new possibility that I previously thought was unobtainable in Unity and long story short the GBuffer is now 32 bit smaller. I have not had a whole lot of time the past week, so that's why its been dragging out. I am, fingers crossed, hopefully pushing tomorrow.

There are lots of overclocking tools out there, it's been a while since I was into that scene but I used a program called Rivatuner to monitor clock speeds and core temperature. I'm sure there are other tools that do it better today, I've heard good things about MSI Afterburner.

Yeah looking into texturing tools is one of the many things on the list As I have many other things to do and am not familiar with most tools it is pretty low on the list though. If you create something I hope you'll share it here

That's surprising to be honest. With 64mb VRAM just the GBuffer should eat most memory

There's more to it than programmers like to tell everyone else because we know that will just confuse them I'll post the short version now. A PBR renderer depends, in the general case, on 3 different values. The diffuse color, the specular color and the surface roughness. You of course always use normal maps, but they describe the geometry, not the detail of the surface itself. Ignoring the whole linear/sRGB business, diffuse and specular color should be equal across the board. This is complicated somewhat by engines using metallic vs specular workflow, but inside the shader once its been decoded it does not matter. It is just a clever way of encoding 6 color channels into 4 (plus IMO it is easier to work with).
I'm not going to go into exactly how, but it is possible to dissect objects and extract their specular color and their diffuse color. Or if you know the index of refraction of the material you can compute the specular color using Snells law (relative to air. That's actually another funny part, your PBS materials are completely wrong under water. They assume the contacting medium is air).
So the specular and diffuse are actual physical measurements with a clear well defined meaning. Specular comes from Snells law and the diffuse is the measured color once you subtract specular (diffuse = total - specular). Its still an approximation of real life but lets not go deeper
The major culprit of incompatibility is left however. Roughness. Now we're entering the rabbits nest. There seems to be a widespread misconception that roughness is just some arbitrary value that different BRDFs using in different ways. There's actually nothing arbitrary about it, it is also a measurement. What it is a measurement of however, varies wildly between BRDFs. I don't remember exactly what it was, but I believe either GGX or blinn-phong roughness was a measurement of the tangent angle between the microfacet normal and the surface normal? Either way for each BRDF roughness is usually measured in different ways. Then, on top of that, you have the parametrization we developers expose to the users
At least using the BRDF I am, a slightly modified GGX, just exposing straight up 0-1 roughness isn't very useful. To start with, black means smooth which is counter intuitive. Then on top of that it doesn't appear linear. Going from 0-0.1 makes a much larger difference than 0.1-0.2. So theres usually some kind of roughness remapping. Jove uses roughness = (1 - smoothness)^2. The same remapping is used by UE4 and Frostbite, and they both use similar BRDFs. So anything that looks good in UE4 should look good in Jove as well. I don't know what BRDF and remapping Unity 5 uses. If anyone knows please tell me

It might just be my ancient version of Photoshop (CS3), but I have a "Channels" tab to the right that lets me manually flip through the channels and copy and paste. Its very pain free, it never occured to me that other people might be using more painful workflows

 

I'm on CS6 and there's still a Channels tab, but either they changed it or I'm too dumb to figure out how to just paste images into each channel (alpha channels work fine though).

 

I open the image I want to copy, do ctrl-a ctrl-c. I then go into the image in which I want to paste, enter the channel I want to (e.g red for metallic) and press ctrl-v. But I'm guessing you've tried pressing ctrl-v already? All four channels work the same for me in CS3.