Welcome, Guest
Username Password: Remember me

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

Documentation for developing Lightworks effects 3 years, 4 months ago #145326

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12887
  • 3 years, 4 months ago
schrauber wrote:
Does "Nearest" work on your system?

It doesn't report an error when compiling. Whether it actually does anything or just resets back to default I can't say without further testing, which won't be today. On this basis it appears to me that the safest setting to use is Linear for all three parameters. This would make sense in a 2D environment, which is what we're dealing with.

"Point" would probably be faster, but would be likely to cause artefacts. I suspect that "Nearest" would too.

I have changed the entry that you quoted above to reflect the actual correct state of affairs.
Last Edit: 3 years, 4 months ago by jwrl.

Documentation for developing Lightworks effects 3 years, 4 months ago #145488

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4454
  • 3 years, 4 months ago
Ok, I've tried to structure the most important information.
See the update of my post #143678 above on page 1.

But I have to add some quotes.
For example, I plan to assign the assignment of textures and inputs under the heading "Shaders".
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)

Documentation for developing Lightworks effects 3 years, 4 months ago #145495

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12887
  • 3 years, 4 months ago
Why?

For what it's worth, here's an example of the definitions block that I often start with.

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

#define BLACK   float2(0.0,1.0).xxxy

#define HALF_PI 1.5707963
#define PI      3.1415927
#define TWO_PI  6.2831853

float _OutputWidth;
float _OutputAspectRatio;

#define Output_Height (_OutputWidth/_OutputAspectRatio)

I then delete what I don't need.
Last Edit: 3 years, 4 months ago by jwrl.

Documentation for developing Lightworks effects 3 years, 4 months ago #145497

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12887
  • 3 years, 4 months ago
In response to the use of the HLSL noise function I posted the following in the user effects forum. I know that I go on about using Cg and not using HLSL but it's worth repeating. Cg is the language in which Lightworks effects are written.

Scanning through the Cg library in alphabetical order, you will find min modf mul normalize pack pow radians. There is no noise listed, so please do not use HLSL as a language reference. The function noise isn't the only difference, either. In HLSL you could write the following:

   a = ddx_fine (b);

That would compile and run under HLSL, but ddx_fine doesn't exist in Cg. Instead you could only use:

   a = ddx (b);

Similarly, there are countbits, dst, fma, mad, msad4, to name a few. There are doubtless more, including functions that require different syntax in Cg like firstbitlow/findLSB and firstbithigh/findMSB.

Also please do not use GLSL as a language reference either. For example, in GLSL you could write the following:

   a = inversesqrt (b);

That would compile and run under GLSL. It wouldn't in Cg. Instead you would need:

   a = rsqrt (b);

Similarly, just off the top of my head, there are differences with fract/frac, mod/modf, modf/fmod, mix/lerp. There are more, again including functions that have no equivalent in Cg at all.
Last Edit: 3 years, 4 months ago by jwrl.

Documentation for developing Lightworks effects 3 years, 4 months ago #145528

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4454
  • 3 years, 4 months ago
jwrl wrote:
Why?
Probably a misunderstanding?

schrauber wrote:
Ok, I've tried to structure the most important information....
I hope that in this way the information collected in this thread are easier to find. Presumably, this thread will contain a lot more pages over time.
Or do you have a structured collection in work?

schrauber wrote:
For example, I plan to assign the assignment of textures and inputs under the heading "Shaders".
With "heading Shaders" I did not mean a section in a program code, but only the structure of my post on page 1.

"TEXCOORD4" takes the coordinates going from input4, but the programmer must make this assignment in the 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.

Documentation for developing Lightworks effects 3 years, 4 months ago #145639

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12887
  • 3 years, 4 months ago
My "Why?" above was because I thought that you were planning to move the input and samplers section into the shaders section in your code. I was genuinely curious. You're explanation clears that up, so yes, it was a misunderstanding.

Documentation for developing Lightworks effects 3 years, 4 months ago #145774

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4454
  • 3 years, 4 months ago
jwrl wrote:
....Scanning through the Cg library in alphabetical order, [...] There is no noise listed, ...
Ok, maybe in the future will we find a code that can do this job? ...

jwrl wrote:
... so please do not use HLSL as a language reference...
According to Windows, noise from pc_2 upwards is no longer supported anyway.

jwrl wrote:
... The function noise isn't the only difference, either. In HLSL you could write the following:
   a = ddx_fine (b);
That would compile and run under HLSL, but ...
For real? Microsoft writes: Minimum shader model: 5

jwrl wrote:
... Similarly, there are countbits, dst, fma, mad, msad4, to name a few ....
Also minimum shader model: 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)
Last Edit: 3 years, 4 months ago by schrauber.

Documentation for developing Lightworks effects 3 years, 4 months ago #145796

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12887
  • 3 years, 4 months ago
Quite true, but still do-able if you define the appropriate profile. Perhaps a better example might have been the modulo operator, %. That definitely doesn't play nicely in Linux/OS-X.

The point is that HLSL should be avoided as a reference. You run the risk of creating an effect that will only run on one platform, and I think that should be discouraged. In the past I've worked through several user effects resolving cross-platform issues.

It wasn't just HLSL incompatibilities either. There were several ported over from GLSL originals by Linux users. I don't want to have to do it again.

Documentation for developing Lightworks effects 3 years, 4 months ago #145906

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4454
  • 3 years, 4 months ago
Update of my post #143678 above on page 1.
jwrl wrote:
...The point is that HLSL should be avoided as a reference ...
OK, I quoted you in the section "An Introduction".

jwrl wrote:
...here's an example of the definitions block that I often start with...
Thank you, you can find this in the "Definitions and declarations" section of my overview.

Texture coordinates I mentioned in the sections "Inputs" and "Shaders".
Here is a draft that I copied into the section "Shaders"
Is something wrong (technical or in translation)? :

.....................................................


Shaders:

Name of the Pixel Shaders:

jwrl wrote:
I also prefix any [...] shaders with ps_ so that it's immediately clear what's going on. [...]
Example: float4 ps_main
Note: This name must also be entered outside the shader in the corresponding entry in the "Techniques" section.



Texture coordinates:

Quote, redsharknews.com:
float4 ps_main( float2 xy1 : TEXCOORD1 ) : COLOR
The “float2 xy1 : TEXCOORD1” inside the parenthesis defines “xy1” to be the coordinates of the texture.

If the effect has more inputs:

Example with two inputs:
float4 ps_main (float2 xy1 : TEXCOORD1, float2 xy2 : TEXCOORD2) : COLOR

TEXCOORD1 receives the pixel coordinates from the first input.
TEXCOORD2 is assigned to the second input.
TEXCOORD3 is assigned to the third input.
etc.
Input 1 is the first input you declared in the "Inputs" section (outside the shader).
The second declared entry is the number 2, etc.
Note: Only textures that are visible as input in video routing are considered. Internal textures that are rendered only within the effect and sent to a sampler can not be used as a source for texture coordinates.

Special case:
TEXCOORD0 is not assigned to an input.
Problem: Great White wrote:
Lightworks always arranges for texcoord0 to be in the range 0..1, whereas texcoord1 and above are modified to include the necessary half texel adjustments that you need for DirectX (when running on Windows).
This can lead to pixel shifts in certain areas.
In the case of rendering with TEXCOORD0, this inaccuracy can worsen the result with each pass.
On the other hand, there are special cases in which TEXCOORD0 nevertheless makes sense.


Many effects name the assigned variable with "xy", or xy with a number. "uv" is also common.
float4 ps_main (float2 uv1 : TEXCOORD1, float2 uv2 : TEXCOORD2) : COLOR
This is also consistent with the U and V addresses in the sampler settings outside the pixel shaders.


The coordinates float2 (0.0, 0.0) is the pixel position in the upper left corner of the video.
float2 (1.0, 1.0) is the lower right corner.
In the horizontal direction the values increase from left to right.
Vertically, the values rise from the top to the bottom.
This is different than in mathematical diargams, where the value increases from the bottom to the top in the Y-direction.





Programming and GPU load or shader limits:


jwrl wrote:

Also conditional statements aren't particularly efficient. They will always carry out both branches of the condition, then discard the result they don't need. For this reason I will usually try and structure them so that I can force an exit as the sole result of the true condition. In normal programming this is definitely not the best practice, but here it's a good idea if you can do it. It also means that there is no else condition.

Finally loops will always be unrolled at compile time at least in the Windows compiler. I'm unsure about that for the other two. This has implications for just how much you can build into a loop.
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.

Documentation for developing Lightworks effects 3 years, 4 months ago #145907

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12887
  • 3 years, 4 months ago
This is starting to look really good as a resource. Are you still out there, brotenet? I suspect not, since there have only been the two posts in this thread from that user. In fact there have only been those two posts from them in any thread on these forums.

In terms of the effort that has gone into this thread, you really should be the thread starter, schrauber. What I think is the appropriate action is to split off your first post and all the following into this new thread which is pinned in place of the old one. I'll leave any editing of the first few lines entirely up to you.

The old thread has been given a link to this should brotenet return.
Last Edit: 3 years, 4 months ago by jwrl.

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

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12887
  • 3 years, 4 months ago
I've just been alerted to a cross-platform issue by gr00by in the user effects forum.

gr00by wrote:
Does anyone know why some FXs (like "Filmic Look" or "FilmFX") are greyscale-only on Linux?

It turned out that I had written a block of code in FilmLook.fx that looked like this.

   float4 retval = tex2D (InpSampler, uv);
   float luma;

        ...

   luma   = dot (retval, _luma_conv);
   retval = lerp (luma, retval + retval - luma, (Saturation + 1.0) / 2.0);

In his original post, gr00by referred to my favourite reading matter at the moment, the Nvidia Cg reference manual.

gr00by" wrote:
I am not sure what is going here (I don't know GLSL). I just see that `luma` is a float, `retval` is a float4, and looking at "Nvidia Cg reference" I see that `lerp` requires `a` and `b` args to be of the same size.

And he is quite correct. When compiled under D3D on Windows it works as I wanted it to. When compiled under Cg it fails. In neither case does the compiler return an error, it just behaves differently.

Fortunately if you need to use mixed float types in a lerp() instruction (or anywhere else for that matter) the fix is simple. Changing the last line to read as follows is all that I needed to do.

   retval = lerp (luma.xxxx, retval + retval - luma.xxxx, (Saturation + 1.0) / 2.0);

The ".xxxx" suffix is a swizzle operation. In the case of the fix to the bug above it causes the compiler to regard luma as a float4 containing the same value in all its members.

The way that it works is simple. 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.

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.
Last Edit: 1 year, 7 months ago by jwrl.

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

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4454
  • 3 years, 4 months ago
jwrl wrote:
...However I usually do it just as a reminder to myself of what I'm actually dealing with.

Is this the reason why you do not use "float4 (0.0, 0.0, 0.0, 1.0)" for the color black, but instead: ?
jwrl wrote:

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

#define BLACK   float2(0.0,1.0).xxxy

Much shorter is not, and it has confused me to see a fload2 value defined, although a float4 value is to be output from the shader.
Now I notice that you probably also clarified that you are planning to work with the notation .xyzw for color values, instead of .rgba?

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

Have I understood that correctly?

Edit:
Would that also work?:
   retval = lerp (luma.rrrr, retval + retval - luma.rrrr, (Saturation + 1.0) / 2.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: 1 year, 7 months ago by jwrl.

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

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12887
  • 3 years, 4 months ago
schrauber wrote:
it has confused me to see a fload2 value defined, although a float4 value is to be output from the shader.

That was an example, not a rule. I could just as easily have used the following structure.

#define BLACK   float4(0.0.xxx,1.0)

It would have meant exactly the same thing.

schrauber wrote:
Now I notice that you probably also clarified that you are planning to work with the notation .xyzw for color values, instead of .rgba?

Most certainly not! The examples that I quoted were to indicate that there are times when using a float4 that you are not referring to RGB and alpha values. In cases like that a different notation is available, and would likely make more sense. 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. That's why I said:

jwrl wrote:
Having the xyzw form available is useful when you're dealing with non-rgba media

I did actually mis-type there. I should have actually said "non-rgba values" rather than "non-rgba media". The example that I gave refers to media, but it's actually a more general notation than that.

schrauber wrote:
Would that also work?:
   retval = lerp (luma.rrrr, retval + retval - luma.rrrr, (Saturation + 1.0) / 2.0);

Yes, it would. It's not what I would have chosen to do though, because it looks like you're assigning a red value to green, blue, and alpha channels. You're actually assigning a single float value to all four members of a float4. The more generalised form xyzw is the more appropriate one to use, in a case like that in my opinion.
Last Edit: 1 year, 7 months ago by jwrl.

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

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4454
  • 3 years, 4 months ago
jwrl wrote:
#define BLACK   float4(0.0.xxx,1.0)

Looks good!
Thank you, good to know.

My example with "luma.rrrr" was just a question of understanding.
I also find your solution more suitable.
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 #146096

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4454
  • 3 years, 4 months ago
Update of the first post.

Cross-platform compatibility:
NEW 3) Application of variables into intrinsic functions

Parameters
NEW Select "Technique" (SetTechnique)

The next step is to fill the section "Technique" with content ...
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)
Time to create page: 0.58 seconds
Scroll To Top