Your import seems to be broken, even the inspector/editor code didn't load.
Delete all the files from the previous version and reimport the latest unitypackage.

yeah, not sure why they dont work for me. I'm on Unity 5.3.6

I had this issue. See my post a few posts up. Check your console to see if you see 1 error that matches the error mentioned in my previous post.

MattouBatou a écrit

I had this issue. See my post a few posts up. Check your console to see if you see 1 error that matches the error mentioned in my previous post.

Ah, thanks that was it. I was not getting anything logged to the console, I must have missed your post. Thanks for the help

Glad it was helpful. I spent a good while scratching my head wondering why the inspector panel looked different to the screenshots in the rest of the thread. If it wasn't for the console logs I was getting, I would have been clueless too. It's a little odd that you didn't get any logs. Ah well, happy shading!

As a sidenote: I recommend Sprite Illuminator for creating your normal maps. I've been hand "carving" them using the angle brush tool and it's been a dream. I attempted setting up a workflow in Photoshop but was a pain previewing the normal map with lighting on a mesh. Sprite Illumintor has a few handy views you can flick between as you paint.

Thanks for all your work @ToddRivers!

I'd definitely be paying for your work, please put it on the Asset Store! Is there a way to get in touch with you directly, maybe to get some active and responsive support, possibly supported by donations?
I thought Spine runtimes for Unity included some basic lit shaders but all the work you're doing is definitely a must have for every Unity Spine user!

Some general questions:

Which Unity Runtimes do your shaders work on? Have you already tested it on Unity 5.4.2f2?

Do the shader support ambient lighting, spot, omni and directional lights?

@[supprimé]
I had an idea.
Speculars.
And Spec map.
Not a request. : p

Pharan a écrit

@[supprimé]
I had an idea.
Speculars.
And Spec map.
Not a request. : p

I'd love to have them as well. And maybe refraction shaders as well, for "predator-like" effects
Willing to pay for such features as long as support is given, please consider the Asset Store

Correct me if I'm wrong but I believe the esoteric team have already mentioned elsewhere in the forums about not wanting things on the asset store to rely on Spine's Unity runtime. This is because it is then only usable for those people with Spine. With that in mind, I expect that a "Super Shader Pack" would need a considerable amount of extra work to ensure they can also be used with any Unity prefab without any programming experience required to use them.

I'll be adding some shaders of my own to work with Todd Rivers shader collection within the next few months. When I do, I'll post them here. A Specular shader is something I'll do if someone else doesn't do it first.

MattouBatou a écrit

Correct me if I'm wrong but I believe the esoteric team have already mentioned elsewhere in the forums about not wanting things on the asset store to rely on Spine's Unity runtime. This is because it is then only usable for those people with Spine. With that in mind, I expect that a "Super Shader Pack" would need a considerable amount of extra work to ensure they can also be used with any Unity prefab without any programming experience required to use them.

I'll be adding some shaders of my own to work with Todd Rivers shader collection within the next few months. When I do, I'll post them here. A Specular shader is something I'll do if someone else doesn't do it first.

I can't correct you, I still haven't read all the forum threads since I only registered yesterday.

I believe if Esoteric released the runtimes as a package in the asset store that would be feasible. Wrappers for other devices (mostly bound to VR) or softwares or runtimes (eg:LeapMotion), are present in the store, so I believe it's possible. I don't know the details so I won't insist. Even if, if the shaders are going to be useful in my project I'd gladly make a donation

Yes, mantaining a package in the store requires work (I'm mantaining several), but you also get some funding in exchange to keep yourself motivated and the package alive.

I think this is a bit off-topic, I'm not going to reply anymore about this on this thread, mine was simply the wish of an enthusiast

You should consider putting them on the asset store, not for profit, but for convenience.

Put it up for $.99 and then it will offset the internet costs for time spent on this.

Hi ToddRivers,

Great progress and updates!

I ran into some performance spikes with your shader. Not really sure how it occurred, but thought maybe you'd want to know? (FYI it's using an older version .. so maybe your latest iteration fixes this)

Anyways keep up the great work and thanks for everything.

@ToddRivers. Nate wants to bundle it with the runtime but I'm trying to figure out how to proceed.

I've been recommending your shader to people who need these features and the common reaction seems to be: "whoa. that's too many features for me." Even though I try to explain that features you don't use don't affect performance. So I want to make some changes to the inspector (spine-friendly defaults and user-friendliness) before then.

I also feel like I need to rename the shader to "Spine/Sprite/Sprite somethingsomething" so people don't get a random "Game" folder in their shaders and so it doesn't get jumbled up with the others. I was thinking something like this:

But it seems a bit too long.

Anyway, I'm wondering about your thoughts on continuing work on it. Like, will there be two versions? Yours and Spine's? Or would you do PRs on the spine-runtimes git repo directly?
I don't want to impose any weird stuff too (in case I make changes to the inspector) if they don't work for the project that you're working on. But I also want to confidently make updates if ever you make changes that require inspector changes too.

Pharan a écrit

@[supprimé]. Nate wants to bundle it with the runtime but I'm trying to figure out how to proceed.

I've been recommending your shader to people who need these features and the common reaction seems to be: "whoa. that's too many features for me." Even though I try to explain that features you don't use don't affect performance. So I want to make some changes to the inspector (spine-friendly defaults and user-friendliness) before then.

I also feel like I need to rename the shader to "Spine/Sprite/Sprite somethingsomething" so people don't get a random "Game" folder in their shaders and so it doesn't get jumbled up with the others. I was thinking something like this:

But it seems a bit too long.

Anyway, I'm wondering about your thoughts on continuing work on it. Like, will there be two versions? Yours and Spine's? Or would you do PRs on the spine-runtimes git repo directly?
I don't want to impose any weird stuff too (in case I make changes to the inspector) if they don't work for the project that you're working on. But I also want to confidently make updates if ever you make changes that require inspector changes too.

The inclusion sounds nice to me as long as support is provided for it.
2 versions would be nice. One, with the Uber shader created by ToddRivers without putting him any limits to his creativity and experimentation, and another managed by the Spine team itself, stable, clean, cross-platform tested, optimised for performance and compatibility so that is coherent and well integrated with the package.

The nested shader solution is nice as long as the nesting makes sense, I'd be ok for it.
OT: btw, speaking of folder structure, having the runtime folders directly on the root of the project folder isn't very clean - may I move them elsewhere? (Also, the runtimes contain duplicate conflicting class names (eg: Animation), could you consider the possibility of using Namespaces?)

The Spine.Animation class has always been in the Spine namespace. Unity still incorrectly detects it as conflicting. It's not even a UnityEngine.Component. There's no way it would conflict. We've already reported this bug and support said it's a won't-fix.

We leave it up to the users to move the spine runtime folders into their own folder scheme. Moving (or even renaming) them doesn't break your ability to upgrade using unitypackages. Unity editor still knows where/which original folder and files are are based on their guid and updates them accordingly when you import updated unitypackages.

I should probably make that clear somewhere.

Alright.

I'm totally fine mirroring updates to the Spine-Unity version whenever you update your version but I wish there was some way to find out what changes you actually made so I can match accordingly.

Example scene, definitely. Maybe just a bunch in one scene though. I don't want it to balloon into an exhaustive description of Unity's lighting system. That's not something I confidently understand myself, and would be too much; not even the ShaderForge package does that.

Although, worst case scenario: I just need to make a blank Unity project, version control that somewhere, and just check the resulting changes every time I update to ToddRivers' latest package.

ToddRivers a écrit

I also realised the pixel lit shader wasn't calculating non important vertex lights in its base pass! I never use them so never noticed but thats now fixed

I'm going to use them a lot with bump mapping instead!

A thing that could be missing would be a normal map intensity multiplier, to better fine tune the bump, or to create effects like transitioning to 3d-like to fully flat texture.

I'd do that myself, but would end up with having to make that change on every update, would it be possible to have this feature in the next shader versions?

I think a multiplier (or a color where applicable) could be handy to fine tune the influence amount of other textures in the shader.

Of course, to give some artistic freedom, there wouldn't be any need to clam or limit the value, so a simple float(also including negative values) would be more than welcome

@[supprimé]
Can I ask how you create your normal maps for your spine animated art? I'm looking at using Sprite Illuminator and am looking for any tips / guidance in regards to creating normal maps for a spine animated character. Are you just painting the normal of the packed texture that Spine exports?

rxmarcus a écrit

@[supprimé]
Can I ask how you create your normal maps for your spine animated art? I'm looking at using Sprite Illuminator and am looking for any tips / guidance in regards to creating normal maps for a spine animated character. Are you just painting the normal of the packed texture that Spine exports?

I was using the same tool (trial edition) but I think I'll be using this http://www.2deegameart.com/p/sprite-dlight.html

Is #if defined(UNITY_REVERSED_Z) a Cg directive?

I'm trying to make the Spine version defaults Spine-friendly.
I'm mostly done.
But how do I make it so that "use mesh normals" is false by default?
I saw the conditionals and I got super confused. :p

@[supprimé]

ToddRivers a écrit

Hmm thats weird. The spike is happening when its first setting that shader for use I think. It could be caused by the Unity running out of shader keywords (the defines used to turn shader features on and off, these shaders now have a fair few of them to allow you to switch all the feature on/off).
At the mo I think theres a 64 keyword limit but its going up to 256 in Unity 5.5 so that might fix it!

I've uploaded new shaders that improve the fake spherical harmonics in vertex lighting mode. Should be a lot faster and look a bit better too

Thanks man you're awesome! Been busy recently, so haven't had time to play in Unity, but will let you know how it goes when I do. :beer:

Hi @ToddRivers,

I'm using the shaders of about a week ago and I'm facing a few issues when the sprite gets exposed to Spotlights with Intensity of 4:

Normal:

Lit by a spotlight with an intensity of 4 (using HDR doesn't change anything)

This is the material I'm using:
Note that even changing the blending mode to premultiplied alpha I get the same results.
It's like the sprite is getting... transparent, you can see through it like it was made of veils.

Note how selecting Pixel Lit the inspector still shows Vertex Lit.
Also, sometimes when switching between shaders the shader crashes and shows a pink/error material. Selecting again the shader from the list solves the issue.

ToddRivers a écrit

Hey! Sorry that was my bad, I forgot to change the code when I changed the shaders names so the shaders weren't switching. I actually fixed it just before you posted, if you grab latest the problem will disappear

I've also been messing around with post effects in my project and noticed if you generate a DepthNormals texture for a camera then the normals would be random for any sprites that use a FixedNormal.

I made a new RenderType for sprites with fixed normals and then made a custom shader for creating a DepthNormals texture which renders Sprites properly.
Its prob not of interest for most peops but if you want to use SSAO or a similaur effect that needs the scenes normals then it might be usefull, its on the github anyways

Nice, the new shaders don't crash anymore!

Do you have any clue about the PixelLit shader becoming transparent as per picture?

ToddRivers a écrit

Yeah so Pixel/Forward lighting is done over multiple passes (1 pass for each light) meaning bits of the sprite lit by additional lights will draw over the top of each other and give that effect as there is no depth test being performed.
To use pixel lighting you need to turn on depth writing, however as you cant write a translucent depth value you need to use a hard clipped alpha rather than having a nice smooth faded alpha.
Vertex lighting is done in one pass meaning you wont get that translucent overdraw and can have fully faded alpha but isn't as accurate (although if your sprite has enough verts you won't notice).

It depends on the project / sprite what mode works best. I'd recommend vertex lighting most of the time though but have a play with the two modes and turning write to depth on/off as well as adjusting the alpha depth cutoff value.

Thanks for the explanation!

I kind of managed to make it work, even if I had to ramp up the lights to obtain the same overbright effect.
Z write on, premultiplied apha, and Z spacing < 0.

The lighting still cumulates when different instances of the characters on the same Sorting Layer and Layer Order overlap.

Should I fix this by assigning an incremental value to the layer index, by offsetting sprites randomly on the Z axis, or is there any other shader-based solution available?

(2 final notes: I can't seem to be able to illuminate vertex lit sprites, and I can't choose "Solid" blend from the shader's dropdown menu anymore)

ToddRivers a écrit

Ok I've fixed the Solid dropdown bug. Not sure whats going on with vertex lighting for you, what's your setup? Are you using mesh normals or fixed normals, is the sprite flipped or has it got negative scale?
Vertex lights working fine for me.

Yeah you'll want to shift them along the z axis if your using write to depth and pixel lighting otherwise you'll get Z fighting.

Solved, I thought some basic normals were calculated. I checked "calculate normals" and used mesh normals and all is running fine

Thanks for fixing the issues so quickly!

Yet, it would have been nice to have both alpha blended sprites and proper lighting together on mobile - I had hand painted characters and having sharp crisp cutout edges somehow ruined the "painted" effect. I'm not sure if using deferred rendering is going to be good on mobile...

Hi!, I'm new using this shader and I have this problem and I don't know how to fix it.

Image supprimée en raison de l'absence de support de HTTPS. | Afficher quand même

Whenever I choose one of your shaders the Spine skeleton is rendered this way.
This are the settings for the atlas texture:

Image supprimée en raison de l'absence de support de HTTPS. | Afficher quand même

Also I'm exporting from Spine as pre-multiplied alpha. Straight alpha doesn't work too.
Help?

Thanks!