Jove 2.0: DX11 Rendering System (Alpha Release)

Unity doesnt support the latest opengl version which is why this package doesnt work with it, I suggest you ask unity about that

 

Thinking of arch-viz, i can give a reason why I saw it as a good use case - A regular arch-viz situation I imagine has an arist in that field been given a regular render-based project and is tasked with creating a visualisation by their client or employer, theyre using stock by Evermotion etc and not giving a second thought to how it might be implemented in realtime, specifically the scene is far too complex, even on the dwg or whatever import and cleanup, nevermind after populating the scene for the actual visualisation, resulting in an extremely heavyweight scene, millions of polygons and complex vray shaders.

These days realtime is becoming pertinent, i think people want to get onboard that, and with the inevitability of VR becoming not only an embraced standard for content consumption but a direct socially expected interface to anything visual created by computation, a middleware that can operate as something that makes an archviz realisation bridging autocad or revit taken to max or maya based content creation to naturally navigable areas in realtime with minimum fuss a bit of a mighty thing, especially if it's cheaply available and not some crazy expensive hamstrung bespoke venture

I'm not in the archviz field, but I am fascinated by it and have been doing archviz related experiments for years, i have videos of my first attempt at developing a suitable middleware with cryengine in my youtube somewhere, using an evermotion scene no less! (Comparing then and now is interesting) and I feel like Unity could be perfect for it with, for the mechanics of navigating a 3D space naturally achievable very easily, something to easily group objects and apply colliders and rigidbodys as needed and a character controller with an Oculus sdk camera controller attached to it for vr.

Visually though nothing currently with Unity can handle it, the scenes are ridiculously dense, decimating a scene in pure triangle count is basically a massive load of fuss, it takes ages, you cant be sure if you decimated too much and stuff looks like hellspawn, or not enough, and the weight of all that information bring the renderer to its knees. The shaders in max would be intended for vray, there's no direct analogue in raster based realtime engines, realtime raytracing really isnt very realtime and currently despite their best efforts, translating the materials to a physically based model that represents them well is a pain in the fecking arse, and however you go about it, its using a jumble of assets and Unity's own 'idiosyncratic' rendering pipeline which is simply not intuitive or fast in a field of deadlines and spiralling costs.

So, Unity's incredibly easy to use in general, it doesnt have the tools to make archviz work like i'd want it to work, which is where even someone with very little knowledge of the ins and outs of gamedev and realtime graphics can approach it and get their scene into Unity, however heavy, and have it looking phenomenal in very little time and fuss.

It seems like my little experiment with shifting that scene, which is an archviz scene, its extremely heavy, was telling about this here renderer - that even at an alpha stage it was integrated, straightforward and well featured enough that i could get a really nice archviz scene working as a really nice realtime scene in a day and a half. Thats something special i reckon! I didnt once have to leave the Jove workflow, no F***ing about with shader collections with great features but features made to fit around unity, it was all inclusive and worked brilliantly.

So yeah, sorry for the rant, but i think people should be paying attention to this. With just some of the inevitable features promised (further shadow casters, SSR, water shading) i feel like this just has it in the bag, it could make Unity a ridiculously affordable minimum fuss product for archviz that gets visually spectacular results. With something like a Shader Forge plugin, translating vray materials might not be such an absurd idea anymore, so yes, keep the work up Aieth and team, this thing is the bomb so far, and if it keeps it up i'll be letting everyone I know about it

 

Damn, I am still loving that render lazygunn... one thing that stands out atm. You know that spiral fixture thing... if it's metal, it needs a metal map

 

Thanks for the rundown... would love to see the setup of your project, as for the card well I'm too vested with Nvidia,
I'm running GTX Titans 3x SLI (With SLI turned off I do a lot of unbiased rendering Octaine, iRay) so Jove is right up my alley or vis versa.

I guess while I'm opening my Kimono...

24 gig quad channel memory
i7-3960 @ 4.5 ghz
MSI XPower II

At least now when I post frame rates you can take it with a grain of salt...

 

It's pretty likely that Jove will automatically support more platforms in Unity 5 as Unity upgrades them to support higher shader models equivalent to directx 11. Didn't they already announce computer shader support for Apples metal in IOS. They said in that blog that Unity would automatically convert over compute shaders written for Directx 11 so I am assuming that is how Unity is planning to handle the other platforms. If Apple don't update their mac osx to an equivalent meaning that IOS devices can handle more complexed shaders than a Mac I'm going to have to start writing them nasty letters.

 

Sexy machine! It suits though, very well, this kinda thing is great for the future in mind

The absolute top of the 700 series and Titans suffer from none of Nvidias deliberate crippling so you'll have no problems with compute, or any problems with anything really! You wont be able to report most realistic framerates to be used as a regular metric but you wont be even remotely troubled by the performance of this unless you're being silly

@Neptune - Jove's metalness approach works just fine, but i havent yet made any custom maps for the scene, its straight out of vray materials in max using the original maps, normalmaps made from grayscale bumpmaps etc. I've decided to make the sculptures seemingly made of some hard resin substance, so they're a dialectric with translucent properties, although its using a flat map for translucency at the moment. Through further refinements i'll use Knald to generate some AO and translucency maps for suitable objects which will give a clearer idea

Aieth has already supplied a vertex AO shader to take care of the lack of occlusion shading in the images and i'm further discussing lightmaps (Generated the regular way, in Beast or externally) and a vertex colour controlled AO, colour control and convexity shader. This stuff should all mitigate current lack of shadow casters quite well until that's rectified

Ian I think that sounds great! I really hope that is true, it could possibly make cross platform translation of Jove a cinch

 

First let me say how unprofessional you sound and congratulations for being the first developer we have seen over the years making derogatory comments/ statements about another developers products and calling us liers, we did not expect this, it's pathetic actually. You said "I am not going to comment" but you do realize you did exactly that

Who are you btw? Do you know us... How do you justify your comment calling us liers when you have NO clue what SpectraGI is capable of since it's not even released. You mention it's vaporware.. this statement alone proves your inability to understand the technical challenges required for proper dynamic GI solution which works in all platforms, not just DX11 and a closed custom 'very unremarkable' render pipeline such as your Jove 2.0 implementation. In all seriousness, a Jove like system can be implemented in over a few days from scratch by any competent programmer. The fact that jove locks users with no consideration for other third party products including Unity 5 is a dangerous offering for any serious game developer.

We also would like to suggest that you tone down your 'snake-oil ' sales tackticks and over-hype of Jove 2 as all of it's capabilities can be implemented easily. The Spectra GI system is capable of doing all this and much more without locking the user to a custom rendering pipeline and by-passing all unity standards not to mention DX11 only. Also, our upcoming Total Reflections package is going to blow your IBL system out-of the water and it works with everything (Default unity and custom shaders) not just a locked down renderer. Also your implementation for Area-lights and SSR are custom to jove and not open.

No comment,

 

This is going to be awkward I recken.
Lets keep it clean

 

@LIVENDA

That was misinformation, quite gross misinformation. You seem to not have addressed why the word 'vapourware' was used (correctly so far). The 'lack' (The truth is it only affects rendering based assets and Aieth has been openly welcoming support so long as it makes sense) of third party support is explicable by absolutely anyone with experience with Unity, so i don't know what the soapboxing is for, and i might add i can bring up record of yourselves not providing third party support within the one product you have released (I own Candela), with no consideration to your point blank refusal to accept responsibility for the incompatibility. Compared to, say, a very open attitude to third party support so long as it is relevant you suddenly seem hypocritical. Support for a rendering pipeline you have replaced makes absolutely no sense?

Your entire post seems to have been directed to children or the inexperienced, which is extremely insulting to intelligence, are you not aware that some of us know what a compute shader is, and their significance? Or that some of us might have actually used the system being discussed first hand and can give personal account, compared to resting on one screenshot? I'm assuming you mean open source by 'open' by the way, or you just misused the word.

Do you think by attempting to charm the ignorant that you're doing Unity any favors? How do you measure the intelligence of the average forum user? And if all that you described can be done in a few days why did Candela take months to appear? And how does a GI solution (A small subset of a renderer) implement more features than a renderer itself?

Your response was either hypocritical, made no sense or was plain misinformation. You can probably avoid criticism if you produce evidence of your GI working as stated, it would surely lead to retracted statements and apologies, even if it was only in an alpha build kind of state (Owners of the original Jove are welcome to attain the Jove 2 alpha)

 

I made derogatory comments? First off allow me to quote the urban dictionarys definition of vaporware

Calling the SSR unremarkable does possibly warrant an apology though. What I meant to say was that since it is a SM 3.0 compatible system it does, since it cannot, any of the more fancier things I need it to do for Jove.
Now, since your brought the topic up. Consider the fact that you have not actually shown a single image of a product that was slated to be released in August (a still image inside a CGI video does not count).
This is from your main post

Are you actually claiming that you have invented a way to perform a full blown monte carlo integration in real time? And you are doing this using fragment shaders? If such is the case, then what you have is amazing (and if you reread what I said you will see I said nothing that contradicts this statement). But, you have not explained in anyway how it works, not shown how it works and post after post is just more promises as to what it can do. What is pathetic in this situation is a developer that without anything at all to show for it is tricking those with less technical knowledge.
Since you bring it up I do not believe you have a product capable of doing what you claim it to do. I fully expect you to release your 'Total Reflections' any second now and perform a bait and switch.
Why would you come in here and call me out on calling the GI vaporware? It isn't even a matter of opinion, it is the definition. You have plenty of people over in your own thread questioning the validity of your claims, go address their issues instead.

Also, as for your snarky comment at the end, this is where my GI development got back in December. I had severe problems integrating it into a Unity workflow and it is the primary reason why development on my own deferred shading pipeline began. This is far from production ready, it has issues with baking times and is generally not done. But it is a screenshot and there is actual proof it exists.


If you wish to further continue this discussion then I kindly ask you to do so in a PM. This does not belong in public.

EDIT: Also, overhype? Says who? Your entire marketing style is 100% hype 0% material

 

Well that escalated quickly...

@LIVENDA , WOW, this is plain disgusting. Your whole post reads like you are purposely using misleading information like lazygunn said, I just hope most people are smart enough to realise that...what a joke.

 

Well I think Aieth won this small debate, from my observations

 

Livenda never claims they did path tracing for the full GI, read their post. It is used together with their other two systems in screen space.

It is very unprofessional to call a top developer liars . Why is it vaporware when they clearly outline their schedual. You also only posted a single image of your GI work, care to elaborate. Livenda, please excuse the above rants, no other developer
I have seen has been so iimmature, keep up the great work!

 

I am not going to comment further on the issue beyond this. I have already explained why it is, objectively, considered vaporware. As for the lying, literally the first thing said in the first post is "Dynamic Path Tracing". Are you saying that it is not actually path tracing, but something else? In that case calling it path tracing would, in fact, be the definition of a lie. It clearly states what it does is path tracing. There is no room for interpretation here, path tracing is a very narrow technique with a clear definition. Either you do it, or you do not.

 

It think their path traced method comes from here (or something similar) :
http://graphics.cs.williams.edu/papers/DeepGBuffer14/#video
They use Monte Carlo method, with an heavy filtering to delete noise.

I tested the executable demo, and it looks really great, but it's a little slow (~50FPS with my GTX570).

 

I think both sides are at fault here,aieth,you did make some inappropriate remarks,but,I can't help agree with the sentiment behind them,livenda has only shown a still image of their technique,originally call it path tracing in their video,than change it in their forum to a mix of a lot of different things. Anyways were all mature developers here,both of ye (hopefully) have great products,please just forgive and forget and keep doing the amazing things ye do!

 

Btw @lazygunn what's the name of your you tube channel,I'd like to check out some of your arch-viz stuff

 

I've tracked down and a fixed a memory leak issue in the current alpha release. If any of those who are currently running Jove 2.0 have issues with it, it occurs when moving between play and edit, PM me and I'll send you a new version.

Patch notes

• Deferred vertex color shader (RGB affects color, alpha affects AO)
• Updated SceneCameraMovement, make your game camera follow your scene camera in edit mode
• Fixed a video memory leak when going between edit and play
• Fixed blending between transparent and opaque shadow maps

 

i hardly have any! on my youtube channel its just various stuff-i-made rubbish-along-with-random-personal-things with some experiments with cryengine in '09 i think for getting this realtime archviz thing off the ground but here you go https://www.youtube.com/user/LazyGunn/videos. I claim braggers rights for doing box correction * glossy in 2012 based off some random talk in the shaderlab forum. Havent things come on since then

Hopefully not going to inspire wrath as it's a rather unconventional way to pick out something good about something but i like to think it builds a compelling case for this thing. Just leapt bizarrely at me, half-edit



Seriously?

 

Great to see! I've just noticed the missing blending and now that's no more.

 

That frog guy, while looking a little out of place , looks awesome. I guess you are using translucency to achieve the effect?

 

Hah yes, he's a heavy hitter in translucency, i packed some of his clothing with it too but i am basically half-edit and was very surprised when i found myself looking at the above. I'm not sure why this hasn't been done before but translucency AS STANDARD really does change how you do materials, in a very good way, and finding translucent aspects in many things is very interesting. Quite inspired

You can only look forwards to even more anachronistic/genre-spiting additions, because keeping experimenting fun means making weird things a bunch

A feature request i guess would be a forward flavour of translucency that had its transparency driven by the same or somewhat edited map, then doing plastics, oils, waxes etc in various stages of decomposition would work super and the effect's translucency-specific values would be individually editable rather than per-light. Being able to realtime animate a melting candle using a mix of this and something like megafiers for the deformation would look extremely impressive

Anyone interested in joining the translucency party, Knald https://www.knaldtech.com/ is inarguably great value for just random map producing duties but it's extremely fast and gives you mesh based AO and translucency in not too terribly huge a wait. Waiting for xNormal is very trying, Knald gives you multi fps updates

 

How good Knald is with low-frequency AO? Let's say, if I want to calculate ambient occlusion of four meter radius for some interiors. Beast works for that somewhat but it's not very fast nor precise with it's results.

Another question would be whether Knald indeed supports AO radius setting tied to world space and not relative to the model scale or texel density in any way. Wouldn't be nice to get twice smaller AO radius on a twice smaller model using same settings, especially if those are pieces of a modular environment that should seamlessly fit together.

 

Keep it clean, any more arguments get infractions and deletes. Goes for both parties, I don't care. Take it to PM.

 

Good questions, knald doesn't do anything so precise as in take per-unit or any unit based scaling but you can specify feature scale to it. It's ostensibly a tool for getting a normal map out of a colour map, just various stuff crazybump does but supercharged through GPU cannon, when it comes to baking AO it takes a general scale and opacity vales, and the scale of the occulsion in RELATIVE terms goes by the size of that feature relative to the entire chunk you're baking. You give it a texture to use as a basis for its 'integrator' (seems like a giant brain that outputs normal, derivative, AO, convexity etc no matter what map you feed it) then you can give it a mesh, which it will apply the integrated map to and then you can use it as a basis for AO and Transmission maps. Can't offer you anything specific and it's sadly lacking in multi-object support, so baking environments could be a pain, but as said it's ridiculously fast, Beast for AO seems a waste of time in comparison, and if Jove keeps the pro-translucency attitude then it's worth your 99 dollars or so for quick translucency maps you can evaluate as they are generated

 

This has nothing to do with unity(its UE4) but its so amazing I had to share:

. If its not too much to ask Aieth,could you set this as your target

 

I think a very similar result can already be achieved, biggest component missing is the SSR. Other than that, a properly blended Beast bake and properly configured PBR materials will give you that video. I am currently experimenting with a UV2 shader that allows you to use baked shading without dropping realtime lighting (with AO feeding to PBR occlusion output etc.).

 

I think I agree with bac9 here, it looks very pretty but its a very simple scene that would not be that hard to appropriate already. SSR lacking is a factor but ive found Joves reflection probes to be amazingly accurate, so not too worried

I fired a few ideas to Aieth regarding getting artist control over GI and occlusion without a realtime GI solution etc, while you (bac9) seem to use Beast a lot, i deeply dislike it and far prefer using Vray to bake lightmaps - rthe intention is to bake indirect light from a vray render to texture for UV 2 as standard as a basic lightmapper that can be further enhanced by baking the probes a few times each, and a nifty, hopefully possible to implement, colour encoding algorithm for getting an extra channel out of vertex colours (the encoding moves 3 channels to two, giving you rgb vertex painting control, plus two extra channel to blend maps of choice), thought this would be neat for tweaking AO and in the other side a route for picking out highlight detail where required from a map that could be packed in with an AO map.

I might be talking hoo haa but hey its exciting

 

So I have made some progress with TrueSky and Jove, however there are some issues, noticeably in this SS the artifacts close to the camera. It is also basically just the sky and sun colour / direction that is being controlled by True Sky. There is still work to be done to fully integrate it but at least there is some progress. I will work on it more when I have some time.

@Licarell

 

I think the only features missing would be SSR, tube lights and DoF. And they are all coming in time, so be patient

 

loving jove so far, shadows amazings, SSAO awesome, sky wicked, particles top notch.

Some smoke particle I quickly made thing is wicked cool

One question is it possible for the editor to resemble in game lighting maybe just without the bloom etc. its quite flat right now unless i'm missing something

 

No you are not missing anything. I have not looked into making it appear in scene view, I will at a later stage though. However, you can attach the SceneCameraMovement script to your camera and tick the follow box, and the game camera will follow the scene camera. I will attempt it at a later stage, be patient

 

check out here for some code for all kinds of area lights: https://www.shadertoy.com/view/4ss3Ws I implemented the spherical ones myself(no attenuation)in Unitys forward renderer. Also I cant help asking,do you have rectangular area lights in Jove?

 

There are no rectangular lights at the moment no. This is one of those things I want to take a closer look at though, but I do not know when. I've seen that link before and it's really cool, but it's not something you want in a real game It has to raycast against every light to accomplish that.

 

On the topic of rectangular lights check out this implementation here,its for blenders game engine,I tried to implement it but ran into problems when trying to rotate them,anyways heres the link: https://dl.dropbox.com/u/11542084/AreaLights.txt and the blog post: http://devlog-martinsh.blogspot.ie/2012/11/bge-candy-area-lights.html

 

Yeah, I think area lights are very important, and support for them (with texture masking) would simplify emulation of enormous range of light sources. Tube lights, TV screens, approximations of huge point light arrays, and so on would become possible with some very simple setup changes.

I remember a CryENGINE demo where a single area light with a complex texture mask was used to cover the entire ceiling of a huge hangar to simulate light from thousands of individual pipe lights, providing very similar look with laughable performance hit and pretty accurate reflections. So yeah, proper rectangular area lights would be an extremely useful tool.

P.S.: Speaking of existing spherical area lights, I think I have noticed a small issue with reflections from them - they do not take clipping against geometry into account. If you sink the area light zone halfway into the ground and look at a wall near it from a higher point, you would see the whole sphere reflected. Not sure if it's possible to fix that though, maybe it's an inherent limitation of a current technique.

 

That clipping you mention is because of the way games are rendered,rasterization,with rasterization objects are not aware of other objects,a way to fix that area light issue would be to implement area light shadows,but Im not even go into how difficult that is to do with shadow maps!

 

That is superb, well done! Let me get my greedy paws on your adjustments when you feel its up to it cheers!

 

"Yeah Baby Yeah"
- Austin Powers

 

Whoops, I thought the other thread was the asset store one. Moving the post.

Ah, so that's what's happening. Yeah, point light cookies were sitting at 1. Changing the value did nothing until I reloaded the level though, - might be worth looking into the setter of that value, see if it updates stuff correctly.

Overall, my idea of cookie use is to apply them to point lights that are situated in areas where desired look can be achieved without very expensive shadow casting (even though point light shadow casting isn't it yet, I guess it's not too early to assume that point light shadows should be used in high moderation, like in any other engine). So it makes sense to support arbitrary amount of lights with cookies if there are no technical limitations to that.

By the way, here is an idea: perhaps masking the light through use of cubemaps is not even necessary in some use cases. How hard do you think it would be to implement basic direction-dependent falloff for point lights? Extreme example would be lerping intensity between 1 and 0 depending on the direction of light, which will lead to a point light that outputs most of the intensity in one direction (maybe you can even sneak an optimization and remove 1/6th of lighting cost as the top will be entirely excluded).

You don't need to sample a cubemap that has to be prepared in the atlas to implement that, I guess. And the idea can be expanded into slightly more complicated feature where you set the custom midpoint. Maybe a slider in the light properties that sits at 0 by default (i.e sits at the equator of an imaginary cubemap with black gradient above and white gradient below) and can move into either direction, allowing you to create, for example, a point light that outputs at full intensity into 240 degree sector downward and falls off into black in the remaining sector above.

Only obvious consideration there, of course, is to limit it to cases that spot lights can't cover. Obviously, a point light that masks out everything but 60 bottommost degrees or 30 topmost degrees can be rendered with exactly the same result using a spot light, which would be cheaper. But for lights like on that screenshot, the idea of cubemap-less masking looks very attractive to me:



Obviously, the approach I have described will not allow you to have elaborate layered IES-like gradients like on that screenshot, but I can live without those.

Ah, I see. I think it can be easily solved by creating a custom editor that explicitly creates the undo point. NGUI has great uncluttered examples of those, if you have it for reference.

 

Implementing that wouldn't be very hard. From a performance perspective though it isn't really that great a solution, it would force the attenuation function to run once per point light and it would have to pass a lot of unneeded data.
I think it is one of those features that is great in some cases and completely unnecessary in most, which means that in a general product I can't really do it I'm afraid. At some point I want to support IES gradients though, which would give you the freedom you are looking for.

Also, as I said in my reply, for the next update I'll rework the cookies so that a single cookie and be used as many times as you want it to

The main features coming in the next version are

• Better cookie support - Reusing cookies no longer count towards the cookie limit
• Volumetric scattering with support for all lights (ambient probes, direction, point and spot)
• More shader variations (had requests for a cut-out shader and a UV2 AO. If you have an idea, please tell me)

Upcoming volumetric fog​

 

>I think the only features missing would be SSR, tube lights and DoF. And they are all coming in time, so be patient

Cannot wait for this. This and IES (real-time feedback?) lighting could give UE4 a run for it's money. The only main thing UE4 lacks at the moment is hybrid forward rendering, it's why we see very little characters rendered with it. No support for decent shaders.

I've been watching Jove 2.0 very closely. The fact you have improved on Unity's atrocious shadows is a seller for me.

Waiting patiently on the SSRR! This effect combined with PBR can make anything look realistic.

 

Add rectangular area lights to that list. @Aieth what did you think of the implementation I shared,could you integrate it with Jove?

 

Ah, you're right then. I'm just looking for ways to handle very large environments with shadows. Obviously, the shadow mapping is one of the most general and widely used features, but I'm worried how they will be handled on large scale. In contrast with non-shadowcasting light sources, deferred rendering is not providing any magical solutions to the performance hit per-source shadows incur, so you would still have to use them conservatively.

On the other hand, no one wants to go back to shadows baked into lightmaps - baked AO and GI is as far as most would agree to go. So I'm wondering how it's possible to get reasonable performance while giving environment artists freedom to play with shadows on large scale.

Another idea I had is a natural extension of adjustable shadow map update rate that already exists. Is is possible to allow creation of point/spot light sources with zero shadow map update rate? At this point, I guess, the performance hit from per-light shadow mapping would be identical to cubemap masking, with the practical limits being imposed by amount of memory shadow maps can take and the need to attenuate every light source separately.

I don't think it's really possible to come up with a solution that allows you to use non-uniform point lights with per-pixel and not per-source performance hit. There are light cookies, there is cubemap-less attenuation I have proposed and there are shadow maps without dynamic updates - all of them add per light cost in exchange for unique per-light appearance. All three of those should obviously never be used on 500 lights per scene or even a third of lights per scene, and that is unlikely to change.

IES and exotic angle-driven attenuation are very niche stuff, I agree. So yeah, if we're thinking about a generic solution that can be useful in every single project, then that would be shared cookie support first and stored shadow maps without dynamic updates second. Both are extremely powerful environment art tools that, we should communicate clearly, should be used in moderation - but nevertheless, would be a very desirable addition to Jove.

 

@8Infinite8
Custom lighting models rendered in forward mode are on my to do list. It is already possible but it requires a lot of copying code around A more user friendly version is on the horizon.

It isn't as straight forward as you might think. It is all very technical, but I do plan on revising the area light system at some point. It's a medium priority thing, I wasn't sure on where to add it to the roadmap

@bac9-flcl
We are currently working on point/spot shadows with some of the ideas you propose. We will see how far we can take it and what is actually released, but the current idea is that lights further away get a smaller shadow map and less frequent updates. The system is pretty complex though so it is likely to take a while, don't count on it in the next patch

 

If anyone is interested, here is Deferred Bumped shader with UV2 ambient occlusion support. Can be very useful for adding stable occlusion information into interior scenes to compliment the occlusion data from your UV1 texture mapping and screen space ambient occlusion.



The source (save to Jove/Resources/Shaders folder, otherwise the includes won't work):
http://hastebin.com/civuxosicu.vhdl

Intended to be used on large objects where UV2 lightmapping makes sense, like interior meshes. The mesh must contain the second set of texture coordinates (UV2), easiest way to obtain it is to enable "Generate lightmap UV" in the mesh import settings. Read the instructions below carefully!

The shader supports both Beast-baked 32-bit .exr lightmaps and 8-bit custom lightmaps. As, in contrast with traditional lightmaps where most of the data occupies a tiny range of values, necessitating 32 bit precision, AO occupies whole range between absolute black and absolute white, I recommend always using 8-bit AO maps with compression turned on. The difference is completely negligible.

To use the shader with the Beast lightmapping system:

• Create a separate scene exclusively for lightmapping, presense of lightmapping in the scene can cause issues with object lighting which are sometimes not immediately obvious
• Set the scene ambient lighting to absolute white in the Render settings
  
• Set lightmapping mode to single lightmap, not dual
• Set AO intensity to 1
• Set texel density to very high value to ensure complete use of the atlas area
• Set appropriate AO radius (I recommend 3-4 meter, there is no point in using macroscopic lightmapping for high-frequency AO, you already have that performed in screen space)
• Set "Static" flag to any objects in the scene you want to contribute to ambient occlusion (make sure to remove it later), including the object you are baking the lightmap for
• Use Bake Selected option with one object selected.
• Find the resulting .exr file in the scene folder, duplicate it to sewer any link with the scene (so that you won't accidentally remove it by pressing Clear or overwrite it)
• (Optional) Move the lightmap to the Materials folder of your mesh just like you do with any other unique per-material texture. Make sure the texture import mode is set to Lightmap.
• Add the ligtmap to your material
• (Extremely important) Copy the tiling and offset values from the Ligthmapping window of your lightmapping level while having your object selected - Beast sometimes writes the texture using values different from 1;1+0;0, so it's very important to save them. Paste them into the tiling and offset fields next to the lightmap slot in your material.
• Set the Lightmap sampling mode slider to the right value (32 bit)

To create and use 8-bit ambient occlusion maps with the Beast lightmapping system:

• Do all steps above, open the resulting .exr file in Photoshop, use Image -> Mode -> 8-bit to open conversion of it from 32 bit to 8 bit mode.
• (Extremely important) Select "Exposure and gamma" conversion type with the gamma value of 1.0
• Save the resulting map (keep the original .exr nearby just in case), make sure that import type is not set to Lightmap
• Add the texture into the material, set the sampling slider to the left (8 bit mode)

Note: The shader in NOT meant to be used for traditional custom lightmapping. You can not use it with lightmaps containing lighting information. The shader feeds the lightmap into the occlusion channel of GBuffer, which is useless for passing lighting information. If baked scene ambient was not set to absolute white, you will simply darken your object, and if any areas of your lightmap contain non-ambient light, you will simply subtract it from ambient lighting intensity, contributing to nothing.

____

Edit: Added parallax support, works by sampling unused alpha channel of a normal map for height.

 

Somebody made this for unity which creates self shadows for the particles. It's nowhere near nvidia's version

But I have a feeling it would look a lot better with jove

 

Jove already has shadows for particles

 

Wow blue, those two vids are impressive (I'm not seeing that these are necessarily for release)...

...so Jove can render volume particles comparable to the above? I'd rather like to see that!

Btw, congrats Aieth; I've been quietly following your asset as you know since the beginning, and I'm loving what I'm seeing now with 2.0.

Cheers!

-Steven

 

Yeah it's definitely not necessary for release, just thought it would be a nice addition.
@JecoGames I know particles can cast shadows on the enviroment in jove but I don't think it has self shadowing? I may be mistaken though