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: https://github.com/ondeowl/SuperFormula3D-Unity
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!
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
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.
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?
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 18.104.22.1681 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.
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.