2D Rendering Techniques - Fragment Rendering

[cyuria]

This issue is a place to list/discuss ideas for rendering for the backend wayland client.

I would like to propose an idea of "fragment rendering". This idea is composed of two interchangeable functions:

1. Fragment Generator
2. Fragment Shader

Note that both of these functions should take some kind of "uniform" value (defined similarly to uniforms in 3D graphics libraries such as openGL).

This would provide a very basic framework for also implementing software rendered 3D scenes. To use traditional techniques, this would require the user to implement their own vertex shading and triangle rasterising

Fragment Generator

This is a function which generates a list of pixels which should be rendered. The simplest example of this is a box. What it does is simply iterates over every pixel within the given dimensions and returns each of them. This could be implemented as a co-routine, or it could call a given fragment shader directly. The shader would be passed as a function pointer.

Fragment Shader

A function which, given a pixel coordinate will determine which colour it should have. This can be transparent to be the equivalent of the GLSL "discard".

Question: What if you want to fill an area with transparency? Solution: Have different alpha blend modes.

Other Stuff

Pre-implemented functions

There should also be a number of pre-implemented drawing functions which utilise these two as a kind of "backend". Examples would include functions for drawing rectangles, ellipses, arcs, triangles, polygons and a number of other basic shapes.

Anti-aliasing

Possibly have generators return a special "edge pixel" value. This would pass a flag to the fragment shader to tell it to render an "edge pixel".

We could have the generator return an extra "alpha" value for anti-aliasing. This would have its own dedicated blending.

Uniforms

It is not yet clear how to implement passing uniforms to a generator and shader.

Possible Options:

• A void * to a user defined struct
• A map of some kind
• Some kind of interfaces code? (if and when zig adds interfaces)
  • Just pass a get([]u8) function pointer or something instead of an interface
• Something else?

Ideally it would be as transparent as possible and not require much if any prior setup from the caller (i.e. minimal setting up of uniform variables).

[cyuria]

Could the fragment generator be an iterator?

[cyuria]

uniforms could maybe just be a comptime known struct with some anytype stuff in the library wrapper function

[cyuria]

Should I use floats or integers for the drawing API?

I'm leaning toward ints, however there is an argument to be made for floats.

Argument for float

• More familiar interface for people with 3D rendering experience.
• More resolution agnostic.

Argument for int

• The most "native" pixel format for CPU rendering.
• If you need floats, you're going to have to convert somewhere anyway. On the other hand if you want integers, you can do it without conversion.
• Integers are more common (?) in 2D rendering techniques (using pygame as an example).
• Reduces the complexity of the fragment rendering glue code.

[cyuria]

Users can also always write their own versions of the rendering functions which use floats instead of ints.

[cyuria]

Create generic "fragment" struct. This will contain data like pixel position, uv coords, and any other possible data.

For example:

const Fragment = struct {
    position: @Vector(2, u32),
    uv: @Vector(2, f32),
    staticdata: T, // uniforms for the fragment shader
};

[cyuria]

You can find out values such as the "angle" for circular generators by transforming the uv coordinates, where the centre is (0.5, 0.5). Any uniform values can be passed through the staticdata field (this should have a better name). Perhaps this could be combined with the options field somehow?