@ToddRivers good hearing back from ya!

I was getting flickering on 5.5, but I should update to 5.6 to test it out as well. It seems the flickering is gone on 5.5 at least, crossing fingers. Will let you know how it goes on 5.6!

Thanks again for the continued support on this amazing shader!! Let me know if there's anything I can help you out on.

22 Apr 2017, 04:55

@ToddRivers

Just updated to 5.6.0f3 Looks to be good on the flickering issue! Thanks alot for the shader support! We all owe ya a debt of gratitude~ :happy:

Getting this issue in the latest version.

25 Apr 2017, 12:29

ToddRivers escribió

...If in your game you rotate your sprites 180 degrees around Y to make sprites face the opposite way, you should also tick 'Allow Back Rendering' in order for lighting to work correctly when Sprites are facing away from the camera.
If you use negative scale or 'FlipX' instead then leave it unticked and it will save a little bit of processing time ...

Where is this Allow Back Rendering? It is a Unity or Shader feature?

WARNING NOOB Questions below: :sweat:

1. Vertex Lit: I can't figure out how to add more verts, is it done in Spine or Unity? EDIT: Yes you do it through the meshes in Spine Pro.

Is this bad for performance?

2. Pixel Lit: When I drag the Z-spacing <0, the sorting orders get "messy". For example and initiated bullet goes below the character. What is the solution for this? Do I have to adjust the z of everything from now on, instead of the sorting orders?

3. How do everyone do their fancy normal maps? Is there a plugin, or do people do these in Photoshop.

ps. love the shaders and Spine!

PeterBacall escribió

WARNING NOOB Questions below: :sweat:
Is this bad for performance?

I'm not an animator but I suppose it could be bad depending on how many chars like that you have on screen, but I simply don't have the required info about the use you want to do of it to provide a clear answer. Also, if you need the character to simply bend a bit (unless you're doing something procedural like applying a vertex shader which displaces the vertexes in some way), having that mesh is probably going to be a bit overkill, and I suppose you may end up having weird overlapping issues.

NeatWolf escribió

PeterBacall escribió

WARNING NOOB Questions below: :sweat:
Is this bad for performance?

I'm not an animator but I suppose it could be bad depending on how many chars like that you have on screen, but I simply don't have the required info about the use you want to do of it to provide a clear answer. Also, if you need the character to simply bend a bit (unless you're doing something procedural like applying a vertex shader which displaces the vertexes in some way), having that mesh is probably going to be a bit overkill, and I suppose you may end up having weird overlapping issues.

Thank you for the quick response! Here comes more info, correct me if I'm wrong:

I am using the Vertex Lit option in the Sprite Shaders. More verts (as ToddRivers stated earlier) gives a higher resolution light. So I generated a lot of them in Spine, mesh editor. I tried this and it surely results in a high resolution light.
My question is: at what point does the amount of verts get overkill for lighting (performance)?

I noticed I need a lot of vertices for the "Vertex Lit" option to be even near the result of "Pixel Lit". Why I'm not using "Pixel Lit" is because of the problems that occur, for example the Z-spacing making the sorting orders out of order. Overlapping characters were blending with each other etc. Therefore Vertex Lit seemed like a better choice. Can I have 400 verts on each character without really bad performance? I'm aiming for PC and MAC (no mobile).

I think the point here is that if you need to shine a spotlight-like thing on your sprite like in your gif, VertexLit is probably not the way to go.
VertexLit is more ideal for sort-of-ambient-but-slightly-directional light. (eg, "there's a campfire in front", or "there are floor lights in a dark room")

For performance metrics, you'd have to test on your slowest target machine.

Getting PixelLit on 2D Sprites in general is unfortunately still quite the conundrum, especially on Unity for now since its render pipeline is not programmable yet. Unity also has weird sorting bugs even if you set it up correctly. It's really weird.

PeterBacall escribió

NeatWolf escribió

PeterBacall escribió

WARNING NOOB Questions below: :sweat:
Is this bad for performance?

I'm not an animator but I suppose it could be bad depending on how many chars like that you have on screen, but I simply don't have the required info about the use you want to do of it to provide a clear answer. Also, if you need the character to simply bend a bit (unless you're doing something procedural like applying a vertex shader which displaces the vertexes in some way), having that mesh is probably going to be a bit overkill, and I suppose you may end up having weird overlapping issues.

Thank you for the quick response! Here comes more info, correct me if I'm wrong:

I am using the Vertex Lit option in the Sprite Shaders. More verts (as ToddRivers stated earlier) gives a higher resolution light. So I generated a lot of them in Spine, mesh editor. I tried this and it surely results in a high resolution light.
My question is: at what point does the amount of verts get overkill for lighting (performance)?

I noticed I need a lot of vertices for the "Vertex Lit" option to be even near the result of "Pixel Lit". Why I'm not using "Pixel Lit" is because of the problems that occur, for example the Z-spacing making the sorting orders out of order. Overlapping characters were blending with each other etc. Therefore Vertex Lit seemed like a better choice. Can I have 400 verts on each character without really bad performance? I'm aiming for PC and MAC (no mobile).

Honestly, if you're on PC, and are aiming to create a scrolling beat'em'up or platform, I suppose you're going to have about 5-30 Spine entities on screen.

Even on old hardware, per pixel lighting shouldn't affect performance too much, I'd honestly stick with that and find a way to make them work (try both the ToddRiver's and the Spine version of the pixel lit shader, I'm experiencing totally different behaviours).

If you really have to fall back to vertex lit, you could still use a low-med grid, but positioning the rows and columns in a way that they form a bevel around the shape, and also by making the lines follow both the texture details and the general 3D shape of the character. A plain grid gives a suboptimal result in my opinion. You may even fake some sort of bump mapping or rim lighting by positioning the vertexes appropriately.

I suggest to stop and take some time to think about this decision, since changing everything in the middle of the project could simply make you want to trash everything and start over. Or, at least, many would be prone to do that.

decoamorim escribió

Getting this issue in the latest version.

---

25 Apr 2017, 12:29

---

ToddRivers escribió

...If in your game you rotate your sprites 180 degrees around Y to make sprites face the opposite way, you should also tick 'Allow Back Rendering' in order for lighting to work correctly when Sprites are facing away from the camera.
If you use negative scale or 'FlipX' instead then leave it unticked and it will save a little bit of processing time ...

Where is this Allow Back Rendering? It is a Unity or Shader feature?

Hey guys, this was happening when i imported this shader.
We are using Unity 5.3.4f1 (64-bit).
Also there is any restriction for this shader to work on PS4/XboxOne?
Thanks =)

NeatWolf escribió

Honestly, if you're on PC, and are aiming to create a scrolling beat'em'up or platform, I suppose you're going to have about 5-30 Spine entities on screen.

Even on old hardware, per pixel lighting shouldn't affect performance too much, I'd honestly stick with that and find a way to make them work (try both the ToddRiver's and the Spine version of the pixel lit shader, I'm experiencing totally different behaviours).

If you really have to fall back to vertex lit, you could still use a low-med grid, but positioning the rows and columns in a way that they form a bevel around the shape, and also by making the lines follow both the texture details and the general 3D shape of the character. A plain grid gives a suboptimal result in my opinion. You may even fake some sort of bump mapping or rim lighting by positioning the vertexes appropriately.

I suggest to stop and take some time to think about this decision, since changing everything in the middle of the project could simply make you want to trash everything and start over. Or, at least, many would be prone to do that.

Just giving my opinion/conclusion if anyone stumbles upon the same question:

Pharan confirmed what I was suspecting... Thank you!

NeatWolf, that's an excellent idea! I tried the the bevel shape, it looks awesome enough and it performs great! I dropped 30 enemies which used 30 vertices each. It should come out fine, considering I'm probably only going to have 5-10 enemies at once. Everything else, not character related, is going to use something else.. like PixelLit.

ToddRivers escribió

the latest shaders only support Unity 5.6 unfortunately. I don't have time to backwards support old version of Unity

Ouch :-/
Are the official shaders still at least 3 months back compatible?

This would be a bit awkward, also because since Unity acquired Anima2D which is available for free and also starting to be integrated and improved natively, not even having some support for shaders is definitely not going to be of help for a 3rd party product with not-so-cheap subscriptions required by multiple users in the same team :-/

Hey there!

I've tried using your shaders, specifically for the Overlay color aspect of them! That does exactly what I needed it to.

There is a problem, though. I have multiple instances of enemy characters. They all use the same SkeletonDataAsset, the same AtlasAsset, and therefore the same Materials. Therefore when I make just one of them flash red when taking damage, it makes all enemies of that type - enemies that use the same material - flash red, too.

I thought at first that I could make instances of the materials, but then it would break the AtlasAssets, as they are ScriptableObjects. I could instantiate the AtlasAssets, too, but they break the SkeletonDataAssets, because they're ScriptableObjects, too. I mean, I tried it, but with all that going on something broke completely. And I'm not a fan of creating whole new instances of things anyway as that will take up lots of memory.

Is this something you could provide some guidance with? Although perhaps this is more an architectural issue with Spine. I know before that the tinting via the "SetColor()" method was done by modifying the vertices of the mesh (I think).

Thanks very much!

@[borrado]
I think you want MaterialPropertyBlocks.
We have a small writeup about it here: https://github.com/pharan/spine-unity-docs/blob/master/Rendering.md#setting-material-properties-per-instance
Sorry for the lack of images, but there's sample code.
Essentially, setting a specific Renderer's property block overrides the Material asset's property values with its own, which allows you to set values per renderer instance.

I've put up screenshots of the list of property IDs, which you can see yourself by selecting the Shader in your inspector.
https://github.com/traggett/UnitySpriteShaders/issues/9#issuecomment-303629612

For example, to set a MaterialPropertyBlock's Overlay ("OverlayColor") property, you'd go:

MaterialPropertyBlock mpb = new MaterialPropertyBlock();
mpb.SetColor("_OverlayColor", Color.red);
GetComponent<MeshRenderer>().SetPropertyBlock(mpb);

This has been the preferred way to set material properties per Renderer in Unity for a while.

You may have seen modifying the returns of renderer.material or renderer.sharedMaterial as the method in very old Unity code but that has historically resulted in too many bad sideeffects.)

This is also probably the wrong thread. I'll move this to a new topic after you reply.

NeatWolf escribió

ToddRivers escribió

the latest shaders only support Unity 5.6 unfortunately. I don't have time to backwards support old version of Unity

Ouch :-/
Are the official shaders going to be at least 3 months backwards compatible?

Don't know if anyone realizes this, but this is probably the most popular thread on Spine's Unity forum. Almost reaching 24,000 views at this point. It's even more read than Pharan's official post http://esotericsoftware.com/forum/Noteworthy-Spine-Unity-Topics-5924

It'd be nice if the Spine guys could pick up the torch and continue to iterate \ support Sprite Shaders or just contract out the support work (both legacy and current Unity versions) to ToddRivers?

His shader makes a significant impact to the visual quality of Spine's animations and helps keep it on par with Unity's Standard Shader. (Without it maybe Anima2D has a leg up?)

ToddRivers, your contribution to Spine's visuals is a huge one, hopefully you get the recognition you deserve. :rock:

With so many lurkers in this thread, it's a shame only a select few bother to get involved in the conversation. If you guys are using this tool and appreciate it, say something..

That being said, I'm more or less following alongside ToddRivers, I'm updated to 5.6 and the shaders are working beautifully. ToddRivers should we update to 5.6.1 now? :party: Haha

You have to admit the topic and content of the first post is pretty SEO optimized.
It literally says "Sprite Shaders for Unity". Imagine how many people google that.
I just googled it and it's the 4th result.
Which is apt, because it's actually not Spine-specific. He actually uses it for more than just his Spine stuff.

I don't call the shots regarding who contracts who. But absolutely, anyone who uses this should credit him with big bold text in their game. It should be the first logo when the game first boots up. 'cause he shares his Sprite shaders to the world freely.

The current spine-unity 3.5 unitypackage is actually packaged for Unity 5.4 and includes the shaders in a 5.4 compatible state, though it probably doesn't handle some of the gotchas like platform-specific depth or normal direction weirdness, if any of that exists.

How to get sharp shadow edges ( toon shading ) like in this video?

SOLVED:
Create a new texture with any resolution (power of two preferably), and paint the left half of the texture with a dark color, and the right half with white. Then place the texture in the Spine/Sprite/VertexLit material's Diffuse Ramp texture slot in Unity.

Yes, that's what Diffuse Ramp is for.

Thanks for sharing.

Is there any way to fix the problem that the light doesn't come from the same direction all the time?
It's as if the light moves with the object as the object rotates, and half way through the rotation the light flips to the other side. It looks really weird.

Image removed due to the lack of support for HTTPS. | Show Anyway

Is this a bug with the shader?

EDIT: Solved after many hours frustrating hours. Solve Tangents must be enabled under "Advanced" in SkeletonAnimation.cs.