Lux-an-open-source-physically-based-shading-framework

Currently all I allow is bone transformation, as well as slightly reorganizing the bone hierarchy to allow what you ask for. As soon as you leave uniform scaling you'll notice everything goes haywire down the hierarchy, but the tool silently does some bone that magic saves you from that.

Anyways, this really is off topic, let's get back to talking about Lux. I only wanted to show that the work to incorporate Lux into uma is making slow but steady progress.

 

On the subject of Lux it's looking good! (I was thinking the same) At the moment i'm using Skyshop to learn the ins and outs since.. well.. i paid for it and all, but to most folk i'd say unless you know particularly what you want out of something as expensive as the costly pbr solutions (I was blundering about excited at a new 'thing' and didn't have a clue, still learning how this stuff works) there's not that much reason to pay so much with Lux offering so much as an alternative, and being developed so quickly

 

If anyone else bought the excellent Substance Indie Pack ( http://www.allegorithmic.com/products/substance-indie-pack ) and wants to use the PBR substances with Lux, here's how I got it working:

1) Get the PBRSubToLux sbsar here: https://www.dropbox.com/s/apry2lffg90oqqa/PBRSubToLux.sbsar
( Optional sbs source here: https://www.dropbox.com/s/xk8zy0hpns1nlhz/PBRSubToLux.sbs )
2) (Optional) Get the Lux4SD viewport shader by hd_ here: http://forum.allegorithmic.com/index.php/topic,917.0.html
3) Now you'll need to create new Lux substances from any PBR substance you want to use... open Substance Designer, create a New Substance. It doesn't matter which template you use, since you'll then just select all the existing output nodes and delete them.
4) Drag the sbsar (not sbs) of the PBR Substance you want to use into Substance Designer. That way you'll get just the small box instead of the entire graph:

5) Right-click this substance box and choose "Expose Parameters", and then check off everything in the list.
6) Drag the PBRSubToLux sbsar into the graph. Hook up the outputs from the PBR substance to the new inputs: Diffuse, Normal, Specular, Glossiness, and Ambient Occlusion. (Note: even though Lux calls it "Roughness" you actually want "Glossiness", which is the inverse of Roughness.)

7) Right-click on the PBRSubToLux node and choose "Create -> Output Nodes". That will create the four output nodes needed for the Lux Bumped Specular shader.

8 ) (Optional) If you got the Lux4SD viewport shader, you can preview what it will mostly look like in Unity by going to the 3D Window and choosing Materials -> Default -> Shader -> Load... and loading the Lux4SD.glslfx shader.
9) Save your new substance, then right-click it in the substance explorer window and choose Publish, and export an sbsar.
10) Drag the new sbsar into your Unity project.
11) Now you can create substance instances and modify the substance parameters as usual, but unfortunately only while you have a non-Lux shader like regular Bumped Specular selected... this is because Lux uses a custom material inspector and I haven't been able to figure out how to get that to work with Substances (if anyone knows, answer my question here: http://forum.unity3d.com/threads/238687-Show-Substance-inspector-with-custom-MaterialEditor ). You can optionally delete the LuxMaterialInpsector.cs file, and then it will work with the Substance inspector, but you will lose the ability to add AO or change the cubemap properties, so you probably don't want to do that. Instead:
12) Check off "Generate All Outputs" in the substance inspector, and modify the substance while using the regular bumped specular to get it to roughly what you want it to look like.
13) Then change the shader to Lux Bumped Specular, and drag the diffuse, specular, glossiness, and optionally AO maps from the substance to the slots if they don't show up automatically.


Success! Runtime-modifiable substances in Lux!

 

wow,

that is really a great contribution!
thanks a lot,

lars

 

Thanks lars! Here's one more thing I'm working on that people might find useful. A substance to automatically convert regular Unity Bumped Specular materials to Lux Bumped Specular materials. This one you can drop right into Unity; you don't need Substance Designer.

The sbsar is here: https://www.dropbox.com/s/acc8obxidrv7ds3/UBStoLBS.sbsar
And if you'd like the sbs: https://www.dropbox.com/s/hajbodao07ct3l2/UBStoLBS.sbs

Now, before Lars yells at me , I should say that you really should manually update existing maps by hand in Photoshop to really get them to look good, but if you have a bunch of existing assets that use the Unity shader that you want to try out or you need a starting point for maps to edit by hand, this should help. Add the UBStoLBS substance to your project, then create a new substance instance for the material you want to convert. As mentioned in my previous post, the Substance Inspector doesn't show up correctly if you select a Lux shader within the substance, so for now leave it as the regular Unity Bumped Specular shader, which should be chosen by default. Ignore the top half of the inspector; under Procedural Properties, drag the existing Diffuse RGB / Shininess A map into the Diffuse Slot, and drag the existing Normal Map into the Normal Map slot:


Make sure to check "Generate All Outputs". Then, if the shiny parts of the material you're converting are metal, check "Is Metal". If not, it will treat the shiny parts more like plastic. Then, change the shader to Lux Bumped Specular, and if the maps aren't automatically filled, drag the generated diffuse, specular, normal, and optionally ambient occlusion maps into their slots:


Now assign this substance to your mesh's material slot instead of the old one. Done! Here's an example, with original Unity Bumped Spec, then Lux with "Is_Metal" unchecked, then Lux with "Is_Metal" checked:




How it works:
You can look at the SBS to see how it works, but basically it extracts the shininess map from the alpha channel of the diffuse texture, and uses it as the Roughness Map, then if Is_Metal is not checked, it uses the Diffuse map as is for Diffuse, and uses a darkened, low-contrast greyscale of the diffuse channel multiplied by the shininess map as the new Specular map. If Is_Metal is checked, it multiplies the diffuse channel by the inverse of the shininess map to remove the color from the shiniest parts, and multiples the diffuse by the shininess map to create the Specular map, basically moving the diffuse color into the spec channel in the shiny parts. Then the normal map is used as is, but also used to extract a height map and convert it to an ambient occlusion map.

Still a work in progress, but hopefully some folks will find it useful.

 

Lars: Do you have a link to that model? Looks like a good one for testing different texturing workflows if the UVs are good.

 

Nice model lars! And i hope you liked my contrbution a few posts ago! (On second thought, though, you probably didn't see it, due to a mountain of new posts... ) BTW, thanks for the examples! just a question on them: is it possible to bake SSS and roughness in Blender?

@SoloChristian: Using your APK to see if Lux works on my 'droid. And thanks for providing it for us android users! I have used terrains before on my tab, but the default shders came out really weird. lets see if Lux does the same!

@Makeshiftwings: keep it up, it's looking good! where did you get the head model from?

 

as mentioned before i did not model the bus – i just reworked some of its texture to make it work with lux.
still a work in progress though.
and i saw your contribution but did not comment on it: mostly because it more or less "just" shows a polished metal surface.
i hope you do not mind if i just go over the top by saying: nice but what else does it show than cube map reflections?
you won’t unleash the real power of physically based shading unless you use complex materials which make fully use of roughness and specular reflectivity.

roughness describes the mircosurface structure – something far beyond of the modeled geometry. so no 3d app has any knowledge about that.

SSS however – or better: a depth map – might be baked using blender.
chickenlord shows it using a method described by dice:
https://www.youtube.com/watch?v=XBTB17hcbio
(around 7:00)

lars

 

I actually beleive that Blender's new Cycles baking might be able to bake SSS but is probably should be easy enough to paint in on its own as well.

I think roughness sort of works like specularity a little bit, so you could always just keep roughness in mind when painting in Blender and bake it out as a spec map, then I think you will probably need to invert the texture for it to work as a roughness map.

 

The DICE translucency shader seems to have taken quite a hold i've in fact weird plans to make attempts towards introducing it to oceans, building the transmission map in an odd way with a perlin based filter forge filter that inverses the height of the waves, bakes the AO then inverst that AO map in PS, wonder if it'll work.. but more on topic regarding that approach and i'm not sure who might want to take it on, but creating a shader inside this pbr paradigm that could mimic translucency, with suitable reflections (As many translucent objects can be shiny) and affect transparency - given a candle's a light source it would be a real showstopper to finally have wax acting like wax while being lit according to energy conservation laws. Effect of course can apply to other objects

You can produce a transmission map by flipping all the faces of your object round, baking AO then inverting the AO map produced. If anyone finds the knowledge useful - there's a very smart bit of software called Knald (https://www.knaldtech.com/) that can generate a lot of the maps you might ever want in a high quality model for a very high quality (and fast) output of maps, does the transmission maps, naturally. You might might really like it for concavity/convexity maps, getting that definition there without runaway AO taking from it

 

hi lazygunn,

bringing subsurface scattering to lux should not be that big deal – but doing it right might really be.

it starts with the fact that working with depth texture (like proposed by dice) do not allow you to define view independent depths.
it looks ok for a candle lit by its own flame. but imagine a candle wich is lit by a light that comes straight from behind:
the outer parts of the candle should be brighter (more sss because of less depth) whereas the inner parts should darker. but how should a depth texture for this case should look like? uv space does not know inner and outer parts.

the second problem are real time shadows, or better: self shadowing.

when writing surface shaders all lighting functions are fed with the light’s position, color and attenuation which is the fall off including real time shadows.
this a more or less no problem in case we are using point or spot lights: as we use a custom lighting function here the shader will always use the forward pass in which meshes do not receive shadows from point or spot lights by default (as shown in fig. 1).

but meshes receive real time shadows from (at least the first) directional light. so the directional light does not contribute to sss (as shown in fig. 2) although it is much brighter than both point lights and should give the light coming through real boost.

only using a directional light will give us no sss at all by default (as shown in fig. 3) unless we uncheck "receive shadows" in the mesh renderer component (as shown in fig. 4).

but if we uncheck "receive shadows" the shader gets quite unflexible as the mesh will not receive any real time shadows at all.

so i digged a little bit deeper "reactivated" "receive shadows" and added a custom shadow caster pass which simply flips the faces:
doing so will block light and translucency for the first directional light (as it is blocked by another game object) but not for the spot or point lights. in addition to that the shadow silhuette might become rather strange (as shown in fig. 5).

so lets resume: right now i know no way to fully integrate sss with the given lighting and real time shadow features.
so what would be a proper implementation?

would you like to have a sss shader that gives you nice sss but no real time shadows?
that would may be fit to objects like candles as they or mostly lit by their own light.

would you like to a sss shader that gives you you the freedom to work with real time shadows and one directional light?
that would fit day light outdoor scenes where the sun is the most important light source.

right now i think that there is no general solution to this so it will be a bit difficult to handle.

lars

 

I actually really appreciate the depth to which you explored that, you're quite right too, transmission maps can affect translucency based on the orientation of the model, but a candle is a good example of something entirely view-dependant, you'd rotate it from above and expect translucency falloff towards the middle uniformly, which isn't something you can express in a transmission map. My mind a bit ago kept falling back to volumetric effects (Which open a massive can of worms instantly, it seems) or some form of material-based light extinction by which to modulate a transmission mask, but even then i don't have the vocabulary you do in shader writing to know how that can work out with the lighting options offered. This kind of shading along with work at berkeley on scattering transparent materials like frosted glass has had me fascinated on what seem to be the more outlying, rarer visual phenomenon that aren't happened upon a great deal in realtime graphics but are or would be incredibly impressive if a convincing solution be found (fell on the subject of frosted glass looking for a course for a friend at Berkeley in the US as she wanted to go there, her brother did and she's also quite bright and i got submerged into their comp sci web pages, particularly on shading - this is what got me first http://graphics.berkeley.edu/papers/DeRousiers-RRR-2011-02/ but you might find a lot of their work fascinating). Maybe it's something to ponder on, but thankyou for a very thorough answer to something i'd wondered about quite a lot.

As an aside and something i've learnt to some profound degree having fooled with skyshop now, are lux's shaders box corrected? The reason I ask is well, why i'm not so keen on how it's currently being marketed, screen space reflection can look really, really good and work very well when paired with box corrected environmaps and the general shading from things like skyshop and lux. I'd really recommend considering having the option there if not already (forgive my ignorance if its there already) - Despite the somewhat errgh presentation of Candela it sure goes well with the stuff i mentioned.

It's quite an odd experience seeing much of this unfold, i made this video https://www.youtube.com/watch?v=9xsTWJd_KDw a year and a half ago as part of an effort to teach people how to bake lightmaps with vray in max rather than using beast, and i think i got more absorbed by the shading than teaching, and basically did a kind of dumb version of what you guys are doing properly now, a convolved (via cubemapgen) box corrected environment map to mimic glossy reflections and topically DICE's translucency shader everywhere on the statues. I find it odd it's taken this long for box correction to pick up a bit, it's by no means perfect but screen space reflections seems to work with it symbiotically to cover each others' weaknesses

Anyways i'll stop rambling now, but thanks again, i'll think about what you have said and it will, along with my investigations into ocean shading and my attempts to comprehend rough refraction, become one of those things i'll keep looking for an answer for

 

@Larsbertram1: That is impressive lars! and thanks for the link! I actually have heard of Chickenlord before... And i wouldn't mind finding out how you did the custom shadow pass. I have tried it myself, but can't work out how to get the shadow map... :/

@Beardbotnik: thanks for the tips! I can't believe Photoshop doesn't have tools like this... I am sure it had a normal map plugin though, but Unity already has that.

 

The generation of this kind of map requires processing of the 3D model in question with very specific techniques, which is generally out of photoshop's scope although it has flirted with 3D at times. As said, you might want to pick up a 30 day trial of Knald and see if it suits your needs, you only need to look at the product gallery to see that the maps it generates can have a very impressive effect on the appearance of your model and its materials

I think xNormal may create these maps too but it's quite a lot slower (but free)

 

hi there,

i hope that finally i have found a good compromise as far as subsurface scattering and real time shadows are concerned ;-)

sss should take the light attenuation into account of course (light’s fall off based on distance and range, light cookies etc. ) – but it should not be blocked by real time shadows as this simply corrupts the whole effect if objects that use sss receive and cast real time shadows – which of course they should do.

upper image – using the built in "atten" value to cals sss
head:
if you have a look at the head there is some sss on the chin but at the parts where the head receives real time shadows (especially around the ear) there is no sss at all.
candle:
the candle does not show any sss. neither the light from its flame not the green point light travels through the candle, so the backside just looks as if is was rendered using a standard spec bump shader.

all this is caused by the fact that unity’s built in "atten" value contains the light’s attenuation * shadows.
but all we need is just the light’s attenuation: we do not want neither self shadowing nor shadows from other objects to block sss.
all previous attemps like writing a custom shadow caster pass simply did not 100% fit our needs but finally i have found a way to just get the light’s attenuation without any baked real time shadow information.
the result is shown in the lower image.

lower image – using a custom "pureLightAtten" value to calc sss
both the head and candle still receives and cast real time shadows. but none of these shadows block sss.
head:
on the head spot light(1.) is blocked (2.B) by sphere (2.A) but we still get nice sss e.g. around the ear.
the cube (4.A) casts shadows on top of the head (4.B) but does not block sss around the ear.
candle:
point light (3.) scatters through the surface although the candle receives and casts real time shadows: no more blocking by self shadowing.

now i have to make this monster compile on dx11.
[edit]done![edit]

lars

 

Sorry for the poor resolution. I can't build the .exe because the build errors out with a
"Assets/Lux/Lux Scripts/Lux Cubemapper/Scripts/LuxCubeProcessor.cs(1040,8) error cs8025arsing error"

For whatever reason it is erroring on the closing #endif(i believe it closes over the "#ifUnityEditor"

I'm using the asset store version.

I'm not sure if you can tell by the video but the basic set up is working fine. Rather than use a single global cubemap I'm trying to do the box projection and have a different map for each room.

Unfortunately the env probe doesn't seem to be capturing the correct maps, or else I'm missing something. I worked on it for quite some time before asking for help.

I create the environment probe(by attaching the correct script to an empty game object), I center the probe, I move his bounds to encompass the entire room(a tiny bit of overlap through each wall), I add all of the game objects it is to effect(which is a nightmare by the way. please consider the ability to tag your game objects and pull them in via tag) and then bake the texture, finally I convolve the texture.

It ends up creating a "pinched" and very dark view, as well as outright missing some areas.

I've seen you demonstrate the outcome so I know there is a way to make it work but it has eluded me, and a few others from reading this thread, thus far.

Any chance you could take a look at it? Or is it a known issue and i need to grab a newer version than the asset store?

edit** - I forgot the most important part. Thank you. This is an awesome tool and I've enjoyed building with it today.

 

Here's what I achieved with this framework:

This is a remake of UnrealEngine4 demo scene. There are still some bugs with cubemap projection and a lack of cubemap blending but looks very similar.

 

Very nice. My eyes were searching for something that was not shiny though. You nailed the tile work at the beginning of the video but the brick wall near the end is just as shiny.

Not comparing our two projects because yours is much cooler but if you stop at 19 seconds on my video you'll see a flat green plastic in a golden frame. That type of contrast shows off the technique better than everything being highly polished.(IMO)

 

You know what, you are some kind of shader writing beast, very impressed, and you've won me over, i'll leave lux importing into a project overnight just so i can play with it because i'm getting particularly impressed by it now. I know you make some changes to things that may affect other similar pbr approaches, i was told, then i forgot, so i'm feeling a bit dim, but if it's not such a problem as to stop them both working in the same scene, that would be useful information. I have a scene that I was originally intending to use Skyshop with, along with candela, but the sss solution offers an alternative to having to forsake using glass objects in the scene, of which there are several - if they are considered to be made of some kind of translucent material instead, like some form of plastic, with lux's treatment of it, it would look a hell of a lot better than just removing the glass entirely, assuming they will be backlit from lighting behind them, and they use transmission masks to get the effect fully working on some of the more complex glass forms

 

I did a clean project, imported Lux from the Asset Store, chose the base demo scene and tried to build and got the same error. I'm going to test your most recent link and see if that cleans this up.

edit** - wow. huge diff between the codebases. I'm not sure if you intend on updating the Asset Store version but it's rickety compared to your githup repo. Not sure if it fixes the issue. I'm waiting for all of your tasty shaders to compile

 

Bam. I updated to the most recent repo and it solved the build problem. It also solved the box projection issue.

This art is repurposed from the Industrial Sci-Fi Kit. I did have to re-author most of the textures to fit the PBR shading model.

I do have a workflow issue. When you're using modular components to build your levels you end up needing to add hundreds of game objects to your environment probe. It's a real beating.

A couple of ideas to help alleviate the grind would be to allow the user to tag game objects and just pull all game objects with that tag in.

A more interesting idea would be to use the bounds of the box environment probe as a trigger and have it populate the game object list when you press a button, and then let the user exclude anything they don't need, or add anything the trigger missed.

Because of the modularity of the level and the need for unique cube maps per room, at this point the best workflow is just to duplicate your prefab and copy the material so it can be unique per room. this gets rid of the need for the cube mapper entirely at the cost of some extra draw calls. I haven't checked the library since I updated the repo but the Asset Store version doesn't have a box projected illumination shader either. Just doing unique textures per cube map solves this issue as well.

Great toolset. It's a lot of fun to play around with and was a great introduction to authoring textures for a PBR system. Appreciated.


edit** - I realized I didn't have the updated cubemap on the floors so they look better now.

 

hi there,

you are making fun of us, aren’t you?
i can not believe that this amazing video was rendered using lux. so could you please post some in engine pictures?

lars

 

It's possible actually. don't tell me that you don't realize the capabilities of your creation!!!!???
but honestly i'm curious about the SSR, which one did he used for ssr :/

 

I'm curious about the performance difference experienced between the Unity and UE4 versions.

 

hi there,

i am glad that the latest version fixed your problems (although the reflections at the ceiling still look a bit weird?).

i see. but i am just a one man show... so i wished if somebody could jump in here.

neither the repo nor the package contains all possible permutations of all possible features because there are just too many...
however i might think of adding a self illuminated box projected shader as it seems that it is a quite popular feature on sci-fi environments ;-)

thanks!

lars

 

I could try help making some simple editor tools,
but someone needs to write the specs/requirements that what it should do..

 

great!
well, first it should be easier to assign your meshes/materials to the script.
personally i do not care if it is done by tag name or any other way. my first thought was: allow to drag nested game objects to the script and make it find all mesh renderers within that have a box projection shader attached.
have a look at "SyncAssignedGameobjects" in "LuxEnvProbe.cs".

lars

 

View attachment 95753
As you can see I wrote custom shaders re-creating UE material graph with parameters to achieve identity. I didn't manage to fix normal maps though: in UE demo they always visible even in dark areas and on very rough surfaces (diffusing light).
Also I limited reflection intensity for non-metal surfaces to 25% compared to metallic ones. Don't know if it is physically correct but looks like UE pbs works somehow as that. Never worked with shaders that much before but it is fascinatingly Do you have some thoughts about cubemaps blending approach? I'd like to try this.

I wrote additional simple function for probes for gathering nearest objects in radius and assigning cubemaps on material instances during gameplay instead of sharedMaterial in editor. But probes lose their cubemaps after exit. Still investigating how to fix it (Get Generated Cubemaps button doesn't work somehow)

I used Candela ssrr to achieve better result but I can't say it does too much for such a static scene.

 

hi there,
unfortunately your image does not show up...
lars

 

Ahh... Not sure if there is a way to enlarge this or somthing... nevermind. You can still see there are many parameters controlling roughness, layers etc like in UE material instance editor.

 

Hmm speaking off another editor extension, is there any other ways to scale the box projection size, somehow using scale gizmos kinda weird.
i was thinking something like how we scale box collider (using shift and drag the small rectangle on it side), is anybody know how to mimic this??

 

wow!
that is absolutely incredible!

usually image based ambient lighting should make your normals visible – even in unlit areas. and it does not matter if you have a rough or a shine material as both diffuse and specular ambient lighting will help to make your normals visible.

hmm, reflection intensity should be automatically be driven by the specular color which differentiates between metals and dielectris.

you mean blending between different local cubemaps for moving objects?
not really but i would likely do it by script and pass the blended cubemaps to the materials.

lars

 

When using Skyshop i did do exactly this - to scale and position the box projection size I put the position of the sky gameobject, which held the actual settings and env maps where the env map was probed and then attached a box collider, changed the collider to a trigger then scaled the sky gameobject using the box collider as a guide

This has 2 advantages - 1 you can see exactly how the projection is scaled and 2, you now have a trigger zone to switch to an appropriate set of maps for anything with the shader on with box projection settings turned on

I don't know if any of you saw the 2014 gdc video for skyshop but one major feature was it blended between env map sets based upon which trigger area the object was in, based on these trigger boundary areas for the box projection. Setting up the boundaries could be done completely manually, switching done with a script

http://www.youtube.com/watch?v=ENrMQ0aIV-k as you see they have a debug setting that shows the box projection zones as the skyshop materialled balls fly into them. Then the correct map is blended in. They're also aided by the fact that they're doing the convolution on the GPU extremely quickly - i'd i'magine they only do this once for the first object to enter an area and then the results stored for any others. This is all stuff worth looking into, even just being able to set your 'zones' up in a scene beforehand and prebake all your envmap probes for each zone would be really useful

With that stuff in, the only thing that would be missing for me would be Shader Forge integration, which i'm sure the dev would have no problems being approached about

 

Ahh...so they did use collider, now that easier to implement....
the Cubemap Zone i mean

 

I have a couple of shader ideas that don't currently exist for lux (or at least I don't think they do).

1. Simple Overlay Shader: this is a shader that most artists use for rocks, but can be used for just about anything (precursor to dissolve shaders, ect). Essentially you have 2 sections of diffuse, metalness, roughness and normal, and one of those sections overlays on top of the other with various opacity settings.

2. Uncharted/TombRaider Wetness/Dirtiness Overlay Shader: this is a variation of the overlay shader but it has the added advantage of being modifiable at runtime to achieve effect. The most basic example would be using a position map to dynamically increase roughness and add darker color to the diffuse map to simulate the effect of being wet.

The position map is used to make sure the wetness goes from the feet to the head and a collision check at runtime can be used to set the height of the effect on the character model.

You could also use this same system to add "dynamic" dirtiness to a character. Both Uncharted and Tomb Raider Underworld use this type of shader. It is extremely simple to create in Substance designer 4 (as a dynamic texture) but requires a custom shader for speed reasons.

 

Sorry, I have a question as well.

Maybe its because I am an SD4, UE4, and alloy user but why are most people using specular/glossiness instead of roughness/metallic? Maybe I am crazy, but roughness/metallic makes way more sense and seems to be the way the AAA engines(ie UE4) plus disney are defining pbr.

 

If you created a solid system for that, you'd be some kind of hero, a similar debugging implementation would be incredibly useful too

Now extra question - how straightforward would it be to make every relevant shader in Lux have box projection, because it seems to be treated so far quite underwhelmingly by all of these solutions, but I think it's getting pretty vital, especially to augment something like Candela. Shader compilation is a time consuming process too, so i'd imagine it seems like a pita to convert so many shaders. But if it's viable and I can find everything I need in the existing box projected shader, ill get stuff to read and convert a few that I think will be very useful, i have nothing particularly to do today so with a few pointers I dont mind doing that

 

Actually according to the GIT it needs an update first for the things i'm particularly keen on, so I shall leave it for now! I'm basically hoping for the new SSS which i'm unreasonably excited about, aha, especially for use with a transmission mask/map, and naturally adjustable reflections because that's essentially my fix for glass until Candela figures alpha out, if Rea can figure out these zones thingies (i made up calling them zones i think but hey you can keep that) and make a system for that prior to an update also then you guys really are sitting on something big, i'm checking the repo and you already have some dream stuff in there

But yes with the translucency and sss i can forget about worrying about glass for now as well as do a variety of interesting plastics/rubber/wax (esp with bump in there) and so on, which I find significant, personally, especially as in traditional raytracing these effects take an absolute age to render

And then i'll spend some time making each shader i use box projection, when I know how, and even despite that, i'll set up the my planned scenes to showcase this stuff for skyshop and then do lux versions too, this is important for personal work especially, and when I start adding character models to the scene.. well, that gets exciting!

 

Here's the "corrected" screenshot at the edges.





In the first screenshot you can see the correct reflection at the edge where the floor meets the wall.

In the second screenshot you can see the correct reflection at the ceiling edge, which is picking up the cobalt metal walls. In the first shot you're picking up the same cobalt because the ceiling is modular and has the same material, and in the second shot you can see the green from the other room reflected in the floor.

The illuminated parts of the ceiling don't have a box projection shader so they're picking up the world based cube map.

Flash forward to when you have a box projection for all of the permutations I'm using. You're essentially going to need a unique material per modular map piece, per environment probe, to get fully accurate reflections.

So you spend a bit more in draw calls because of the extra materials, and your modular set up is a bit more complicated as you end up having permutations of very similar pieces.(In my example, I would have aluminumFloorRoom1, aluminumFloorHall1, aluminumFloorRoom2, etc... each permutation a different game object, because each room needs a unique material set.

If you alter the workflow in this way it brings you several things. You don't actually need a box projector unless you want to exclude a static object from the reflections. Set up a regular environment map, capture your cube, and assign it to your prefabs for that room. You'll get accurate reflections without having to capture each game object in a list.

I don't mind contributing, I'm just trying to reason through the workflow. It seems inevitable that you'll need a unique material per "box" if you want accurate reflections, and if that's the case I'm not sure the box projection branch has a place in the workflow except for rare exceptions. I'd appreciate your input on this line of thinking.


edit** - unless the box projection isn't actually assigning the cube map to the game objects material and just uses its position and looks up the correct cube map at run time. I didn't actually think about that. If that's what it does I may need to start figuring out if I can do an OnTrigger in edit mode and help collect the proper game objects.

 

@ Jmatthews - I don't really understand, cant you just change the env maps used by the shader on the material when it's inside the bounds of the box used for the projection? Assuming you used a box collider set to trigger as your guide for the bounds

 

well, iguess it is up to the author of shader forge to integrate lux or not.
but – as far as i know – shader forge does not allow to create shaders using deferred lighting – which would be a big minus at least for me.
please correct me if i am wrong.

lars

 

@larsbertram1 excellent work! Much appreciated.

@dnnkeeper Nice! Could you provide a online demo of that scene? or possible the scene itself I'd love to play with that.

 

Yes, you can. My entire line of thinking was off. re: needing multiple materials.


edit** - I was assigning cube maps after convolving them. If you add the game object to the probe and make sure there is no cube map assigned to the specific object it works as it's supposed to. Having the same prefab using two different probes(for the different rooms) was throwing me.

 

that is more or less the "Lux Bumped Specular Detail" shader (without opacity settings i have to admit).
alternatively you can have a look at the "Lux VertexBlend Simple Bumped Spec " shader.

that is a bit more complex – and would need a whole set of dedicated shaders and script to control them.

hey, you are absolutely free to create your own shaders on top of lux lighting functions which is not taht big deal i hope;-) and dnnkeeper just has shown how mighty those can be.
you can even sell them on the asset store if you think you have done something very helpful – but of course it would be much nicer to just share them with the community.

so personally i think it is best for me to just concentrate on improving the core and adding further essential features (like specular anti aliasing).
but if it comes to wetness effects: here you have a first impression of the upcoming advanced foliage shaders v.3 – based upon the lux lighting functions bring physically based shading and physically based wetness:



lars

 

hi there,

i hope you did not get me wrong,
any suggestion or feature request is much appreciated. you guys using lux will probably have much better ideas than me.
but in case i can not respond to those anybody is invited to take part in this project.

lars

 

thanks.
and do not hesitate to show what you are doing with lux here as this thread could use some more pictures i think.

lars

 

hi there,

i have just added the subsurface scattering shader to the repo – next to a self illuminated boxprojected one.

but may be even more important: i have refactored the core.
so now you do not have to write to o.deferredfresnel in your surface function anymore.
so i have removed this from all shaders.
unfortunately this will likely make you reimport and recompile all shaders... but you do not have to do so if they just work fine for you. all "old" shaders will just work even if you update the core and import the new sss shader. but as soon as you make any changes to existing shaders they might break. so please update those before you do any changes.

update note for custom shaders:
remove:
#if defined(UNITY_PASS_PREPASSFINAL)
// Fake Fresnel effect using N dot V / only needed by deferred lighting
o.DeferredFresnel = exp2(-OneOnLN2_x6 * max(0, dot(o.Normal, normalize(IN.viewDir) )));
#endif
from the surface function as it now is part of the "LuxLightingAmbient.cginc".



lars

 

I've been following Shader Forge with much interest as it's going to allow me to do quite a few things i'd otherwise find very hard (most particularly a rather advanced ocean shader i'm ging to be trying to write for both dx9 and dx11 with the dx11 version being very very fancy) and all the posts relating to Skyshop from shaderforge, (And shaderforges mention in skyshops recent snow video they showcased at gdc 2014) seem to imply that the integration is a two way thing, both shader forge and skyshop have had to be adapted to support other. The upshot of this pairing is, you could then make an enormous range of shaders benefitting from skyshop's ability. I imagined the same circumstance would hold for Lux

Regarding deferred rendering, this is the next big feature for the editor that seems to be getting very near to release - http://forum.unity3d.com/threads/22...hader-editor?p=1592459&viewfull=1#post1592459

Has a few caveats and all and might be worth waiting till it's there for support but i think it would be pretty neat to have it as an option

 

of course it would be nice if shader forge would support lux.
but lux rely on a tweaked internal prepass lighting function (when talking about deferred), custom fog on some very complex shaders that unity is unable to inject the needed code into and even 2 custom depth passes to make shaders work under opengl: so it is quite a lot to handle.
but i will contact the author and see what he says.

lars

 

i tried to do a pull request but I'm a github noob and couldn't figure it out.

Code (csharp):

1.     @@ -153,6 +153,8 @@ public class LuxEnvProbe : MonoBehaviour {
2.             // Get all objects
3.             for (int i = 0; i < AssignedMeshes.Count; i++)
4.             {
5. +               if(AssignedMeshes[i])
6. +               {
7.                 if(AssignedMeshes[i].renderer != null)
8.                 {
9.                     int materials = AssignedMeshes[i].renderer.sharedMaterials.Length;
10.     @@ -173,6 +175,7 @@ public class LuxEnvProbe : MonoBehaviour {
11.                     AssignedMeshes.RemoveAt(i);
12.                     break;
13.                 }
14. +               }
15.             }
16.         }

this fixes the issue where if you delete a gameobject referenced by the environment probe it errors out the LuxEnvProbe script and won't let you see the list of game objects it is managing.

b.t.dubs. Thanks for the box projected illuminated shader.