Jove 2.0: DX11 Rendering System (Alpha Release)

Sebastien Legarde has an article on his blog regarding this and I think the issue is tackled in the Lux shader framework, might be worth a look at some point for those interested

 

Yeah, even with any of the three color channels selected in CS6, Ctrl-v pastes the image into all three of the color channels at once. Alpha channels allow individual pasting though. Maybe there's a way to control that behavior, I don't know. The Channel Merge feature isn't too bad though. In fact, it's probably a little quicker.

 

@Aieth

As far as I know, Unity 5 is using Substance Designer roughness format with 1/0.75 more range than SD had. I don't know what's their BRDF, I just remember some Unity developer mentioning how SD range was weirdly small for some materials and how they were in talks with SD guys in hopes of changing standard roughness range there in the future.

I should probably check Quixel export profile for Unity 5, it should describe everything in easy to read plain text.

 

Uhh, that should not happen. Select the layer you want to paste things from, go to Channel view, click once or twice on an individual channel like R, Ctrl+A, Ctrl+C, go to target layer, go to Channel view, go to channel, Ctrl+V. It should never paste full RGB in that situation.

To make it easier, don't use layers in the final file at all, leaving only Channels tab relevant to you and leaving out the chance for weird situations with RGB pasting.

 

Yeah, I tend to flatten all the maps and copy paste to channels but organising even 4 diff textures - well rgb and alpha for 2 in colour, 4 different maps in the mask texture and a normal map.. for every single model becomes a huge chore doing it manually(the scene I'm about to do could have me do this process 30 or 40 times!?), so yes a dDo profile would make jove materials much more enjoyable to create, I find dDo pretty inspired in this regard, it was making stuff I thought would actually be pretty fiddly like dota 2 materials a breeze. E-beverage of your choice for such a thing

 

Yeah I was supprised too with the results with 64mb of ram. At my laptops native resolution the frame buffer takes 9mb of it.
Ill do some more testing with a proper scene maybe in the future.

 

Yes, I think I was getting messed up in situations where I had content in layers and misinterpreting what I saw. I just tried it with a Photoshop image containing only a flattened "layer" and it does indeed let me paste the color channels at will. Good to know! The Channel Merge feature is handy to know about too in any case.

 

Since we're in DX11 land, would it be difficult to add a tessellation version of the shaders?

 

Should be trivial, although they have a very limited use in practice (since you usually want to use hard edges in your geometry and since every single hard edge will cause your displaced tessellated geometry to get gaping holes).

 

No it isn't, I just have yet to look into it. I'm prioritizing what to work on and I'm sad to say tessellation isn't at the top

To all the beta testers. A new version has been uploaded, a release candidate. No documentation yet (sorry ), but a quite a few under the hood changes. It should be faster now, the SSR should look better and the new light types are properly integrated into the editor (with scene view drawn outlines and stuff). I'd really appreciate it if as many as possible of the beta testers could test this one, even just for a minute. I'm using a native plugin to set some render flags and I just want to make sure it runs on all systems (especially if someone has a 32 bit system to test on!).

 

if you need an extra hand with testing, lemme know

 

Report here with performance, sort of averaging 9 fps now, although I get more spikes to like 16 and stuff.

HD4000 master race.

 

I always do. Just PM me your in-voice number first

I've changed the default settings a bit between the two. It's likely choking on the increased memory requirements for the fog resolution. 64mb isn't a lot Also I'm unsure how integrated graphics handle the way I'm treating the depth/stencil buffer now. I am binding it to read only so that it can be read as a texture while performing stencil tests. If it's slower then it's possible the integrated graphics is emulating the behavior. It is definitely faster on a "real" GPU, I saw a notable speed increase on mine

 

My GPU is as real as it gets
Did some more testing, without fog I get 16fps.
Changed fog resolution for all values to 64 (widh, heigh and depth), get 13fps with that.

With no effects on what so ever, I get 20fps.
One thing, if I make SSAO strength 0, does it turn it off?

 

I'm afraid not. SSAO was made mandatory in an effort to save on shader variations. Are you just testing on that HD4000 or are you actually planning on developing using it and Jove?

 

I only have my hd4000 laptop available this year as i'm on cultural exchange, but want to keep doing my hobby here.

Regarding SSAO, is it possible to reduce the quality of it to the point where it doesn't really affect performance at all (than have the strength set to 0)?

 

No it isn't possible without editing the code and removing the creation of the SSAO texture as well as the sampling of it in the shading stage.

 

Ah that's a shame. What kind of impact do you think to frames SSAO causes? If it's built into the shaders then I assume that it would be a lot faster than a post effect.

 

Hi Aieth is the latest version supposed to be able to build out of the editor yet. Just tried downloading the latest version to test. For some reason it seems to have film grain turned on as default again and it doesn't appear to be be able to build outside the editor which I thought you said had been fixed ?

Is that correct or has the download link been changed meaning I downloaded an older version ?

 

It should be fairly minimal, but it isn't free

Yeah I forgot to turn off film grain. The download link is the same. It builds fine for me, what kind of errors are you seeing?

 

I didnt have problems building other than it takes an extremely long time, chiefly the unity shader compilers working like crazy for ages, is there a way to speed this up? Or compile once at least

 

Not other than me restructuring to reduce the amount of multi compiles. Unless you manually remove some of the multicomp directives you dont use from the shaders.
On the plus side, it should only take long once and then you can build a lot faster (as all variations are compiled).

 

Actually im checking myself now, id noticed the multicompiles after rooting around after the lengthy build.. so er.. disregard the previous post. It's quite easy to prune the multicompiles

 

I tried compiling it again. This time it finished without crashing unity. It took 40 minutes maxing out all the cores on my i7 though so I think something is still pretty wrong with how it is compiling. All of the threads are running separate shader compiler processes Also all the shaders needed in the Jove demo would have had to have been compiled once already to run in the editor so I don't understand what it is compiling.

If I compare the shader compile times with something like shader forge for example Jove is taking 100 times longer which doesn't make much sense.

 

I'm gonna refactor a bit and change some logic to get the number of permutations down. The thing is that in editor Unity only compiles the shader variations you actually use. When building it compiles all you can potentially use. On the plus side it only does it once, next time you build its already there. But yeah it is an issue and I am aware of it. Next patch

 

Aieth is there an easy way to get a hdr panorama to work with Jove quickly?

 

If you can convert it to a cubemap you can just slap it on as the sky background and use that to bake some probes. Jove has no logic for importing or working with panormas though.

 

I tried that back the probe I baked was pure white.

 

Yeah that was a bug with the release candidate. No idea what caused probe baking to start behaving like that, but its fixed in my version now. Ill update the RC in an hour or two.

 

Release candidate 2 is up for the beta testers. Contains a fix for baking reflection probes and a fix for the long build times. It should now be roughly ~100 times faster (shader compiling wise that is, Jove still contains CPU code which needs to compile as well )

I uploaded a standalone demo of the new 2.2 patch. Link is in the first post but I'm posting it here as well https://dl.dropboxusercontent.com/u/233290703/JoveStandalone.rar

 

Same link as before?

 

Yup

 

Hi Aieth the compile times certainly are a lot better now. Something seems to be up with the luminescence power again though. Terrible things happen if you set luminescence on a light to 0 again which was fixed in a previous beta. Also if you set the luminescence power very high even more terrible things happen. Also is it impossible to turn specular highlights off on lights or set lights to have a radius 0 so they are more suitable for proxy GI , it always sets it back to radius 0.01 ? In general the specular highlights look far brighter than they should for a light so I don't know if there is a bug in the code or something. If you for example set a light with a low luminescence so you don't even notice it lighting objects you can still see a specular highlight of it on objects such as the green spheres.

Also performance seems a bit strange especially in compiled projects for me. In a lot of cases it appears to run faster as you add more lights. In the editor when you add a few thousand lights the frame rate starts to drop below 60. In the compiled project it doesn't so I am assuming it is just the overhead of the editor and lights gizmos which is fine. Strangely if I compile a project with just a few hundred lights turn away from the lights and look close up at an object to see the specular highlights in the object the frame rate can plummet into single figures. If I add more lights to the same scene so that I can never look in a direction that isn't facing any lights it doesn't do this. The performance effect seems more pronounced the fewer lights you have in a scene.

To recreate it simple add a bunch of point lights in the air. then zoom in and look down close up at a shiny material such as those green spheres in your demo so that you aren't looking directly at any lights. Doing so on my gtx 680 can bring the frame rate down below 20 fps. I think it might be hitting the cpu rather than the gpu though as changing resolution does not affect this frame rate. In most cases even with thousands of lights it is constantly v synced at 60 fps so I don't understand what is causing those drops.

 

Wouldn't a spherical area light with a huge radius be far more suitable for an ambient fill role? Smaller radius equals far more pronounced specular reflections, that's fundamental. Traditional infinitesimal point lights are, like, the worst possible approximation for scattered light.

 

bac9-flcl you can't set the radius to be large enough to test that as it appears to be a slider between 0 and 1. I am no expert on photo metric lighting but I was assuming the best approximate for GI would be lights with a large range and 0 radius. If that's not possible then I am assuming that a very large radius would spread it over a larger area so it wouldn't be noticeable which would also work. A maximum of 1 is not large enough for that though and I still think there might be a bug with the specular because surely you shouldn't be able to see a specular highlight from a light with such low luminance you can't see it in any other way although maybe it is correct because the sun may be causing you to see the rest of its lighting in the demo.

 

Realistic light sources have no radius, only intensity and physical size. More intensive light source will have more intensity remaining at a given distance from it in comparison to a less intensive one, and a point where surfaces lit with those lights become too dark might be perceived as a light source radius, but that's it.

The physical size is very important factor for specular reflections and softness of lighting in general. Incredibly small point lights will always have brutal, extreme specular highlights that look like tiny points on reflective surfaces - precisely because they are, in fact, tiny points shooting all that light out. In contrast, big light sources, like luminescent panels, might be intensive, but have their emission spread over large area, so their reflections are very soft and can't leave harsh point highlights. So, the softest possible setup would be a light of a huge physical size, not an infinitely small light. Hell, you can even think about a traditional ambient model (flat ambient color added to lighting everywhere) as about an area light of infinite volume that emits light from random evenly spaced points - that's the softest, most even kind of lighting that can be imagined, haha.

As far as I remember @Aieth planned to add dedicated ambient lights at some point in the future, for use cases like yours. Existing point lights have their sizes capped in reasonable ranges fit for stuff like traditional lights, and they have a falloff preventing you from creating grid with even intensity, so you won't have an ideal result with using them to approximate scattered lighting. But still, a point light with a large area value might be a good stand-in until ambient lights are added.

 

Holy mother of cheeseburger, I remember speaking with @Aieth about tackling this sort of stuff years back in the beginning.

Great job with the volumetric scattering, that was something I never got around to and your SSR implementation also looks nicer than ours. Just looks great from head to toe.!

I'm going to buy it to see what you've done better than me ..

Edit: One question, did you every get around to doing temporal AA? It's on my list of to do and would rather pass it off if I can .

@lazygunn some mighty impressive piccies there champ!.

 

Thanks, fixed the 0 bug. Seems I accidentally reverted a change. As for the too high, that's actually a hardware limitation. I am packing the lighting inside a 16 bit texture, and it can only store that much. It shouldn't be a problem in practice, as it can still store values thousands of times brighter than the sun.

Radius 0 is the same thing as dividing by 0. As in, not good The best thing in your case would probably be to simply remove the entire specular part of the point light evaluation in the shader. Lookup line 121 in LightingMain.cginc and remove the "spec" part of it.

I'm not sure I understand. Either that or I am failing to reproduce it. Even if Jove uses clustered culling, lighting isn't free. You pay the math cost for each pixel affected by a light. But if it doesn't change based on resolution then something does sound off. I'm not sure what as the culling should be really cheap in the scenario you describe. Could I get you to send me something so I can reproduce it?

 

A few things have happened since we last spoke Temporal AA is coming. I'm limiting myself to one major feature per patch.
2.2 - Lots of stuff (on RC2 now)
2.3 - Lightmaps
2.4 - Local light shadows
2.5 - Temporal AA

That's a rough roadmap but it is subject to change.

 

Hi Aieth maybe it is a strange graphics driver issue for me then. I restarted my computer and tried the demo again and it seemed to run as you would expect it didn't get the slow downs I mentioned. If I set the range of a light to 0 or the luminance of a light too high and then set it back to a sensible level even though the effects are shown I then get erratic performance. I had a situation where increasing the resolution in the game window was increasing the frame rate. Restarting my computer again fixed this issue where it was running at 60 fps again. Your previous betas didn't seem to have this issue for me though. Setting low luminance lights to have a large range destroys performance for me which wasn't the case before.

I'm beginning to think your lattest update is the most elaborate april fools in history. Increasing resolution results in increased frame rates thats a first for me.

 

I suppose it is possible that in case error appears once it propagates via the temporal reprojection of fog and ssr. So it happens when range (not radius) is set to zero and if luminance is too high? What exactly is too high? If you can test that we might be able to ger around the issue if I hardcode a cap.

 

I can't set a light radius to 0. The slider always sets it to 0.01 even if I type 0. I can only select the value on the slider from 0.01 to 1. If I set the luminous power to be above 10 to the power 9 instead of proper lighting I get a rectangle the colour of the light. I think you need some sort of culling where it will not allow you to set lights above a sensible brightness and also will limit range if the light has a very low luminous power. Also since luminous power needs such large values I think you would be better having a slider or make it automatically multiply the figure you enter by a factor so you don't have to always type in such large values.

 

Lightmaps? What's up with Unity generating the lightmap UV's and running it that way?

Does it have full support for Unity 5 + Enlighten?

 

I think Aieth (and most people) haven't fully investigated how Enlighten works currently and such unable to implement in Jove right now.

 

Ok, thanks for the response.

 

I *think* I might have fixed it. Going to upload a new version later today, can you give it a try then and see if you still get it? I was unable to reproduce the slowdown when a light has low luminous power though. It doesn't even make any sense, so I'm hoping the issue magically goes away with the changes I made.

Patch 2.2 which is coming... any time now, supports Unity 5. Actually, it only supports Unity 5, as I'm using a bunch of new features not present in Unity 4 like HDR cubemaps.

Lightmaps are a tricky issue. I am still on the fence about this but this is my current reasoning. I am going to be supporting lightmaps in addition to (or perhaps next to) the IBL solution, as this is mandatory for indoor scenes. I have two options:
1. Roll my own lightmapper + atlasing algorithm (half way done)
2. Integrate Enlighten

At first glance integrating Enlighten seems the obvious choice. But there are a few things I have been unable to figure out and am therefore reluctant to investing a lot of time (which is a precious resource as a solo dev). First off, now in patch 2.2 I've moved the entire lighting over to the photometric system with phyiscal values and as good as possible approximations to area lights. This requires a full 16 bit range to fit. The glance I had at Unitys shader code implies Enlighten works with RGBM encoded 8 bit maps with a max of 8. I need a max of several hundred thousand, 8 might as well be black
If I use Enlighten I either need access to the packing stage (which I don't think I get) to do some luminance scaling to approximate the behavior of 16 bit packing or I need to simply make it use 16 bit maps. Which would be preferable, but I don't think its supported currently. I'd be glad to be proven wrong though.

The advantages of making my own is that I get to use whatever format I want, and I can make it fast and GPU accelerated. That, and the technique(s) I'm using approach ground truth with a high amount of samples. I'm using a small archviz apartment for testing and it's baking ground truth like lightmaps in a couple minutes. The only unsolved issue at this point is if I can force Unity to use my lightmaps like I could in Unity 4. I'm sure its possible, I just have not figured out how to yet.

 

@Aieth

Well the only advantage to Enlighten is that it can generate small, low texel lightmaps dynamically and changing light direction / colour intensity can be done on the fly because it pre-computes a geometry cache for bounce lighting. If you change the packing and scaling, you're just going to incur pre-computation costs on an already slow solution.

I much prefer UE4's Photon mapping solution, not only does it look far better. It's also quicker to bake, but then you're stuck with the same issue as UE4 is. Dynamic lighting within a pre-defined latency definition, let's face it all real time GI solutions suck in one way or another, you either have low quality and colour / light bleeding (LPV) or it runs so slow your GPU melts (SVOGI).

Lighting is a tricky thing, I'd probably reach out to Unity and see if they can offer assistance. End of the day they're getting money from you ..

 

I have not had any luck getting any of my questions answered before though.
But yeah, I agree that it would be great if I could get it in. I'm sketching on a dynamic GI system I want to give a shot after the roadmap is done. I'm pretty excited by it, but we'll see

 

Just a few hitches I found with SSR on my system.

I dont know if it's just my GPU or not (I know some things don't work so well on it, namely some unity effects).
I get some wierd artifacts from reflections where reflections shouldn't be or just some results with many visual artifacts.



Although at some angles the results are quite stunning.



Take note that the images have seemed to have quite a loss in colour quality and looks 'compressed', don't take this to what Jove actually looks like.