thefuselab / vl.fuse Goto Github PK

• Rendering 3D SDF (using site’s Feature image source patch)
• VolumeSDF help patch
• Use Domain Repetition on SDF

Example use case would be rendering a single channel control map or a 2D vector texture.

Implement node factories to create nodes easily from sdsl files for example for sdfs or intrinsic functions.

Atm this has to be done with a little indirection and a static file, would be much nicer to have it patchable

The current c# project should be cleaned and work with nugets, but also allow to work within rider and to test code.

Had this a lot in quite complicated patches already, but made a simple demo here bd64116

https://github.com/blender/blender/blob/594f47ecd2d5367ca936cf6fc6ec8168c2b360d0/source/blender/blenkernel/intern/particle_system.c implementation is in line 1403

• Gamma version : 2021.4.0-0320
• Fuse version : current main, 54bbaf1

When setting a negative value on MandelbulbSDF's iteration pin, all monitors switch to black for two seconds, then come up again but tooltips are not updating anymore.

Repro steps :

• Create a MandelbulbSDF node and its tooltip
• Play with a few parameters except iterations, the tooltip reacts normally
• Now set the iteration pin to a negative value
• All monitors briefly turn black and then are up again
• Play with another pin such as position : the tooltip does not update anymore

Only way to fix is to restart vvvv

Proposal : the node should catch that and either do nothing or show a warning

• Gamma version : 2021.4 526
• Fuse version : latest develop, ca8d150

Was trying to make a small HowTo for the VolumeSDF node, using the Stanford Dragon asset from FieldTrip. When using the Raymarch (Basic) node, the dragon renders fine, but using Raymarch (Material), it only shows a box.

After trying to use Raymarch (Material), gamma stays in Hot Swapping state forever (static red bar under the quad menu) and ends up being unresponsive.

I'd like to do a little renaming and consistency checking on the nodes in .Core & .Common.
This would be nice to do sooner rather then later so there are less patches and modules affected (broken).

An example would be changing noise and SDF nodes from using 'x' to Input(probably the way to go), Position or Domain (a lot of SDF nodes could have a position pin separate to their domain)

Another example would be a lot of the intrinsic function nodes could have more helpfully named parameters. While they do currently actually follow the referenced functions I think we can do better to make it easy for ppl not familiar with HLSL.

Take lerp node:
lerp(x, y, s)

could be
lerp(Input, Input2, Mix)

another example:
Current: Bias(x, Control)
-> Bias(Input, Control)

In both examples I'd propose to avoid x ,y etc as this is easily confused with components and swizzling.

For multiple inputs we currently have a mix of upper and lowercase (a, b), (x, y), (Input, Input2) & (Values, Values2)
I think the best would be to be consistent with VL style which is Input, Input2, InputN

The atomic nodes in Fuse.Core.Math seem to use values, values2, valuesN, this may or may not be worth changing to the VL convention...

Kind of seems like a PITA but there are both human and programmatic advantages to consistency.

So far we are using hash without sine which does not work to bad but seems to generate weird patterns on particle stuff
https://www.shadertoy.com/view/4djSRW

This one lists are wide variety of functions
https://www.shadertoy.com/view/XlGcRh

Lets discuss this

How to replicate the crash. : Make new vvvv patch, add fuse dependency, start scrolling list of examples from dependency menu. Crash

Crash Report. Screen shot of the window that cannot be copy/pasted and the text of the crash attached below.

20211125_Crash_report.txt

• Gamma version : 2021.4.0-0320
• Fuse version : current main, 54bbaf1

If I want to draw a BezierSDF where B's Y component is the negative of A's Y component, the function seems to go wrong, see the attached gif :

Fix CullRayByBoundingBox in Fuse.Raymarch

Should we just use the glsl style Mod which is propably what people expect any advantage on using fmod?

It looks like its stuck at constant strength and vector, probably all 1

video of issue:
https://imgur.com/a/juaxhHr

I think this can easily be fixed by putting resources like buffers or textures into rgroup PerMaterial and using the stage keyword:

rgroup PerMaterial
{
    stage Texture2D InputTexture;
}

for reference: VL.Stride.Runtime/src/Effects/ShaderFX/Texture/DeclTexture.sdsl

everyoneishappy:
Yes indeed that should work and does not. Actually anything texture sampling related seems to have trouble when fed into the material system via ToShaderFX. tebjan I think this is the same cause as the SDF volume not working correctly in the material system (and probably some other things like the VAT stuff)
is there some resource registration or manegment that needs to be taken care for on the VL side?
looking at the emitted sdsl in the log folder for this and also the shaderFX sample level, which does work
the actual sdsl lines to sample the texture seem the same in both, but I can see in the debug info on the ShderFX one it lists the resources for the texture and sampler as being bound. It does not list these in the Fuse based one. The variable declaration for texture and sampler looks the same though

When I try to open any of the fuse help or create any Fuse nodes, I get a compile error:
"The type or namespace 'T3' could not be found" in Fuse.Core.vl.cs(1330,61)"

I installed Fuse via Nuget (nuget install VL.Fuse -pre).

Are there some other dependencies that are needed?

See the end of this message for details on invoking 
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
VL.Lang.Platforms.Roslyn.EmitException: C:\Users\tekt\AppData\Local\vvvv\gamma\nugets\VL.Fuse.0.0.21\vl\Fuse.Core.vl.cs(1330,61): error CS0246: The type or namespace name 'T3' could not be found (are you missing a using directive or an assembly reference?)
   at VL.Lang.Platforms.Roslyn.TargetCompilation.<>c__DisplayClass64_0.<Emit>g__EmitRelease|1()
...
[fuse_error.txt](https://github.com/TheFuseLab/VL.Fuse/files/7150238/fuse_error.txt)

We need a good fallback option here https://github.com/TheFuseLab/VL.Fuse/blob/develop/src/Fuse/Monadic.cs#L30

Currently it throws an exception, some sort of warning would be better.

Example patch can be found at https://discourse.vvvv.org/t/some-nodes-hide-render-windows/19951/3 where a Spread<Vector2> gets connected to a GpuValue<Spread<Vector2>>

We are planning to rename some things. Is your repo up to date with all of your latest changes?

We could convert your patches as we do the renamings and make a pull request on this repo with the fixed patches.

See also: vvvv/VL.StandardLibs#238

https://www.shadertoy.com/view/XtKSWc

Hello, it was my first touch with the latest release 0.17
I was about to replicate the very first patch I watched in the recoreded workshop session (https://youtu.be/_NOZ3FLMD_I?t=516)

1. I firstly introduced the FBM node
2. then the Stride SceneWindow
3. The MeshRenderer
4. the RenderEntity
5. and lastly the DrawShaderGraph

as a result VL started spawning numerous rendering windows

This happens only if I create the SceneWindow before the DrawShaderGraph node.

From our talk in Skype here's the example C# project attached.

VL.CustomRegion.zip

• Check What is Fractal Brownian Motion
• Update FBM help patch with Kyle's info
• Domain displacement example
• Landscape
• Noise Reference ?

ToFloat > ToVector4 (AbstractGpuValue)
make more:
ToFloat (AbstractGpuValue)
ToVector2 (AbstractGpuValue)
ToVector3 (AbstractGpuValue)

CastFloat > To (GpuValue)
CastFloat2 > ToVector2 (GpuValue)
CastFloat3 > ToVector3 (GpuValue)
CastFloat4 > ToVector4 (GpuValue)
make:
ToFloat (GpuValue)

TypeFloat helper nodes.
rename to:

NO!!!!! it doesn't work!
you can name the node like that

but then it doesn't show up in the patch or in the node browser

Pins name.

• try to use Input and Output for the main input-output pins (where not specific)
• Capital letters

Pins order
use signature configuration thingy to sort pins order per operation

check category Capital Letters Everywhere

When uploading single CPU values and vectors atm we always need to create this middle node.

Not really super urgent, as it works quite ok. But I think it's ultimately extremely important from patching experience point of view to streamline this.

Perhaps we could come up with some ideas for how it should work, and then look at what's reasonable to implement and if the vvvv devs have some advice.

My initial thought (from user pov only) is that it would be quite nice to just be able to middle click from the GPU pins and choose your CPU iobox type directly (so the upload is encapsulated effectively) You could still choose create generic/GPU iobox if that's what you want.

We want to find a better way to handle delegates without strange templating syntax prefarebly by using mixins here is a proposal in shader code.

First write an abstract shader class that is used

shader AbstractColor
{
    
    abstract float4 colorValue();

    float4 computeColor(){
        return colorValue() / 4;
    }
};

Fuse will generate an internal shader with the implementation

shader ColorImplementation : AbstractColor
{
    
    float4 colorValue(){
        return float4(0.0,1.0,1.0,1.0);
    }
};

This will be placed into the final generated shader with composition

shader MyColor_DrawFX : VS_PS_Base
{
    

    [Color]
    float4 Color = float4(1, 0, 0, 1);

    ColorImplementation colorImp; 

    override stage void VSMain()
    {
        streams.ShadingPosition = mul(streams.Position, WorldViewProjection);
    }

    ColorImplementation colorImp; 

    override stage void PSMain() 
    {
        streams.Depth = 1;
        streams.ColorTarget = colorImp.computeColor();
    }
};

This could also be used to already define delegate functions in the mixin like this

shader AbstractColor
{
    
    abstract float4 colorValue();

    float4 colorRed(){
        return float4(1,0,0,1);
    }

    float4 colorBlue(){
        return float4(0,0,1,1);
    }

    float4 computeColor(){
        return colorValue() / 4;
    }
};

Fuse would use one of the provides functions

shader ColorImplementation : AbstractColor
{
    
    float4 colorValue(){
        return colorBlue();
    }
};

basically, every shader generation needs to have a context that carries the ID counter/generator. on every recompile the id counter can be created together with the compilation context. this will make sure that the shaders will always be the same at every start of vvvv.

this is how it is done for ShaderFX: vvvv/VL.Stride@a50ae1d#diff-91f406fa91afc39ec40496e370408932bc025abdbb4c3941be7f3a1d3e2f9a35R18

here are two screenshots from two starts of the same help patch:

There seems to be a bug looks like this return a wrong string some times so instead returning the string directly for now

see StructuredBuffer input patch

basically, every input value has to track compilations and generate a new input for every sink.

see this PR: vvvv/VL.Stride#451

• Explanation patch/overview, give high level explanation on the system
• One help patch for each component (ObstacleSDF, Texture2DVectorField + Volume2DGradientControl, SphericalImpulse)
• Rename Particles patch to Example
• Simulation textures help patch

Find a time slot to look at this together

-We should all watch this as homework ;)
https://www.talque.com/app#/app/ngx/org/jTiDQhBciSV8rDuqoYvi/session-detail/bZrIrhXnNHe2KNBWMIXp
Can have a follow up session with Gregsn if needed

-Tech implementation
seems like @texone has a good start already. Does this also bring up issues around pin annotations and such though (how to know which tooltip implementation to use- would be nice to have that decoupled from types)

-Design
What tooltips are needed / useful? Can we switch on the fly?

All flavours stopped working

just noticed that materials with fuse shader generator nodes compile two times. Once there is an error and then a second time, it looks like something is a frame too late, which causes the behavior of first generating an invalid material.
You can also see that it is blinking red first, and then blinking green.

The shader should be generated in the callback GenerateShaderSource: Stride.Rendering/Rendering/Materials/IComputeNode.cs#L25

this is the compilation event of the sink, it also passes the generator context which tells you whether it is a material or custom shader.

looks like an else input is not always passed through might be related with delegates look in example patch in R&D is wokring with add scale 0 hack

Might make sense to integrate those?

https://github.com/BrianSharpe/GPU-Noise-Lib/blob/master/gpu_noise_lib.glsl

We need to discuss project timing and milestones. I'll prep a google doc with an outline and share beforehand