MaterialExtensionTessellation

[kopffarben]

Add a MaterialExtensionTessellation Node to use ShaderFX inside the domain stage.
Example provided. see help/Tessellation/HowTo Beziert.vl

known issues:

1. Need to set streams going to domain stage by hand ... see MaterialExtensionTessellation-Node not a big issue, but i think this can be handled automatically
2. ShaderFX Nodes behave confused Create 2 input pins for each input in the shader, one named nicely, that behave confused, one other named by shadername + property name ... this works correctly not a big issue ... because i just use the second inputs
3. Displacement not working on extended Materials, it just didn't compile correctly, so nothing to see I think some stage/streams are not set up correctly ... but i didn't dive in this deep

[azeno]

Looks good to me, few little things though:

• Please remove the EditShaders.sln
• Reference the csproj in the help patch directly and remove the *.dll - it is good to know for the end-user how to define a custom struct for the shader
• The help patch is called "Beziert" - maybe call it how to extend a material with tesselation? The question here is about the new tessellation extension and not about b-splines, right? You can add a tag "bezier" to the help browser instead.

[gregsn]

The patch works nice though:

• wouldn't go fullscreen for a help patch. reset bounds pin
• am I the only one here? I am getting runtime excpetions when hovering pins:
  
  when hovering the MaterialExtension output:
  mesh or material typed pins this might not be your fault, but it's bad. So we should either discuss a viewer for the particular type, that doesn't try to draw the material, thus doesn't crash or maybe there is a way to fix the issue

it's a bummer that we don't have a help patch for the other material extension node. It's quite tricky... @tebjan do you have an opinion regarding how the nodes should be modularized?

[azeno]

I have no crashes like that on my machine.

[gregsn]

Was looking at it with @azeno.
We'd love to accept the pull request but hit too many questionmarks. Some of them for sure are not because of you, but because we are not that deep into the system right now.

• MaterialTessellation should that be called CustomTessellation? We figured that other "standard" tesselations can be connected also.
• Is there a reason for the material extension input, which tweaks the vertex color? It sounds like not related to tesselation.
• Is this a combination of features that always comes as a pair? Tessellation and Vertex Color tweaking? If not, should they end up on different nodes for modularity reasons?
• Why do we use material extensions instead of building the material from scratch? It feels quite like a hack. Also because the material specification now operates on another level when compared to the original material node.

Hopefully we can shed some light on the topic and only tweak some little bits.

[kopffarben]

The different of the both nodes i provide is:

MaterialTessellation

• you connect directly to the Material
• you can write your own Tessellation for this material
• works on stride side internally the same as the MaterialExtensionTessellation

MaterialExtensionTessellation

• you can extend a Material with an Tesselation Shader, some how inject the TesselationShader
• that approach allow me and others to write somthing like BezierSplineTubeEntity where the user can connect his own Material
• the fuse Sphereimposter use the same approach

i like the idear to rename the MaterialTessellation node to CustomTessellation, this is more clear i think

so next question why there is this extra MaterialExtension pin on MaterialExtensionTessellation node

• at the end this is a copy of the code from the original MaterialExtension and it is needed in one node if you whant stream (pass) somthing to an other stage than Domain
  • the porblem is that the MaterialExtension node dont work after the MaterialExtensionTessellation node
• but if i think about maybe it is the best idea to add the Tessellation feaure to the existing MaterialExtension node
• than we has one Materialextension node with all features

so whats yor opinion, tomorrow i will has time to push all the changes

next question ... should i provide a more simple sample than the bezierTube with own geometry own struct ...

• somthing like Sphere Tesselation ... with simple inputs positionBuffer sizebuffer
• maybe i sould bring the BezierTubeSegment and some more what i want write in the future (BezierTubeSpline ...) to a seperate nuget

summary:

• rename MaterialTessellation node to CustomTessellation
• add TesselationFeature to existing Materialextension node
• more simple basic sample

[gregsn]

all of what you propose sounds good to me.

[tebjan]

@kopffarben first I want to award you with the medal for (probably) being the first dev who has developed a custom material feature in the way that the Stride architecture wants you to do it :). 🥇

I also think that both workflows are valid and your renaming suggestion makes sense. And yes, it was also my first thought, if the existing MaterialExtension node is able to manage everything in one node without breaking existing patches, that would be best.

[kopffarben]

THX TATA ... beeing a c# coder helps

all Changes are now pushed ... now

rename MaterialTessellation node to CustomTessellation

• add TesselationFeature to existing Materialextension node
• more simple basic sample
  • tessellate a HalfSphere facing to Camera out of

      float3 SpherePos  : SPHEREPOS
      float3 SphereSize : SPHERESIZE

• so no need for csproj
• and much more clear simple Example to understand

[kopffarben]

By the way, this problem

ShaderFX Nodes behave confused Create 2 input pins for each input in the shader, one named nicely, that behave confused, one other named by shadername + property name ... this works correctly not a big issue ... because i just use the second inputs

are still there ... ShaderFX behave a little bit confused if it found stage inputs in the DSMain, HSMain ...

And if sombody looks to this, maybe we can get rid of the TessellationStream pin.

• maybe the shaderCompiler knows some how witch streams a there?

[tebjan]

2. ShaderFX Nodes behave confused Create 2 input pins for each input in the shader, one named nicely, that behave confused, one other named by shadername + property name ... this works correctly not a big issue ... because i just use the second inputs

This is indeed a weird issue, it looks like the shader reflection returns two pins and we don't sift them out. needs further investigation.

made an issue here: vvvv/VL.StandardLibs#72