Generating procedural mesh from buffer

Hello there,
I’m trying to get familiar with using shaders in gamma and I am still trying to port this GPU Superformula implementation, which also generates a mesh and calculates normals and tangents:

The ported version of the compute shader part seems to work (I’m only drawing the vertex positions at the moment), but now I’m trying to figure out how it would be possible to generate a mesh from the buffer with stride.

Would be really glad if somebody could point me in the right direction!

Superformula_CS.7z (14.1 KB)



what we did with early versions of beta was just using a grid and mapping the superformula positions onto it:

to approximate the tangents and normals, we calculated two more points in the x and y direction on the grid and took the cross product.

does anyone know where these shaders are? can’t find them in the contributions…

Blast from the past (5.3 KB)

superformula 2d (5.0 KB) (16.2 KB) (14.1 KB) (8.3 KB)

Looking through the archive there seem to be quite some gems that didn’t make the transition between websites. Might make sense to collect and “re-publish” them.


Awesome! Thank you for the shaders!
I’ll immediately take a look at them :)

So thank you for your help so far! Indeed managed to draw the mesh with my own pixel shader. Would love to dive deeper into how to use a geometry shader in stride’s shader pipeline to generate a mesh and apply strides pbr material to it. Couldn’t really find much useful information in the Stride documentation. Would really appreciate any link to documentation about this or any example patches

this question is very similar to this: Using Vertex Shaders in Materials

and I am working on an example that demonstrates how to set this up properly but it got delayed by more important bugs that need fixing. i think it will be ready by the end of the week ahead.

however, if you are really brave, download the latest preview, it has a WIP state of the example in it. it even works, but it is still experimental and needs improving. so don’t tell anyone yet…


That’s really awesome. I’ll keep quiet !

Coming back to this topic:
I have a working geometry shader, which is drawing a mesh and everything works fine in my drawing shader, now I wanted to try and integrate the whole thing in @tonfilm 's “Geometry Shader with PBR” example in the newest preview. But I’m not really sure where to put the Vertex and Geometry Shader in this example if I don’t want to draw particles, but a mesh. Can I mainly replace most of, what is going on in the “MyParticleProvider” with my own Vertex and Geometry Shader? And do I need to know what the “MaterialExtensionsName” in the NullMesh does in the pipeline? Thanks a lot for your help :)

it isn’t quite there yet, but here is a quick overview of the architecture, as it is now. this might change a little before we announce it officially.

in the example, there are three shaders that customize the material and each one has a certain responsibility. all three can be renamed as you want can contain anything that makes sense to the specific application. i’ll briefly explain what they do in this example:

  • SphereImpostorMaterialExtension.sdsl - override/extend the final material shader
  • MyParticleProvider_ShaderFX.sdsl - node in the patch, data input
  • ParticleProvider.sdsl - an interface/convention to pass data from ShaderFX node to the material extension

the ParticleProvider.sdsl serves as an interface, or “data channel” between the material extension and the ShaderFX node in the patch.

what it does in the example:

  • define vertex id stream variables
  • define a method to get the world position
  • define a method to get the particle size

the SphereImpostorMaterialExtension.sdsl will get “mixed” into the material. which means that the compiler will “apply” this shader on top of the material shader. in this shader, you can overwrite/extend the main shader stages (VS, HS, GS, PS). you set the name of this file as the “Material Extension Name” on the mesh parameters. can be any mesh, they all have a parameter collection.

what it does in the example:

  • the transformation in the vertex shader gets almost completely removed
  • a geometry shader stage is added
  • the Shading method is overwritten to set some variables (normals, etc.) before the PBR shading gets computed
  • calls methods of a ParticleProvider in the geometry shader

MyParticleProvider_ShaderFX.sdsl it is a ComputeFloat to be able to connect it to a material input. it also implements the ParticleProvider, so the SphereImpostorMaterialExtension can call the methods to get the data from it. you can have different ones of these nodes and each one is free to choose how they provide the data.

what it does in the example:

  • pass through the metalness value
  • define input for particle size
  • define input for the buffer that contains the particle data
  • returns particle data from the buffer as world position
  • returns the particle size

this shader threefold might appear slightly overdone when you just want to add a geometry shader, but it separates the responsibilities nicely and you have a lot of flexibility. but we’ll also add a simpler example when we have polished this one.

hope that gives you the knowledge to dig around and customize it to your needs. @catweasel might also be interested in this.


what also helps with the original question, are new secret unofficial nodes in the preview of today that allow you to create buffers and textures down to the graphics API level.

here a config that allows to read/write into a buffer in a compute shader as RWBuffer<float4> and bind the buffer as vertex buffer of a dynamic mesh and draw it like any other mesh:

1 Like

Thanks for the detailed explanation @tonfilm ! Extremely helpful as always :)
I will have a look and try to tinker with it. And post something here if I’m successful.

Another follow-up question from my side:
Is there a best-practice to debug shaders, which have no representation as a node in vvvv, like the ParticleProvider and the SphereImpostorMaterialExtension in this example? Is there a way I can check for compiler errors of these shaders? Or would some other Stride node throw compiler errors at me if there are any errors in the complete pipeline?

yes, with the EditShaders solution for visual studio with the stride plugin installed. the stride plugin will analyze the shaders and give you error messages.

there is an explanation in the “Write a Shader” help patch.

Ah didn’t know about that! That sounds really helpful. There seems to be an issue with installing the VS plugin for Stride on my machine at the moment, but I’ll see if I can sort it out.

Do you have an error message? Which version of visual studio do you use? Also, i think it needs Stride 1401 installed to find the nuget packages where the shader analyzer is stored.

No I don’t have an error message. If I click Visual Studio plugin “Stride: Install” in the v5.0.4 launcher nothing happens. I have Stride installed and Visual Studio Community 2019. Is there a place where I would usually find the Plugin if it is already installed?

Apart from my Stride Plugin issue I’m at least getting somewhere with this. Still got some issues.

If I try to override VSMain in the SphereImpostorMaterialExtension.sdsl vvvv instantly crashes. Even if I do not really override anything in the VSMain stage, but just call it. So at the moment I’m just overriding VertexPositionsin the PreTransformPosition and PostTransformPosition similar to the help patch and do the rest in the geometry shader. So my question would be if it’s generally not the idea to override the whole VertexShader in this place? And if yes what would be the single stages where I could override UVs, Normals and Tangents in the VertexShader without overriding the whole VSMain?

My second problem at the moment could also result from something that is still off in my shader, but I wonder if there is an obvious reason for this problem. My mesh is at the moment only lighted by the SkyboxLight, all other lights do not have an effect on the geometry. However, shadows are there for all lights.

1 Like

For your 2nd problem, I’d guess the normals calculation might be wrong, the skybox seems to give more of an ambient light than skyboxm and the lights need the normals to create highlights. Just a thought.

Thanks @catweasel. There was a problem with the normals indeed. I’ve overridden only the meshNormal in the version above. If I’m overriding meshNormalWS and normalWS with my calculated normals in World Space, the SkyboxLight looks right. All other lights still do not have an effect on the mesh though.

1 Like