pixelmeat

  • 5 дней назад
  • Регистрация: 11 ноя 2015

    Perfect! Thanks guys.

    • Изменено

    Thanks @Harald. Yes I mean an animation with a single key on the first frame. I'll give a go to the animation.Duration == 0.
    Also, what does @Nate mean when he says:

    Nate Apply the animation

    ?

    Thanks Nate! I didn't know clipping attachments were so demanding.

    I'm using 1 frame animations to set some objects to static states like the open or closed state of a door when it's not opening or closing.
    What would be the best way to detect a 1 frame animation in code? If I have diferent enemies using the same behaviors I'd like to be able to detect if any of them has a 1 frame "idle" to apply the method you mentioned and loop the rest of the "idles", for example.

    Hey,
    We recently discovered a noticeable performance load when we added a ground cracked tile made in spine to our project.
    There can be up to 100 of these tiles on screen at the same time.
    I started fiddling with the animations and ended up fixing a couple of things that improved performance.

    1. The skeleton uses a cutout mask, so I disabled the mask at the start of the animations in which it is no used.
    2. The skeleton has a couple 1 frame animations that are played in loop. These 2 animations are used for 99% of the time that the tile is on screen. I figured maybe 1 frame animations looping are not so performant because some management must be done when starting/ending a loop, so that would make this steps needed every frame. I just added a dummy key to make these 1 frame animations into 20 frame animations instead.

    Number 1 improved performance pretty noticeably. Number 2 was almost not noticeble.

    I'd like to know if what I did makes sense and is something I should replicate for the rest of my skeletons and if there is an obvious improvement I'm missing for 1 frame animations. Maybe using FixedTimestepUpdates?

    We are already using the UpdateWhenVisible property and it also seems to help.

    Thanks for your time.

    Misaki Nice. I'm glad I could help spotting it. Spine is awesome 😎

    Cheers!

    Nate I just emailed it.

    • Misaki ответили на это сообщение.

      Just to add to what the AI is saying, I already set the mix to 0 as my first attempt to solve the issue, so that should not be the problem, I guess.

      Hey,
      I've encountered this behaviour when previewing a simple animation I'm working on.
      This trapdoor just moves to the right (x) and has a bit of anticipation via animation curve, like this:

      The weird behaviour is that when I preview the animation, this little anticipation only appears when I play it looped AND only from the second loop forward. See the video:

      It's not really a big issue, but I just wanted to share it in case I'm doing something wrong or this happens to be a bug.

      Cheers!

      Hey,
      I was talking to my programmer partner about how nice it would be not having to rely on diferent animation systems in our project, and we were wondering if it would be viable to use Spine for everything.
      All the game characters will be animated using Spine, but there are some minor things that should be animated (sometimes using traditional animation), like projectiles, and I'd like to know if it would make sense to create a skeleton with just the root bone and a sequence attachment to create such animated objects.
      The game is not going to feature massive amounts of enemies/npcs/projectiles on screen. Think of something in the lines of classic zelda games. 4 - 5 enemies at most at the same time and maybe a boss spawning a barrage of 10 - 20 projectiles.
      Do you think this could be handled using only Spine skeletons?
      Oh, btw, the game will be on PC, Xbox, PS and NS.

      Thanks in advance for your insights!

      Harald
      It worked!

      Thank you so much. I'll try to make a showcase post down the road when we implement the final production effect.
      Cheers @Harald!

      Harald
      I tried what you proposed. If I'm understanding correctly, by changing #pragma fragment frag to #pragma fragment constantColorFrag I'm telling the shader to use this new method to paint the image instead of the frag method found in ../../Include/Spine-Skeleton-ForwardPass-URP.hlsl, right?
      Just to clarify, I understand that I am not supposed to make any changes to the Spine-Skeleton-ForwardPass-URP.hlsl file.
      So, my new shader now looks like this:

      Shader "Universal Render Pipeline/2D/Spine/Blend Modes/Skeleton Constant" {
      	Properties {
      		_Color ("Tint Color", Color) = (1,1,1,1)
      		[NoScaleOffset] _MainTex ("MainTex", 2D) = "black" {}
      		[Toggle(_STRAIGHT_ALPHA_INPUT)] _StraightAlphaInput("Straight Alpha Texture", Int) = 0
      		_Cutoff ("Shadow alpha cutoff", Range(0,1)) = 0.1
      		[MaterialToggle(_TINT_BLACK_ON)]  _TintBlack("Tint Black", Float) = 0
      		_Black("    Dark Color", Color) = (0,0,0,0)
      		[HideInInspector] _StencilRef("Stencil Reference", Float) = 1.0
      		[Enum(UnityEngine.Rendering.CompareFunction)] _StencilComp("Stencil Comparison", Float) = 8 // Set to Always as default
      	}
      
      	SubShader {
      		Tags { "RenderPipeline" = "UniversalPipeline" "Queue"="Transparent" "IgnoreProjector"="True" "RenderType"="Transparent" }
      		LOD 100
      
      		Fog { Mode Off }
      		Cull Off
      		ZWrite Off
      		Blend One OneMinusSrcColor
      		Lighting Off
      
      		Stencil {
      			Ref[_StencilRef]
      			Comp[_StencilComp]
      			Pass Keep
      		}
      
      		Pass {
      			Tags { "LightMode" = "Universal2D" }
      
      			HLSLPROGRAM
      			// Required to compile gles 2.0 with standard srp library
      			#pragma prefer_hlslcc gles
      			#pragma exclude_renderers d3d11_9x
      
      			// -------------------------------------
      			// Unity defined keywords
      			#pragma multi_compile_fog
      
      			//--------------------------------------
      			// GPU Instancing
      			#pragma multi_compile_instancing
      
      			//--------------------------------------
      			// Spine related keywords
      			#pragma shader_feature _ _STRAIGHT_ALPHA_INPUT
      			#pragma shader_feature _TINT_BLACK_ON
      			#pragma vertex vert
      			#pragma fragment constantColorFrag
      
      			#undef LIGHTMAP_ON
      
      			#define USE_URP
      			#define fixed4 half4
      			#define fixed3 half3
      			#define fixed half
      			#define APPLY_MATERIAL_TINT_COLOR
      			#include "../../Include/Spine-Input-URP.hlsl"
      			#include "../../Include/Spine-Skeleton-ForwardPass-URP.hlsl"
      			
      			half4 constantColorFrag(VertexOutput i) : SV_Target 
      			{
      				float4 texColor = tex2D(_MainTex, i.uv0);
      				#if defined(_ZWRITE)
      				clip(texColor.a * i.color.a - _Cutoff);
      				#endif
      				return float4(i.color.rgb, texColor.a * i.color.a);
      			}
      
      			ENDHLSL
      		}
      	}
      }

      With this new shader, I'm getting these results:

      The color is still performing some kind of additive effect and the clipping is not taking the alpha into account.

      This is the current shader inspector config:

      • Harald ответили на это сообщение.

        Harald What do you mean by the last half of the sentence "just changed the color value of the texture to the same input color"? Do you want to output just the tint color in additive blend mode?

        I'd like the shader to output a single color from an input, without any blending, just the input color and the alpha from the character texture. And the shader should have the stencil interaction property.

        I'll try to implement your suggestion and see how far my skills get me 🙂

        • Harald ответили на это сообщение.

          Harald That's great! TY

          I have a follow up question too. Would it be possible to have a simpler version of this shader that, instead of modifying the texture color via a screen blending effect and an input color, just changed the color value of the texture to the same input color? I'm not a coder, just a tinkerer, and almost had a heart attack when I opened the shader file in Visual Studio :_(

          Any ideas on that? What I have in mind is a simple shader that paints the character in a constant color and has the stencil interaction property.

          • Harald ответили на это сообщение.

            Harald

            Oh, I think I found it! Is this the property?

            I was only looking under the "valid keywords" and "invalid keywords" not under "saved properties", my bad. Too many new things ^^
            I see that the value is set to 4 which is exactly what I needed for the effect, although I don't know why is it set to this value or even if it was me who set it accidentally. Could I change this value somehow if I needed it?

            I have a follow up question too. Would it be possible to have a simpler version of this shader that, instead of modifying the texture color via a screen blending effect and an input color, just changed the color value of the texture to the same input color? I'm not a coder, just a tinkerer, and almost had a heart attack when I opened the shader file in Visual Studio :_(

            Anyway, thanks again for your help and your compliments Harald. The game is still in pre-production and I'm the game designer, so I'm exploring the possibilities of what we can do and what we can't. I'll make sure to keep posting some showcase bits, as the Spine community is always so kind and appreciative of the works of others.

            • Harald ответили на это сообщение.

              OK! Now I have something really similar to what I was trying to do. The problem is... I don't know why it's working! hahaha
              Here's the effect in action:

              The thing I'm not getting is why the shader that I use for the "silhouette" is working correctly inside the masks.
              These are the shader settings:

              There's no info there about Stencil Comparison, not even if I look in debug mode. So I don't know how is it working correctly with the Sprite Mask.
              Here's the rest of the components I'm using to create the silhouette, based on the same components used in the outline method:

              And that would be all for now, just looking for some enlightenment about why this is working before I happily move on 😃
              Thanks!

              • Harald ответили на это сообщение.

                I can't delete my last post, so please ignore it. My mask was not in the wrong place. The setup is working as intended.

                I have encountered a new problem now. My prototype is using custom axis sorting, so the scene sprites sort themselves using the Y axis instead of Z. All the characters and ground obstacles are in a sorting layer called onGround, more specifically in position 0 inside that sorting layer.
                Now that the outline object is working, I need it to render in position 1, inside the onGround layer, so the "see through" silhouette will be visible when the character is behind an obstacle.
                I've tried using the SortingGroup component, as I think this has worked for me in the past. Is that the right way to force a mesh to sort using the sprite sorting system? It is not working for me right now.

                What do you think I am doing wrong?
                Thanks!!

                Harald That's exactly what I meant, thanks!

                Harald
                I see this setup in the example scene:

                How can I make the outline object be mask-interactive?

                • Harald ответили на это сообщение.

                  Harald
                  Wow, I really didn't see that coming, the shaders were not working because I had reverted to the 2D renderer and I was still trying to use the 3D shaders. Changed to the 2D ones and it displays right now. I'll continue from here.
                  Just one more question for now. Are there versions of the outline shaders for the URP/2D category?
                  I mean like this one:

                  • Harald ответили на это сообщение.