Welcome, Guest
Username Password: Remember me

TOPIC: Documentation for developing Lightworks effects (Post # 1 contains summary links)

Re: Documentation for developing Lightworks effects 3 years, 4 months ago #146150

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4454
  • 3 years, 4 months ago
Multi technique


We can allow the user to switch between pixel shaders.
This simplified graph shows the "Channel Extractor" effect .
See also Post # 143763 on page 1 (filename: Sample 4 - Single input, Multi technique.fx)
This image is hidden for guests. Please log in or register to see it.


For each Pixel Shader, we can program a "Technique" that activates a selected Pixel Shader.
technique Red
{
   pass pass_one
   {
      PixelShader = compile PROFILE ps_ExtractRed();
   }
}

technique Green
{
   pass pass_one
   {
      PixelShader = compile PROFILE ps_ExtractGreen();
   }
}

technique Blue
{
   pass pass_one
   {
      PixelShader = compile PROFILE ps_ExtractBlue();
   }
}

technique Alpha
{
   pass pass_one
   {
      PixelShader = compile PROFILE ps_ExtractAlpha();
   }
}

For the selection of Technique the order in the code is decisive.
This must correspond to the user settings (see "Parameters").

The name of the Technique is not important.
A suitable name is of course meaningful.
The same rules apply to the naming as are used for variable names.
Avoid identical names with eg variables etc.

Differing from the original "Channel Extractor" code, I made adjustments according to our template:
  • Pass rename to "pass_one"
  • Shader names have been added to the prefix "ps_".



If many Techniques are used, I prefer to write the code compact:

technique Red   {pass _1  {PixelShader = compile PROFILE ps_ExtractRed();   }}
technique Green {pass _1  {PixelShader = compile PROFILE ps_ExtractGreen(); }}
technique Blue  {pass _1  {PixelShader = compile PROFILE ps_ExtractBlue();  }}
technique Alpha {pass _1  {PixelShader = compile PROFILE ps_ExtractAlpha(); }}


I replaced the name "pass_one" with "_1".
The name is unimportant, and can be used multiple times in the code.
The same rules apply to the naming as are used for variable names.
(The pass-name can not start with a number)
Because each of these techniques uses only one pass, names like "SinglePass", "pass_one" or "_1" are useful.
(Multi pass effects are shown later on using another example.)


At the end of the line we see which pixel shader is activated by the respective technique. This name must match the name of the corresponding pixel shader.
Mainly automatically translated
--------------------------------------------
Software: Lightworks 2020.1; || Windows 10, 64 Bit
Hardware: Intel i5-4440 (3,1 GHz); || shared RAM: 8 GB; || Intel HD Graphics 4600 (can use max. 2 GB of shared RAM)
Last Edit: 3 years, 4 months ago by schrauber.

Re: Documentation for developing Lightworks effects 3 years, 4 months ago #147047

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4454
  • 3 years, 4 months ago
Multi pass


Here is a simplified example with two active pixel shaders:
This image is hidden for guests. Please log in or register to see it.


// Techniques
//--------------------------------------------------------------//
technique Shear
{
   pass pass_one
   <
      string Script = "RenderColorTarget0 = OutputFromPassOne;";
   > 
   {
      PixelShader = compile PROFILE ps_ShearHorizontal();
   }

   pass pass_two
   {
      PixelShader = compile PROFILE ps_ShearVertical();
   }
}



To make the textures available to the pixel shaders, we still have to create the inputs and samplers:
This image is hidden for guests. Please log in or register to see it.



In order for it to be compiled, all import code and sampler code must be above the pixel shader and the technique:
This image is hidden for guests. Please log in or register to see it.



//--------------------------------------------------------------//
// Header
//--------------------------------------------------------------//

int _LwksEffectInfo
<
   string EffectGroup = "GenericPixelShader";
   string Description = "Shear, May 2017";
   string Category    = "Stylize";
   string SubCategory = "Samples";
> = 0;

//--------------------------------------------------------------//
// Inputs
//--------------------------------------------------------------//

texture Input;

// This is a TWO pass effect, so we need an intermediate texture
// which stores the results from pass 1, and serves as the input
// to pass 2.  This is done by defining a target texture in this
// way.  Because it's a target texture only it will not appear
// as a user input to the effect.

texture OutputFromPassOne : RenderColorTarget;

//--------------------------------------------------------------//
// Samplers
//--------------------------------------------------------------//

sampler FgSampler = sampler_state
{
   Texture = <Input>;
   AddressU  = Border;
   AddressV  = Border;
   MinFilter = Linear;
   MagFilter = Linear;
   MipFilter = Linear;
};

sampler P1OutSampler = sampler_state
{
   Texture = <OutputFromPassOne>;
   AddressU  = Border;
   AddressV  = Border;
   MinFilter = Linear;
   MagFilter = Linear;
   MipFilter = Linear;
};


//--------------------------------------------------------------//
// Parameters
//--------------------------------------------------------------//

float Horizontal
<
   string Description = "Horizontal";
   float MinVal       = -1.00;
   float MaxVal       = 1.00;
> = 0.0;

float Vertical
<
   string Description = "Vertical";
   float MinVal       = -1.00;
   float MaxVal       = 1.00;
> = 0.0;



//--------------------------------------------------------------
// Shaders
//--------------------------------------------------------------
float4 ps_ShearHorizontal( float2 xy : TEXCOORD1 ) : COLOR
{
   float2 pos = xy;
   pos.x += ( pos.y - 0.5 ) * Horizontal;
   return tex2D( FgSampler, pos );
}


float4 ps_ShearVertical( float2 xy : TEXCOORD1 ) : COLOR
{
   float2 pos = xy;
   pos.y += ( pos.x - 0.5 ) * Vertical;
   return tex2D( P1OutSampler, pos );
}



//--------------------------------------------------------------//
// Techniques
//
// Now that we have more than one pass, this specifies the
// order in which the passes are executed.
//--------------------------------------------------------------//

technique Shear
{
   pass pass_one
   <
      string Script = "RenderColorTarget0 = OutputFromPassOne;";  // Sets the target the result is placed in
   > 
   {
      PixelShader = compile PROFILE ps_ShearHorizontal();
   }

   pass pass_two
   {
      PixelShader = compile PROFILE ps_ShearVertical();
   }
}

The intermediate target of the texture "OutputFromPassOne" could also get a different name, which must match in the sections Techniques, Imports and the Sampler settings.
(A new name must be used to name the sampler.)


Edit:
You can also use multiple texture targets with different names. You can make these textures available to one or more pixel shaders via different samplers. This allows you to create a complex routing within the effect with pixel shaders, similar to the routing we already know from Lightworks with different effects.
Mainly automatically translated
--------------------------------------------
Software: Lightworks 2020.1; || Windows 10, 64 Bit
Hardware: Intel i5-4440 (3,1 GHz); || shared RAM: 8 GB; || Intel HD Graphics 4600 (can use max. 2 GB of shared RAM)
Last Edit: 3 years, 4 months ago by schrauber.

Re: Documentation for developing Lightworks effects 3 years, 4 months ago #147254

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4454
  • 3 years, 4 months ago
I have deleted my experiments with macros in the section "Techniques" because it missed the goal of simplification.

Instead, other suggestions ...

jwrl wrote:
I have saved a template file for creating effects. It's undergone some modification since I started doing this, but here's the current version.

//--------------------------------------------------------------//
// Techniques
//--------------------------------------------------------------//

technique MyEffect
{
   pass pass_one
   {
      PixelShader = compile PROFILE ps_main ();
   }
}

I'm not suggesting for one moment that this should be slavishly copied by anyone writing FX files. It's just what I do.


"My Effect" is probably the placeholder for the effect name.
In this standard case, with only one "technique" and one Pass, I do not see any informative added value, and therefore propose to remove it without replacement:
//--------------------------------------------------------------//
// Techniques
//--------------------------------------------------------------//

technique
{
   pass
   {
      PixelShader = compile PROFILE ps_main ();
   }
}


In this example, I also shortened "pass pass_one".
In my experiments on Windows it works.

In the case of multi-technique or multi-pass, these names are helpful for Code clarity. On the other hand, I would find the use of comment delimiters more meaningful, because they are not subject to restrictions comparable to variables, and immediately make clear that they have no program function.

Your opinions?
Mainly automatically translated
--------------------------------------------
Software: Lightworks 2020.1; || Windows 10, 64 Bit
Hardware: Intel i5-4440 (3,1 GHz); || shared RAM: 8 GB; || Intel HD Graphics 4600 (can use max. 2 GB of shared RAM)
Last Edit: 3 years, 4 months ago by schrauber.

Re: Documentation for developing Lightworks effects 3 years, 4 months ago #147258

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12887
  • 3 years, 4 months ago
Well, as I said, I'm not suggesting for one moment that this should be slavishly copied by anyone writing FX files. It's just what I do. What ever works for you is fine. Here's another way in a 2x2 technique. Again, it's readable, and the techniques carry the program name plus an indication of what the technique does. And no, this isn't a real effect before anyone asks!

technique quick_grade_gamma {
   pass P_1
   < string Script = "RenderColorTarget0 = Fgd;"; >
   {   PixelShader = compile PROFILE ps_gamma (); }
   pass P_2
   { PixelShader = compile PROFILE ps_main (); }
}

technique quick_grade_S_curve {
   pass P_1
   < string Script = "RenderColorTarget0 = Fgd;"; >
   {   PixelShader = compile PROFILE ps_S_curve (); }
   pass P_2
   { PixelShader = compile PROFILE ps_main (); }
}

There are thousands of variants that you can use. Just use whatever works for you, and that you can easily return to in six month's time when someone has found an obscure bug!
Last Edit: 3 years, 4 months ago by jwrl.

Re: Documentation for developing Lightworks effects 3 years, 4 months ago #147386

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4454
  • 3 years, 4 months ago
Thanks for the example "Multi technique, Multi pass"
In the first post I linked to your post.

A question about "RenderColorTarget0"
Does anyone know other variants?
Has "0" a particular meaning?
Mainly automatically translated
--------------------------------------------
Software: Lightworks 2020.1; || Windows 10, 64 Bit
Hardware: Intel i5-4440 (3,1 GHz); || shared RAM: 8 GB; || Intel HD Graphics 4600 (can use max. 2 GB of shared RAM)
Last Edit: 3 years, 4 months ago by schrauber.

Re: Documentation for developing Lightworks effects 3 years, 4 months ago #147395

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4454
  • 3 years, 4 months ago
Transfer parameters from the Technique to the Pixel Shader:



For different shader passes, you can also give the Pixel Shader different parameters.
For example, the value 0.5
PixelShader = compile PROFILE ps_main (0.5);

jwrl wrote:
Here's an example from my SuperBlur effect. This does five passes through the same shader, each time with different parameters.

/--------------------------------------------------------------//
// Techniques
//--------------------------------------------------------------//

technique SuperBlur
{
   pass pass_one
   <
      string Script = "RenderColorTarget0 = Blur_1;";
   >
   {
      PixelShader = compile PROFILE ps_main (FgdSampler, RADIUS_1);
   }

   pass pass_two
   <
      string Script = "RenderColorTarget0 = Blur_2;";
   >
   {
      PixelShader = compile PROFILE ps_main (b1_Sampler, RADIUS_2);
   }

   pass pass_three
   <
      string Script = "RenderColorTarget0 = Blur_1;";
   >
   {
      PixelShader = compile PROFILE ps_main (b2_Sampler, RADIUS_3);
   }

   pass pass_four
   <
      string Script = "RenderColorTarget0 = Blur_2;";
   >
   {
      PixelShader = compile PROFILE ps_main (b1_Sampler, RADIUS_4);
   }

   pass pass_five
   {
      PixelShader = compile PROFILE ps_main (b2_Sampler, RADIUS_5);
   }
}



In the Pixel Shader, variables must be declared in a certain way, which can take the values passed by the technique.
Example from the same effect:
float4 ps_main (float2 uv : TEXCOORD1, uniform sampler blurSampler, uniform float blurRadius) : COLOR


The complete effect "Super blur":
//--------------------------------------------------------------//
// Lightworks user effect SuperBlur.fx
//
// Created by LW user jwrl 30 June 2016.
//  Modified for version 14 11 February 2017.
//
// This version modified at khaver's suggestion to reduce the
// number of render targets used - 2 July 2016.
//
// This is a spin-off from my radial blur as used in several
// of my other effects.  To ensure ps_2_0 compliance for
// Windows users this is a five pass effect, however this is
// achieved by taking five passes through the one shader.
//
// Bug fix 26 February 2017 by jwrl:
// This corrects for a bug in the way that Lightworks handles
// interlaced media.  THE BUG WAS NOT IN THE WAY THIS EFFECT
// WAS ORIGINALLY IMPLEMENTED.
//
// It appears that when a height parameter is needed one can
// not reliably use _OutputHeight.  It returns only half the
// actual frame height when interlaced media is playing and
// only when it is playing.  For that reason the output height
// should always be obtained by dividing _OutputWidth by
// _OutputAspectRatio until such time as the bug in the
// Lightworks code can be fixed.  It seems that after contact
// with the developers that is very unlikely to be soon.
//
// Note: This fix has been fully tested, and appears to be a
// reliable solution regardless of the pixel aspect ratio.
//--------------------------------------------------------------//

int _LwksEffectInfo
<
   string EffectGroup = "GenericPixelShader";
   string Description = "Super blur";
   string Category    = "Stylize";
   string SubCategory = "Blurs and Sharpens";
> = 0;

//--------------------------------------------------------------//
// Inputs
//--------------------------------------------------------------//

texture Input;

texture Blur_1 : RenderColorTarget;
texture Blur_2 : RenderColorTarget;

//--------------------------------------------------------------//
// Samplers
//--------------------------------------------------------------//

sampler FgdSampler = sampler_state
{
   Texture   = <Input>;
   AddressU  = Clamp;
   AddressV  = Clamp;
   MinFilter = Linear;
   MagFilter = Linear;
   MipFilter = Linear;
};

sampler b1_Sampler = sampler_state
{
   Texture   = <Blur_1>;
   AddressU  = Clamp;
   AddressV  = Clamp;
   MinFilter = Linear;
   MagFilter = Linear;
   MipFilter = Linear;
};

sampler b2_Sampler = sampler_state
{
   Texture   = <Blur_2>;
   AddressU  = Clamp;
   AddressV  = Clamp;
   MinFilter = Linear;
   MagFilter = Linear;
   MipFilter = Linear;
};

//--------------------------------------------------------------//
// Parameters
//--------------------------------------------------------------//

float Size
<
   string Description = "Radius";
   float MinVal       = 0.0;
   float MaxVal       = 1.0;
> = 0.5;

float Amount
<
   string Description = "Amount";
   float MinVal       = 0.0;
   float MaxVal       = 1.0;
> = 1.0;

//--------------------------------------------------------------//
// Definitions and declarations
//--------------------------------------------------------------//

#define LOOP     12
#define DIVIDE   49

#define RADIUS_1 4.0
#define RADIUS_2 10.0
#define RADIUS_3 20.0
#define RADIUS_4 35.0
#define RADIUS_5 56.0

#define ANGLE    0.261799

float _OutputAspectRatio;
float _OutputWidth;

#define OutputHeight (_OutputWidth/_OutputAspectRatio)

#pragma warning ( disable : 3571 )

//--------------------------------------------------------------//
// Shaders
//--------------------------------------------------------------//

float4 ps_main (float2 uv : TEXCOORD1, uniform sampler blurSampler, uniform float blurRadius) : COLOR
{
   float4 retval = tex2D (blurSampler, uv);

   if ((Size > 0.0) && (Amount > 0.0)) {
      float2 xy, radius = float2 (blurRadius / _OutputWidth, blurRadius / OutputHeight) * Size;

      for (int i = 0; i < LOOP; i++) {
         sincos ((i * ANGLE), xy.x, xy.y);
         xy *= radius;
         retval += tex2D (blurSampler, uv + xy);
         retval += tex2D (blurSampler, uv - xy);
         xy += xy;
         retval += tex2D (blurSampler, uv + xy);
         retval += tex2D (blurSampler, uv - xy);
      }

      retval /= DIVIDE;

      if ((blurRadius == RADIUS_5) && (Amount < 1.0))
         retval = lerp (tex2D (FgdSampler, uv), retval, Amount);
   }

   return retval;
}

//--------------------------------------------------------------//
// Techniques
//--------------------------------------------------------------//

technique SuperBlur
{
   pass pass_one
   <
      string Script = "RenderColorTarget0 = Blur_1;";
   >
   {
      PixelShader = compile PROFILE ps_main (FgdSampler, RADIUS_1);
   }

   pass pass_two
   <
      string Script = "RenderColorTarget0 = Blur_2;";
   >
   {
      PixelShader = compile PROFILE ps_main (b1_Sampler, RADIUS_2);
   }

   pass pass_three
   <
      string Script = "RenderColorTarget0 = Blur_1;";
   >
   {
      PixelShader = compile PROFILE ps_main (b2_Sampler, RADIUS_3);
   }

   pass pass_four
   <
      string Script = "RenderColorTarget0 = Blur_2;";
   >
   {
      PixelShader = compile PROFILE ps_main (b1_Sampler, RADIUS_4);
   }

   pass pass_five
   {
      PixelShader = compile PROFILE ps_main (b2_Sampler, RADIUS_5);
   }
}
Mainly automatically translated
--------------------------------------------
Software: Lightworks 2020.1; || Windows 10, 64 Bit
Hardware: Intel i5-4440 (3,1 GHz); || shared RAM: 8 GB; || Intel HD Graphics 4600 (can use max. 2 GB of shared RAM)

Re: Documentation for developing Lightworks effects 3 years, 4 months ago #147408

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12887
  • 3 years, 4 months ago
That's a powerful effect that requires a powerful system to function in real time. It makes very clear why more economical box blurs and Pascal's triangle and the like are used!

It's something that I did because I could, not because it was a wise thing to do. And I also wanted to see how far I could push the technology, too.

Re: Documentation for developing Lightworks effects 3 years, 4 months ago #147427

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4454
  • 3 years, 4 months ago
If a comparison with simple GPUs is of interest (Intel HD Graphics 4600):
My GPU, which must share the space on the same chip with the CPU, it can in the 720p HD output format (24fps) usually still in real time (GPU load about 95%). Larger output formats I usually do not need.
Mainly automatically translated
--------------------------------------------
Software: Lightworks 2020.1; || Windows 10, 64 Bit
Hardware: Intel i5-4440 (3,1 GHz); || shared RAM: 8 GB; || Intel HD Graphics 4600 (can use max. 2 GB of shared RAM)

Re: Documentation for developing Lightworks effects 3 years, 3 months ago #148413

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4454
  • 3 years, 3 months ago
I have tried to summarize some quotes etc. on the topic of Swizzle operator.
Do you have any suggestions for improvement?




Swizzle operator



jwrl wrote:

There are two ways that subscripts work with floats in Cg. You can use either rgba notation or xyzw notation.


jwrl wrote:
You can regard a float as being an array containing just 1 member, which therefore is referenced by the suffix ".x". In exactly the same way that you can move values in a float4 by typing newval.xyzw = oldval.zyxw, you can say newval.xyzw = oldval.xxxx


jwrl wrote:
You can play all sorts of tricks by doing things like float2 xy = uv.yx, which will rotate the image through 90 degrees. You can also do things like Input.rgb = Input.aaa, in which case the alpha channel will be shown as a monochrome image. That could also be written Input = Input.aaaa and achieve the same result [...]

[...] What you cannot do is change the notation with which you refer to a variable. See the example below.

   float4 In1 = 1.0;
   float4 In2 = 0.0;

   In2.w = 1.0;
   In1.rgb = In2.rgb     // This will fail!!!  Do not use

   float4 In1 = 1.0;
   float4 In2 = 0.0;

   In2.w = 1.0;
   In1.rgb = In2.xyz     // This will work


Having the xyzw form available is useful when you're dealing with non-rgba media - HSL, HSV and the like, for example.

jwrl wrote:

[...] "non-rgba values" The example that I gave refers to media, but it's actually a more general notation than that.

[...]
In the same way that referring to a position as xy.rg would be confusing, referring to an HSL value as hsl.rgba would also cause confusion. There can be no red, green or blue components of an HSL value, just hue, saturation and luma.



Another example with rgba values, in which the xywz form is preferable.


Instead of:
#define BLACK   float4 (0.0, 0.0, 0.0, 1.0)

Can we also write:
#define BLACK   float4 (0.0.xxx,1.0)

0.0 is assigned to x
.xxx causes the xyz to take the value of x
1.0 is assigned to w

We could have written 0.0.rrr, but what could be confusing because only one value corresponds to the color red.


A variant which causes the compiler to treat float2 as float4:
#define BLACK   float2 (0.0,1.0).xxxy

0.0 is assigned to x
In the first step, 1.0 is still assigned to y (without consideration of the Swizzle operator)
.xxxy causes the xyz to take the value of x, and w take the value of y




Use float like float4

jwrl wrote:
Where you are simply assigning a value from a float to all members of a float4, for example, this is unnecessary. It's what each of Cg/HLSL/GLSL allow in the language definition. However I usually do it just as a reminder to myself of what I'm actually dealing with.

The exceptions are some intrinsic functions.
See post #146013 on page 4.
Mainly automatically translated
--------------------------------------------
Software: Lightworks 2020.1; || Windows 10, 64 Bit
Hardware: Intel i5-4440 (3,1 GHz); || shared RAM: 8 GB; || Intel HD Graphics 4600 (can use max. 2 GB of shared RAM)
Last Edit: 3 years, 3 months ago by jwrl.

Re: Documentation for developing Lightworks effects 3 years, 3 months ago #148433

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12887
  • 3 years, 3 months ago
jwrl wrote:
Where you are simply assigning a value from a float to all members of a float4, for example, this is unnecessary. It's what each of Cg/HLSL/GLSL allow in the language definition. However I usually do it just as a reminder to myself of what I'm actually dealing with.

schrauber wrote:
The exceptions are some intrinsic functions.
See post #146013 on page 4.

That isn't quite true. It isn't an exception. It's a difference in the way that D3D and Cg based compilers interpret that example. For clarity I'll give a condensed version of the example.

   float4 ret  = tex2D (InpSampler, uv);
   float  luma = dot (retval, float4 (0.2989, 0.5866, 0.1145, 0.0));

   ret = lerp (luma, ret + ret - luma, Saturation);

D3D (Windows) interprets lerp (float, float4, float) as lerp (float.xxxx, float4, float). Cg (Linux/Mac) interprets it as lerp (float, float4.r, float).xxxx. They are both valid interpretations, but produce inconsistent results cross-platform. The Cg language definition requires that both input variables to the lerp () instruction should be of the same type. The result of combining a float variable with a float4 is undefined.

When I changed the code to the form lerp (float.xxxx, float4, float) the ambiguity was addressed by explicitly swizzling the first float value to be interpreted as float4. That isn't an exception, it's exactly consistent.

What might have been a better way of handling that example would have been float4 (lerp (float.xxx, float4.rgb, float), float4.a). That would have preserved the alpha value unchanged. Since the float value in that example was a monochrome version of the float4 value without the alpha channel it would have been a smarter way to do it. In fact, here's an alternative way of preserving the alpha channel.

   ret.rgb = lerp (luma.xxx, ret.rgb + ret.rgb - luma.xxx, Saturation);

And here's another less efficient alternative.

   ret.rgb = lerp (luma.xxxx, ret + ret - luma.xxxx, Saturation).rgb;
Last Edit: 3 years, 3 months ago by jwrl.

Re: User Effects files (Post #1 has them all) 3 years, 2 months ago #151051

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4454
  • 3 years, 2 months ago
I see in my effect "zoom out, zoom in; logarithmic" the same problem as already reported by some other scaling effects. See Post "Edge Noise When Using Motion Effects with Transparency".

Only when outside the texture is zoomed with slow keyframing.
Not as strong as for example with the Ligktworks 2D DVE effect, but still a visibly uneven movement of the edges.

Is there a simple code that will force the GPU to also interpolate the edges to the outside?
Sampler-Filter Linear I have set, but this seems to work on the edges not properly.

Currently I am testing the interpolation in the shader code, but that is very complex, and I am unsure if it will work ...
Mainly automatically translated
--------------------------------------------
Software: Lightworks 2020.1; || Windows 10, 64 Bit
Hardware: Intel i5-4440 (3,1 GHz); || shared RAM: 8 GB; || Intel HD Graphics 4600 (can use max. 2 GB of shared RAM)
Last Edit: 3 years, 2 months ago by jwrl.

Re: User Effects files (Post #1 has them all) 3 years, 2 months ago #151075

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12887
  • 3 years, 2 months ago
I haven't tried that.

The technique that I used in the triple DVE effect was pretty much a standard 2D DVE algorithm. The alpha channel is handled in exactly the same way as the rest of the video - as a linear interpolation. I wonder if there is a difference in the way that Lightworks effects handle alpha channels? I know that I have to apply gamma correction to the alpha channel with Lightworks generated titles to get the same visual result. If they are doing that, in an interpolated alpha channel such as that produced by moving or scaling the image it could cause of those erratic results at the edges.
Last Edit: 3 years, 2 months ago by jwrl.

Re: User Effects files (Post #1 has them all) 3 years, 2 months ago #151410

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4454
  • 3 years, 2 months ago
I have done some tests.
Positive zoom works well with my zoom in effect:
This attachment is hidden for guests. Please log in or register to see it.


With the 2D-DVE effect, the skis jump both with positive as well as with negative zoom. Here is an example of nagative zoom. The additional zoom effect is only used to make the problem more visible in the video.
This attachment is hidden for guests. Please log in or register to see it.

This image is hidden for guests. Please log in or register to see it.





Test with my zoom in effect at negative zoom:
This attachment is hidden for guests. Please log in or register to see it.
The edges do not jump so strongly, but they move unevenly. For Triple-DVE effect, it looks similar when the edge softness is set to 0.
Mainly automatically translated
--------------------------------------------
Software: Lightworks 2020.1; || Windows 10, 64 Bit
Hardware: Intel i5-4440 (3,1 GHz); || shared RAM: 8 GB; || Intel HD Graphics 4600 (can use max. 2 GB of shared RAM)
Last Edit: 3 years, 2 months ago by schrauber.

Re: User Effects files (Post #1 has them all) 3 years, 2 months ago #151419

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4454
  • 3 years, 2 months ago
When I use a grid it becomes visible that it is probably a common problem when minimizing textures:
This attachment is hidden for guests. Please log in or register to see it.

If I understand it correctly then there is at minimizing the problem that not all original pixels are used? To prevent this is probably the task of the Mipmap, which provides the min filter according to prepared textures?

However, the mipmap from the 2D texture seems to make a 3 D texture?
I wonder if the mipmap is available in Lightworks effects?
I did not notice any change, whether I chose MipFilter = None, Point, Linear, Anisotropic, or PyramidalQuad in the sampler settings.
Mainly automatically translated
--------------------------------------------
Software: Lightworks 2020.1; || Windows 10, 64 Bit
Hardware: Intel i5-4440 (3,1 GHz); || shared RAM: 8 GB; || Intel HD Graphics 4600 (can use max. 2 GB of shared RAM)
Last Edit: 3 years, 2 months ago by schrauber.

Re: User Effects files (Post #1 has them all) 3 years, 2 months ago #151421

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12887
  • 3 years, 2 months ago
I've just checked on my Quadro K2200, and the effect is similar but possibly somewhat less obvious. I suspect that has little to do with Lightworks and a lot to do with the interpolation process being applied in the GPU.

This is a time when it would be really great to be able to use GaussianQuad for the mipfilter!!! But I suspect that you're right, and that its setting is just ignored with 2D processing.
Last Edit: 3 years, 2 months ago by jwrl.
Time to create page: 0.57 seconds
Scroll To Top