Header Generation - tiagodinis/GParticles GitHub Wiki

With the loading of a project, GParticles generates automatically all the required event headers, the glsl portions of code that declare the available inputs and variables on the shader. This process is based on the resource and collider configurations indicated on the xml files. Below is showcased an example of the generation of an update event header:

Example file: "puddle.xml"

<project>
	<resources>
		<instance>
			<buffer name="positions" elements=512 type="vec4" />
				...

			<atomic name="aliveParticles" />
				...

			<uniform name="maxParticles" type="float" value=10 />
				...
		</instance>
	</resources>

	<psystem name="puddle">
			...

		<colliders>
			<static type="sphere" x=15 y=0 z=-3 r=5 />
			<static type="sphere" x=0 y=-2 z=-3 r=1 />
			<static type="sphere" x=-3 y=-2 z=0 r=1 />
			<static type="plane" x=0 y=1 z=0 d=3 />
		</colliders>

			...
	</psystem>
</project>

Example file: final puddle update event shader, found inside "/App/dumps" as "puddle_update_compute.glsl"

	...

////////////////////////////////////////////////////////////////////////////////
// RESOURCES
////////////////////////////////////////////////////////////////////////////////

layout(binding = 0, offset = 0) uniform atomic_uint puddle_aliveParticles;
	...

layout(std430, binding = 9) buffer Puddle_positions
{
	vec4 puddle_positions[];
};
	...

uniform mat4 model, view, projection;
uniform float puddle_maxParticles;
	...


const uint MAX_SPHERES = 3;
const vec4 spheres[MAX_SPHERES] =
{
	vec4(15.000000, 0.000000, -3.000000, 5.000000),
	vec4(0.000000, -2.000000, -3.000000, 1.000000),
	vec4(-3.000000, -2.000000, 0.000000, 1.000000)
};

const uint MAX_PLANES = 1;
const vec4 planes[MAX_PLANES] =
{
	vec4(0.000000, 1.000000, 0.000000, 3.000000)
};

	...

On the above example we can notice the presence of three uniforms that were not declared on the xml file: the model, view and projection matrix. The model matrix is constructed from the properties, rotation and scale tags located inside properties. The view matrix is provided from the application side to the processParticles function, while the projection matrix is instantiated every iteration based on the window dimensions stored on the GPDATA singleton. These last two processes are demonstrated in Tutorial 1.

This is the extent of header generation on the emission and update events. The render event, however, has one more quirk, since it is composed by at least two shaders and data can only be fed directly into the vertex shader, needing to be passed along manually if another shader further down the pipeline requires it. GParticles uses the convention of appending an identification character at the end of the resource name, as a way to indicate from where it comes from. The next example should be sufficient to understand how we can reference a resource, that we'll imagine is named "res", depending on the type of shader we are working with:

That's it. If you are having trouble understanding the header generation process, you can try running one of the GParticles example projects, such as "virusPuddles.xml", and checking the final generated file, found inside the "/dumps" folder. This can also be very useful when we are unsure about what resources might be available for the function we defined, or simply when having trouble debugging a certain event.