Marmoset Skyshop - Image-Based Lighting Tools [RELEASED]

I just tried this...and it breaks the shader... :/

 

New version fixes it for me.

 

not sure what you means "breaks the shader"
these files are common to all shaders.

monkeyscience said he will fix it in the next release.

The problem is only in deferred mode AND when the shader doesn't have a normal map.

In the MarmosetSurf.cginc, the original code is:

PHP:

    //NORMALS
    #ifdef MARMO_NORMALMAP
        float3 N = UnpackNormal(tex2D(_BumpMap,uv_bump));
        #ifdef MARMO_HQ
            N = normalize(N);
        #endif
        OUT.Normal = N; //N is in tangent-space
    #else
        //OUT.Normal is not modified when not normalmapping
        float3 N = OUT.Normal; //N is in world-space
        #ifdef MARMO_HQ
            N = normalize(N);
        #endif
    #endif

See the line:
float3 N = OUT.Normal; //N is in world-space

change it to:
float3 N = IN.worldNormal;

so the code will now look like:

PHP:

   //NORMALS
    #ifdef MARMO_NORMALMAP
        float3 N = UnpackNormal(tex2D(_BumpMap,uv_bump));
        #ifdef MARMO_HQ
            N = normalize(N);
        #endif
        OUT.Normal = N; //N is in tangent-space
    #else
        //OUT.Normal is not modified when not normalmapping
        float3 N = IN.worldNormal;// <--CODE CHANGE
        #ifdef MARMO_HQ
            N = normalize(N);
        #endif
    #endif  

now since "MARMO_NORMALMAP" is not defined in Diffuse/Spec IBL, you will have an error cause "IN.worldNormal" will not be defined.

so to fix that you have to change MarmosetInput.cginc

original code:

PHP:

struct Input {
    float2 uv_MainTex;
    #ifdef MARMO_NORMALMAP
        float3 worldNormal; //internal, required for the WorldNormalVector macro
    #endif
    #if defined(MARMO_SPECULAR_DIRECT) || defined(MARMO_SPECULAR_IBL)
        float3 viewDir;
    #endif
    #ifdef MARMO_SPECULAR_IBL
        float3 worldRefl; //internal, required for the WorldReflVector macro
    #endif
    INTERNAL_DATA
};

delete or comment out the def check so the code will look like this:

PHP:

struct Input {
    float2 uv_MainTex;
    
    float3 worldNormal; //<-- CODE CHANGE - Now shaders will have access to this
    
    #if defined(MARMO_SPECULAR_DIRECT) || defined(MARMO_SPECULAR_IBL)
        float3 viewDir;
    #endif
    #ifdef MARMO_SPECULAR_IBL
        float3 worldRefl; //internal, required for the WorldReflVector macro
    #endif
    INTERNAL_DATA
};


so the shader will have access to "worldNormal"

it's 2 quick changes...and only needed for deferred mode with shaders that don't use normalmaps.


best I can explain

 

Perfect... thanks

 

how did i never knew about this project. It's amazing

 

1.031 patch incoming!

It's a minor one, pending Asset Store review right now. I've made the few fixes mentioned in this thread, including:

• Fixed worldNormal bug in deferred rendering path.
• Fixed Mobile "Auto-Detect Colorspace" bug.
• Removed d3d11_9x support from all but mobile shaders (will warn harmlessly in Unity 3.5 but fixes legitimate 4.x warnings).
• Made calls to Util.cs explicitly use the mset.Util namespace (should help with scripting conflicts).

 

Sweet... I'm enjoying this new update... looking forward to your next surprise...

 

Nice i like that
i am going to review it in the asset store

 

Ah, it's unfortunate but this latest update has messed up reflections as well as caused some other lighting issues which are making it unuseable for us. Sadly we've had to pull Marmoset out of all of our projects and go back to less exciting and beautiful options It's amazing at creating those nice confinded turn-table renders but stick this thing in a real time environment with all sorts of stuff going on and it's not quite ready for a production pipeline yet.

Can't wait for the day that it gets there though!

 

Does this addon require a static sky (without day night cycle)?

 

Sorry to hear that. From the old thread I can see you guys are using deferred lighting; there is a 1.031 hot-fix for deferred lighting normals on the way, pending asset store review. Check back occasionally, we are actively growing this project .

 

Unfortunately yes, the skies have to be pre-processed so in-game changes to the sky cannot change the lighting. Changing sunlight can still be modeled with a direct and shadow-casting light source. You could model the image-based sky lighting to be your ambient lighting term and use a moving, changing direct light for the sun.

 

1.031 hot-fix is live
https://www.assetstore.unity3d.com/#/content/8880
Get it while its hot!

 

Bonjour, ironbelly.

As someone interested in Skyshop with "all sorts of stuff going on" as well, would you mind elaborating if that comment was in response to the patch that altered your experience, or just in general?

Merci

 

So After the update i got these errors : (re-download re-import all the same)
=============================
Assets/Marmoset/Skyshop/Script/Sky.cs(63,74): error CS0030: Cannot convert type `int' to `CubemapFace'
Assets/Marmoset/Skyshop/Script/Sky.cs(63,52): error CS1502: The best overloaded method match for `UnityEngine.Cubemap.SetPixel(UnityEngine.CubemapFace, int, int, UnityEngine.Color)' has some invalid arguments
Assets/Marmoset/Skyshop/Script/Sky.cs(63,52): error CS1503: Argument `#1' cannot convert `object' expression to type `UnityEngine.CubemapFace'
============================
i don't even have locomotion installed
Please do updates that fix bugs not add them...

 

Hey Monkeyscience, is there a way to enable transparency in the Self Illumination shaders? I am planning on doing a pair of sunglasses and I need the lenses to be semi transparent...I could use the simple glass, but I don't know how much of a performance hit with multiple materials...

 

Try Transparent/Simple Glass/Bumped Specular Glow IBL, I use this for the vespa turn-signals.

 

The only problem also is the model is setup to use the upcoming skin shader...

 

Can i ask for a refund please ? its not working and you are to busy with other customers.

EDIT : Again i found the conflict. this time its with Graphic Power-Up asset.
whats wrong with your asset conflicting with others ? never had this issue before and i wasted 3 days going throw my asset to check for the conflict 2 times. with zero help from you.
Good luck with the sales but please release it when its ready so we all can be happy.

 

Util.cs conflict should have been fixed by 1.031. What was the conflict this time, do you know?

 

Conflicts aren't the fault of asset makers, if anyone's to blame it's unity for not allowing namespaces which creates a lot of potential collisions, it's no more his asset that conflicts than the other one and he can't help you with this because he can't purchase every single asset and test it, you shouldn't expect any help on this as this isn't product support, it's making assets work together and that job is on YOUR side.

Just chiming in as i followed this thread and you're looking as one impatient hard customer, complaining (after 5 hours!) about how long it takes to fix an issue that isn't even one caused by his asset!

 

Well if you where following the first conflict was with locomotion from unity and after i figure it out the update was out and it fixed it BUT another conflict arise. ( i don't know where you live but that is way more than 5 hours where i live)
i don't think its MY job to recheck all my asset after each update that will be wasting 1 day just to check.
i am not a programmer so i don't know exactly where the conflict is, i use PlayMaker for my programming needs. there must be away to stop this, having a big project is difficult not to mention sorting asset conflicts.
on another note : i never had this issue with my asset before (they are a lot)

 

5 hours is 5 hours, it doesn't depend on where you live. And no, there is no way to fix it the more assets you add to your projects the more likely there are to be conflicts, this is because of a choice unity made to disallow C# namespaces. Normally you can have as many class named "whatever" in your project, as long as they're in diferent namespaces. However with no namespace support as soon as someone will make a class, if it's something pretty common, then as soon as you import another asset with the same class name you'll have the issue. I have ~=130 (paid) assets from the store i use, it just happens as soon as you use a large one it's bount to have at least 1 or 2 classes with pretty generic names and poof, you'll get a colision sometimes, it's important to understand this is NOT an error from the programmer, it's just bad luck, and it can't be fixed before it's reported (unless someone tests purchase every single asset to check if he's not using the same names ever, and that's bound to break in an update anyway).

So short version, yea i get it you're not a programmer, you can't fix it yourself, it's frustrating. But do understand that 1) this is not an error from the guy who made this, it's just bad luck (or if you look deep through, a huge early mistake by the unity team we're all paying for now) and 2) there is no way for him to get the same error unless he also has the same assets so he really can't help you much nor fast unless you're very specific with the error.

Also the asset store validates packages before they're accepted, so if you import something and get an error upon launch 99% of the time it's something on your side (in your project or from another packages) else it wouldn't have made it through the store get rejected instead of approved, so next time you update and get a compile time error, make sure your default thought is "crap, another incompatibility between 2 products" and not "damn, this product sucks they broke things again".

 

correct me if i am wrong but isn't adding unique pre-fix to the classes and variables will avoid conflicts ?

 

Unfortunately Ronan is right, there is no way for me to guarantee Skyshop code will not conflict with the thousands of third-party assets available in the store. I have to tackle these bugs as they come in, so I appreciate everyone's patience and assistance with calling out conflicting assets and helping me narrow down the causes.

As for turn-around, it looks like even quick patches have to pass through the Unity asset approval process which seems to take a minimum of three business days. This puts a damper on getting hot-fixes to you guys right away.

Meanwhile, please continue having awesome discussions on shader tweaks and code fixes in this thread. It will help out everyone in the community and I will work on getting your ideas changes into formal releases.

 

It does but :
1) It's a hack
2) It only works if you use something long enough to be rather unique
3) It means rewriting the whole code base (for all assets) which means lots of chances to introduce actual bugs if the codebase is semi-large
The best bet is using namespaces by compiling all of the code in a dll ( using namespaces in there) keeping as little code outside (basically the scripts that need to be dropable on components only i guess?) as raw code, limiting the clash to those classes which can reasonably be prefixed reference the DLL classes (where commonly clashing names would be).

This is reasonably doable but i doubt you'll get many asset makers to do this as we are few to use "many" paid assets in the same project. What would be a good solution however would be to introduce namespaces in unity but I'm not counting on it

 

Namespaces do seem to work with non-Unity things, for instance the Util class is in the "mset" namespace already. My fix for 1.03.1 was to use the namespace explicitly everywhere: mset.Util.blah. I might have to give my other classes this same treatment.

MonoBehaviours and other editor class derivations don't namespace though, which is a problem. Sky.cs might just have to change to MarmosetSky.cs. I worry this will break every level anyone's ever assembled with skies in them, so I've been hesitant to do it.

 

I wouldn't hesitate too long, either do it now or don't do it, your product's still young so you probably won't be affecting too many customers at this point, but the tradeoff is the same as for other asset makers, either fix it break all existing customers (one shot), or don't only keep breaking a few people (but forever). Two bad choices you need to pick one

 

Btw, this works like a charm ... especially for the glossy part of a persons eyes. And if this takes normal maps, I can imagine refraction being the next step for this. Will you include glow in the Skin shader as well? Such as for glowing face paint

 

Hi monkeyscience, do you think this feature will make it to the next update?

Thanks man!

 

Yeah I'm going to try to, I really don't want diverging feature lists for pro and free.

 

I really appreciate this.
Thank you!

 

Is there a way to compute Skybox, Diffuse and Specular cubemaps during runtime ? Or maybe could you expose all the inputs and the computation.
It would be an awesome feature !
How can I convert my cubemap to be usable in a Skyshop shader at runtime ? Could you expose the convolution process ?

 

Purchased it on asset store. Gota say my models look absolutely awesome with the shader. However I am having one issue, whenever I initially load scene all models that are using marmoset shader are solid black and I have to load demo scene first to get it working.

 

Do you have a Sky object in the scene? You'll need to create one in your scene and assign the proper lighting cubemaps to it for the marmoset shaders to work.

 

I just purchased this today to try out on our project and when I install it I get a list of errors

"Assets/Marmoset/External/Lightmapping Extended/Editor/LMExtendedWindow.cs(55,44): error CS0117: `Path' does not contain a definition for `GetDirectoryName'
Assets/Marmoset/External/Lightmapping Extended/Editor/LMExtendedWindow.cs(56,43): error CS0117: `Path' does not contain a definition for `GetFileNameWithoutExtension'
Assets/Marmoset/External/Lightmapping Extended/Editor/LMExtendedWindow.cs(57,44): error CS0117: `Path' does not contain a definition for `Combine'

and 16 more similar errors.

Has anyone ran into this?

Thanks in advance

 

that fixed it, thanks!

 

+1, This would really be Great and makes SkyShop even that much more Awesome.

 

Hi, shaders are amazing. We love them and use in our projects.
But we found what shaders making lightmap much brighter in shadows the standard unity shaders. We can not achieve deep shadows. How to solve this case? Please see examples below.
normal unity shader


mormoset shader

 

I usually set the diffuse color down to a half way point... usually works for me

 

We tried this way too. It makes the bright side darker, make our lightning pipeline more complex and etc. Will be very good to solve this case inside shader. Hope mamoset developers read this forum thread. Example with diffuse color down below.

 

Actually, looking at the other image again, show me your light settings... I think I could fix your issue. This happened to me too at first until I fixed the light.

EDIT: Then again, this IS HDR lighting so brightness is expected. If you click on the sky object, you can turn down the diffuse strength...

 

The trouble here is the sky lighting is added on top of your lightmaps but you already have an ambient term in your baked results. Then what you're doing with 50% grey is averaging between the lightmap ambient and the IBL ambient, maybe not the ideal solution.

You'll want to remove all ambient color from your lightmaps and let the Sky object add it at run-time. When baking, try setting "Environment Type" to "None" in the "Beast Global Illum Options" of Skyshop or setting the "Sky Lighting Color" to black if you're using the standard Unity baking interface.

Alternately, you could bake 100% of the sky lighting into your lightmaps, using "Beast Global Illum Options" again, and turn off diffuse IBL entirely. Leave the Sky object's diffuse cubemap empty or set the "Diffuse Intensity" to 0. This would affect all objects in the scene, including non-baked ones which might not be desirable. You could also put a tiny black cubemap in the "Custom Diffuse Cube" slot of your baked materials to disable diffuse IBL on just some objects.

The lightmapping workflow is admittedly rough around the edges right now. The interaction between dynamic and baked lighting in Unity is complicated already, adding IBL into the mix isn't making it easier :-/. I'm still working on a good, presentable solution for it.

 

Hi,

I have just noticed an issue with casting shadows from objects when using the mobile shaders (only checked this in my viewport but will try it on device later today) If i use the Mobile Bumped Spec IBL material my object casts a shadow BUT when i change it to use the Mobile Spec IBL the object stops casting shadows for some reason. My object does not really need a normal map so i would preffer to use a more cutdown shader like the spec IBL so would be good to know if this is a bug or if im doing something wrong lol

 

Is skyshop support lightmap?
I would like to bake lightmap in 3dsmax using vray and use in Unity3d same Legacy lightmaped

 

Skyshop fully supports Beast Lightmapping.

 

The moment you create a multiple probe system for different locations in the environment... i will be all over this.

 

I bought skyshop for unity on my desktop and was wondering how to use it on my laptop as well?

 

Once you buy it you can use it in any project, you'll have to download it again through the asset store but you will not be charged a second time.

 

Thanks for the quick reply! Great stuff...