Hello Guest

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Orion

Pages: [1]
1
Support / Re: flip
« on: November 28, 2013, 06:59:04 pm »
You are right. It's worth a shot. Although my code for flipping just negates the z position, so calling it repeatedly will mess things up. But I'm sure I can create some sort of simple system that just keeps setting every transform to the correct z value.

2
Support / Unity sprites in 2D Toolkit
« on: November 28, 2013, 06:55:48 pm »
Are you planning to make it possible to use the Unity 4.3 sprites as a resource in 2D Toolkit?

I'm very fond of their atlasing and slicing (I could easily make it auto-slice sprites when a texture is updated - I couldn't figure that out in tk2d). But the 2D Toolkit pixel perfect rendering and some other things (flipping!) work much better than Unity's sprite renderer.

So I really wish I could just use the new sprites on a tk2d renderer. Any chance?

3
Support / Re: flip
« on: November 28, 2013, 06:45:18 pm »
I don't have a problem writing (complex) code, once I know a working solution. Right now I'm trying to find anything that will work without killing performance.

Basically what happens is this:

- Character turns around >> I flip z order of children (once)
- Character gets animated (by mecanim) >> the animation restores the pre-flip z order

Right now the only way to avoid that would be to reorder the sprites on LateUpdate, after the animation happened. But I can imagine reordering 1000s of sprites every frame is not going to be good for performance.

How would you solve this (with a manager or without)?

This seems like a common problem to me, when using animated characters that are built from sprites. How is this usually done?

4
Support / Re: flip
« on: November 27, 2013, 12:16:50 pm »
The problem isn't the scale key, but the position keys, when the sprites move. It keeps resetting the z position to "pre-flip".

5
Support / Re: flip
« on: November 27, 2013, 11:52:30 am »
Sorry for digging up an old topic, but I'm running into the same issue.

tommyv's solution seems good, but I'm using animations on my characters. The animations all store the z position of the sprites so if I flip and inverse the z positions in the hierarchy, the animations set it back.

Is there a way to prevent animations from setting the z position? Setting the position on the sprites every frame to order them seems awfully expensive (I have about 100 active characters at once, built from 16 sprites each). Or maybe some other way? :-[ I've been puzzling with this for a long time and everything I try fails for another reason.

6
Support / Re: Best practises for combining sprites
« on: February 18, 2013, 05:46:36 pm »
It took me all day, but I finally managed to convert the surface shader to a fragment shader that does exactly the same as before. The drawcalls do indeed batch now, so that's really great. Thanks a lot for the help!

7
Support / Re: Best practises for combining sprites
« on: February 17, 2013, 11:17:43 pm »
Okay, I tried implementing that, but realized that I'm at a complete loss on how to remove the lighting.
I just recently figured out how surface shaders work, after experimenting a lot with strumpy's shader editor and reading all the confusing material on the net.

I realize I could probably write my current surface shader as a fragment shader, but I can't get my head around how, and if it will have any benefit at all. The shader is currently combining the light from the scene, with a special screen overlay light texture (that is larger than the screen, to avoid certain artifacts). It also uses a "Specularity" texture, that affects how much of the light texture it picks up.

Code: [Select]
Shader "MapLitAlpha"
{
Properties
{
_Color("Main Color", Color) = (1,1,1,1)
_MainTex("Base (RGB) Tranparency (A)", 2D) = "gray" {}
_Specularity("Specularity (RGB) Emission (A)", 2D) = "gray" {}
_Light("Lighting (RGB)", 2D) = "gray" {}
_Cutoff("Alpha cutoff", Float) = 0.5
_LightColor("Fake Lighting", Color) = (0.5,0.5,0.5,0.5)
}

SubShader
{
Tags
{
"Queue"="Transparent"
"IgnoreProjector"="True"
"RenderType"="TransparentCutout"
}


Cull Back
ZWrite On
ZTest LEqual
ColorMask RGBA
Fog{Mode Off}


CGPROGRAM
#pragma surface surf SimpleLambert  nolightmap noforwardadd approxview halfasview alpha decal:blend vertex:vert
//#pragma target 2.0

// Warning: Modified: don't use Strumpy anymore!

float4 _Color;
sampler2D _MainTex;
sampler2D _Specularity;
sampler2D _Light;
float _Cutoff;

struct EditorSurfaceOutput {
half3 Albedo;
half3 Normal;
half3 Emission;
half Specular;
half Alpha;
//half3 Gloss;
//half4 Custom;
};

half4 LightingSimpleLambert (EditorSurfaceOutput s, half3 lightDir, half atten) {
half NdotL = dot (s.Normal, lightDir);
half4 c;
c.rgb = s.Albedo * _LightColor0.rgb * (NdotL * atten * 2);
c.a = s.Alpha;
return c;
}

struct Input {
float2 uv_MainTex;
float2 uv_Specularity;
float4 screenPos;
float depth;
};

void vert (inout appdata_full v, out Input o)
{
v.tangent = float4(1,0,0,0);
// Front is darker than back
float depthFactor = 0.4 - ( _WorldSpaceCameraPos.z - mul(_Object2World, v.vertex).z )*0.2;
o.depth = depthFactor;
// Init to fix dx11 errors
o.screenPos = float4(0,0,0,0);
o.uv_Specularity = float2(0,0);
o.uv_MainTex = float2(0,0);
}

void surf (Input IN, inout EditorSurfaceOutput o)
{
float4 Tex2D0 = tex2D(_MainTex,(IN.uv_MainTex.xyxy).xy);
float4 Albedo = Tex2D0 * _Color;
float4 Tex2D2 = tex2D(_Specularity,(IN.uv_Specularity.xyxy).xy);
// Calculate sizes and margin
float2 Size = float2(2048, 2048);
float2 Margin = (Size - _ScreenParams.xy)*0.5;
Margin /= Size;
// Map back to texture
float2 SamplePos = lerp(Margin, 1-Margin, IN.screenPos.xy);
float4 Tex2D1 = tex2D(_Light,SamplePos);
float4 Emission = Tex2D1 * 8;
Emission *= Tex2D2.a;
Emission *= Albedo;
o.Albedo = Albedo;
o.Emission = IN.depth*Emission;
o.Normal = float3(0.0,0.0,1.0);
o.Alpha = Tex2D0.a;
}
ENDCG
}
Fallback "Transparent/Cutout/Diffuse"
}

On another note -
I've put all characters into the same collection now, but it doesn't seem to make any difference for the draw calls. It still adds 11 draw calls per character, and also 11 "saved by batching". I don't use atlas spanning.

Maybe I'm doing something wrong with the shader, but if I switch between my shader and the tk2d CutoutVertexColor (and have my whole screen filled with characters = ~5000 draw calls), I only get a difference of 2 draw calls for the entire scene, and the difference in performance in the profiler is immeasurably small, so I don't think it really matters, or is the bottle neck here.
If I switch to BlendVertexColor, the DrawCalls go down to almost nothing (lets say 1 or 2 draw calls for everything). But I have the impression that the order of the sprites is then not guaranteed. Do you have more suggestions, how I could lessen the decrease of performance?

8
Support / Re: Best practises for combining sprites
« on: February 16, 2013, 04:56:15 pm »
Ah, nice! I didn't know that!

9
Support / Re: Best practises for combining sprites
« on: February 16, 2013, 03:00:31 pm »
Okay, next chance I'll check if putting all three characters in the same collection will help.

The light issue is interesting, though. I animate the color of the light and would like the characters to match the surroundings. If I change global ambient lighting, it will cause the surrounding models to be lit wrong. Should I write an extra shader just for having no light on the characters? I do already use a custom shader for transparent stuff.

10
Support / Re: Best practises for combining sprites
« on: February 16, 2013, 10:15:26 am »
Actually, for testing, I have one collection per character and three characters close to each other. I was planning to use one collection per bodypart, since they would be interchangeable - but from the sound of it, this may not be such a good idea. The z is different per character and body part . I have one directional light and the camera uses an orthographic-like custom camera.

11
Support / Re: Best practises for combining sprites
« on: February 15, 2013, 05:46:24 pm »
That is odd. Scales are 1,1,1 everywhere, except of "Target Ortho Size" of the collection, where everything is scaled up to match the camera. Z positions of the parts are not identical though, to render them in the correct order.

I do use a custom surface shader to render them. Although if I use one of the shaders that comes with tk2d, it doesn't seem to make a difference. What else could cause the batching to break?

Also, if it says "Draw Calls: 168   Saved by batching: 103", does that mean, there are actually only 65 drawcalls, or that there would be 271, if batching didn't work?

12
Support / Best practises for combining sprites
« on: February 15, 2013, 03:39:01 pm »
Hello everyone,

in my game I animate the characters by stacking multiple sprites on top of each other, that are then animated together. They share the same sprite collection, but unfortunately, each part seems to cause one draw call. So at the current point every single character is 11 draw calls.
Now I actually want to add more parts to the characters, although this time, parts that stick with others (e.g. gun attachments, stuff attached to the head, etc.). At this point already, with 50 characters on screen, I experience heavy performance drops (not surprisingly).

What would be the best practise to do this, while keeping the draw calls low? How would you tackle this?

Pages: [1]