HLSL render 2D entities

[tough flare]

I was having a discussion a day ago with @analog perch, so I want to continue my dumb questions starting from this message #1064581837055348857 message if its possible 🙂

quote
In a 2D plane, quats are very simple: q.x = sin(theta/2) * axis.x q.y = sin(theta/2) * axis.y q.z = sin(theta/2) * axis.z q.w = cos(theta/2)
Depending on the flat plane you're using, it's only 2 values which should be non-zero, XYZ and W.
quote end

What is axis here?

I've read all your messages carefully and as far as I can understand: the main thing I need to return from vertex shader is SV_POSITION which is float4 (or half4) value. In vertex shader it stands for vertex clip space position and in fragment shader it stands for pixel location on screen.
If I right then can you explain why this is 4-sized component value? What w stands for?

Sorry if this thread irrelevant for dots forum.

[analog perch]

Axis is the plane that is not being used in the 2D space. For example, if you have your 2D plane set along the XY dimension (where Z is then not used), axis being a float3 would be (0, 0, 1) and in a quaternion, the value will be (0, 0, sin(theta/2), cos(theta/2).

[analog perch]

Clip space is a... interesting topic. It's difficult to understand and frankly I still have very little clue about what it is. What it's basically doing is determining if this vertex position is visible by the camera and if it isn't, it "clips" it. It requires 4 dimensional positions and the W is important in the math that is used.

Basically all that you need to know is that worldspace position should be appended with a 1, so float4(worldPos.xyz, 1), and then multiplied by UNITY_MATRIX_VP. That's the vertex shader's SV_POSITION. Something happens between vertex and frag so the SV_POSITION is different when set in the vertex shader and when read in the frag shader.

[tough flare]

@analog perch hello again after a long time. Sorry for necro but I feel power inside to finally implement performant 2D transforms in my project.

From your messages I can see that I can use OtW matrix constructed somwhere in ECS systems and then pass it to StructurredBuffer<float2x3> then use mul functions and obtain SV_POSITION as float4 which is a current vertex world position.

In this way (because we are in pure 2D world) we save 40 bytes per entity (16 floats vs 6). So I have 2 questions here:

• Does this optimization possible only for 2D space
• How can I implement 2D parent-child relationship (hierarchy) if I use 2x3 OtW matrix instead of default 4x4 LtW?

[finite ridge]

^Sorry to necro as well. But it seems like you might be interested in how to most efficiently render 2D sprites. The answer is to use a ComputeShader. Run a kernel for each sprite, and write to a RenderTexture directly (RWTexture2D). Only write to the pixels that you need.

At a core level the logic is: loop objects, loop pixels

Also if you don’t know how rasterization works in general, this article is great imo https://www.scratchapixel.com/lessons/3d-basic-rendering/rasterization-practical-implementation/overview-rasterization-algorithm.html