Welcome, Guest
Username Password: Remember me

TOPIC: Documentation for developing Lightworks effects

Re: Any new variables available to pixel shaders? 4 months, 3 weeks ago #165198

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 1994
  • 4 months, 3 weeks ago
"Clamp", "Mirror" etc., together with the or similar shader code: ...
float4 Fgd = (any (xy < 0.0) || any (xy > 1.0)) ? 0.0.xxxx : tex2D (CropSampler, xy);
... with angle change, produces step edges:
This attachment is hidden for guests. Please log in or register to see it.

In your "Flexi-blend" effect, this can be avoided by slightly changing the crop settings.

Using "Border" and this shader Code ...
float4 Fgd = tex2D (CropSampler, xy);
... the edges look good even without cropping. (Windows, Intel-GPU)

jwrl wrote:
... Because "Border" appears to behave ambiguously in Linux I don't believe that it can be used on its own to give the same result. If it could the conditional setting of Fgd could be avoided...
I hope to continue using "Border" for all platforms ....
Mainly automatically translated
--------------------------------------------
Windows 10, 64 Bit
Intel i5-4440 (3,1 GHz) ; Intel HD Graphics 4600
Last Edit: 4 months, 3 weeks ago by schrauber.

Re: Any new variables available to pixel shaders? 4 months, 3 weeks ago #165209

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 9122
  • 4 months, 3 weeks ago
I suspect that the behaviour of "Border" may be GPU dependent.

With my Quadro K2200 with scaling operations I get a flickering 1 pixel line down the left hand edge of the frame. I still haven't got round to reinstalling my Linux setup, so I haven't yet checked with that. I plan to have two dual boot systems - one with the K2200 and a W10/Mint configuration, and the second with a GTX 970 and a W7/Ubuntu setup.

I know that Mint and Ubuntu are very similar, so that second system may end up using a different Linux version. Hopefully January will give me the time to get round to this.

Have a happy new year.

Re: Any new variables available to pixel shaders? 4 months, 3 weeks ago #165435

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 1994
  • 4 months, 3 weeks ago
Thank you, I wish you and all also a happy year 2018.

jwrl wrote:
... With my Quadro K2200 with scaling operations I get a flickering 1 pixel line down the left hand edge of the frame...

Edit:
On a black background, I did not notice the lines, but with a bright background, I now see the lines with Intel GPU.

Test with Windows:

In my case, the gray line came from mixing two textures based on the alpha value. The gray line is the background, which was darkened by the linar interpolated alpha value when mixing.
Actually, this line should be mixed with the foreground, but this is black at that position because the position is just outside the texture ("Border" sampler setting).

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

Test of a problem solution (Windows):

I used two samplers.
For RGB, the Sampler setting "Mirror".
For Alpha "Border" (to get smooth and stepless edges during rotation))
:pinch: Warning: Spoiler!
(Under Linux, however, a second foreground texture would have to be created for the second Fg-Samper.)


The output of the pixel shader for zoom and rotation:
(RGB mirrored edges, but not alpha)
//........
// ------ OUTPUT-------
return float4 (tex2D (FgSampler     , xy).rgb,
               tex2D (FgSamplerAlpha, xy).a);



Mix in the next shader pass:
float4 ps_main (float2 uvBg: TEXCOORD1, float2 uvFg: TEXCOORD2) : COLOR
{ 
   float mix = tex2D (FgZoomSampler, uvFg).a;
   float3 retval = lerp (tex2D (BgSampler, uvBg).rgb,
                         tex2D (FgZoomSampler, uvFg).rgb,
                         mix);

   return float4 (retval, 1.0);
}


The result of slow keyframing:
This attachment is hidden for guests. Please log in or register to see it.


Compatibility:
jwrl wrote:
... a different Linux version. Hopefully January will give me the time to get round to this ...

Ok.
Mainly automatically translated
--------------------------------------------
Windows 10, 64 Bit
Intel i5-4440 (3,1 GHz) ; Intel HD Graphics 4600
Last Edit: 4 months, 3 weeks ago by schrauber.

Re: Any new variables available to pixel shaders? 3 months, 3 weeks ago #168362

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 1994
  • 3 months, 3 weeks ago
Calculation examples of auto-synced parameters (LW14.1):

Example 1 "PROGRESS_Time" (effect progress in seconds):
float _Progress            
float _Length;       
#define PROGRESS_Time      (_Length * _Progress)
Although previews on _Progress & _Length export results may differ for certain export settings, these differences compensate for PROGRESS_Time calculation.


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


Example 2

To calculate is:
LENGHT_original: Effect length in seconds, unaffected by export Settings
PROGRESS_TimeReverse: Reverse effect progress in seconds, unaffected by export settings

Prerequisite is a ramp generated by automatic keyframing:
float Progress_original
<
	string Group = "Effect progress: Do not alter in any way";
	string Description = "Progress";
	float MinVal = 1.0;
	float MaxVal = 0.0;
        float KF0    = 0.0;
        float KF1    = 1.0;
> = 0.0;
Note:
MinVal = 1.0 : The Min value is higher than the Max value to lock the slider.
MaxVal = 0.0: The Max value is lower than the Min value to lock the slider.


The actual calculation:
float _Progress            
float _Length;       
#define PROGRESS_Time   (_Length * _Progress)
#define LENGHT_original (PROGRESS_Time / max(Progress_original , 1.0E-6))   // (1.0E-6 prevents division by zero)
#define PROGRESS_TimeReverse   (LENGHT_original - PROGRESS_Time)
Mainly automatically translated
--------------------------------------------
Windows 10, 64 Bit
Intel i5-4440 (3,1 GHz) ; Intel HD Graphics 4600
Last Edit: 3 months, 3 weeks ago by schrauber.

Re: Any new variables available to pixel shaders? 3 months, 2 weeks ago #169231

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 9122
  • 3 months, 2 weeks ago
This post arises out of a discussion triggered by Sylvain Leroux on the beta forums about the lack of precision affecting moves and scaling in higher resolution formats. As we know, the effects subsystem in Lightworks will display any parameter defined as ranging from -1 to +1 as a percentage value between -100% and +100%. The same applies if the range is from 0 to 1, except that it will be displayed as a percentage value between 0% and 100%. At the moment that gives it the potential to display up to five decimal places of precision for those types of values although more commonly it will be four or even three.

Arguably, extending the display of those parameters in some way would be a major benefit for higher resolution formats. It would be extremely helpful for the effects programmer to be able to specify the number of decimal places to be shown. In fact I would go further: I suggest that the ability to declare when percentage ranges should and should not be used for parameters would be a real help.

For example, let's assume I want an effect that adjusts saturation over the range from 0% to 400%. There's currently no way that can be specified. By the same token, even if I could it's highly unlikely that I would want or need those extra decimal places for saturation.

Currently there's nothing that can be done about that. We are limited to the way that the effects engine interprets floating point values for display. Using my saturation example, currently you would just write the following.

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

That would display a parameter that ranges in value from 0.00 to 4.00. While unsurprising, it really isn't a very clear indication for the user of what's actually going on. It's a poor user interface from that perspective, and it doesn't provide the precision that we could need either. If instead the programmer could write something like the following it would become much clearer.

float Saturation : PERCENT : N.xx
<
   string Description = "Saturation";
   float MinVal = 0.0;
   float MaxVal = 4.0;
> = 1.0;

The programmer would know that by declaring a parameter that way the display would show the range 0-400% with 2 digits on the right side of the decimal point. In fact in such a scheme N.xx could be optional, in which case the display would just default to the current form for percentage display.

There are also occasions where integer increments are required for parameters. Specifying ": N" would suppress the decimal point completely to meet that need. Conversely it should also be possible to specify when 0-1 shouldn't mean 0-100%. It would be great to be able to do something like this to achieve a displayed range from -1.0000 to 1.0000 instead of -100% to 100%.

float PixOffsX : ABS : N.xxxx
<
   string Description = "X pixel offset";
   float MinVal = -1.0;
   float MaxVal = 1.0;
> = 0.0;

The serious problem that introducing such a scheme would create is that Lightworks has legacy software out there. What would version 10 make of such a declaration? To get around this it would be necessary to use something like the form shown below.

#ifdef _LENGTH
   float PixOffsX : ABS : N.xxxx
#else
   float PixOffsX
#endif
<
   string Description = "X pixel offset";
   float MinVal = -1.0;
   float MaxVal = 1.0;
> = 0.0;

If more than one parameter made use of explicit display precision declarations you could of course enclose the whole parameter block in the ifdef - endif structure. However using that form could make coding effects more unwieldy.

Anyway, those are my first thoughts on the matter. Of course, it may not even be possible to implement those compiler switches or the supporting code for the user interface that they would need, in which case this all becomes academic. But it would be nice if we could come up with some suggestions for the developers in time for 14.2 or any higher version.

Any feedback welcome.
Last Edit: 3 months, 2 weeks ago by jwrl.

Re: Any new variables available to pixel shaders? 3 months, 1 week ago #169247

  • hugly
  • OFFLINE
  • Platinum Boarder
  • Posts: 14298
  • 3 months, 1 week ago
I don't understand why the effects should be modified. In my understanding the two decimal-digit display and it's behaviour is the major problem.

Today, I'm able to enter a value with four decimals manually in DVE and the position shows on the screen as desired, but only two rounded decimals are displayed. As long as I don't touch the field everything stays in place. When I click on the field and press enter the (wrong) rounded value is passed over to the effect and DVE jumps away from desired position.

A display with 4 decimals which remembers longer entries, together with some kind of fine adjustment would be a solution for my needs.
It's better to travel well than to arrive...
Last Edit: 3 months, 1 week ago by hugly.

Re: Any new variables available to pixel shaders? 3 months, 1 week ago #169259

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 9122
  • 3 months, 1 week ago
But it isn't just about one user's needs. There are currently effects that use parameters as integers, where even two numerals to the right of the decimal point are a problem and four would be absurd. By the same token, parameters like saturation, brightness and gain are already well covered with just the current five decimal places. Increasing that to seven as you suggest would be unhelpful.

The suggestion that I made would allow any arbitrary number of numerals to the right of the decimal point, although four is probably a practical maximum. It would also allow inhibiting the display of percentage values when they're unneeded and allow them where currently they are impossible.
Last Edit: 3 months, 1 week ago by jwrl.

Re: Any new variables available to pixel shaders? 3 months, 1 week ago #169260

  • hugly
  • OFFLINE
  • Platinum Boarder
  • Posts: 14298
  • 3 months, 1 week ago
Nothing said against your proposal, but complexity of implementation might hinder easy and fast realization.

A change on display (field for entry) from 2 to 3 or 4 digits (decimals) will create for some effects insane precision, but will do no harm. On the other hand it would solve existing problems with effects which need higher precision, but a mode to fine adjust those values is necessary, from my point of view.

And, truncating already entered valid values to rounded two decimals after re-entering a field is just a bug.
It's better to travel well than to arrive...
Last Edit: 3 months, 1 week ago by hugly.

Re: Any new variables available to pixel shaders? 3 months, 1 week ago #169261

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 9122
  • 3 months, 1 week ago
You're very fond of identifying something as a bug because it doesn't do what you want or expect it to do. I suspect that the rounding is part of the current effect engine design, and is unlikely be a bug. It may not even change if the number of digits displayed was increased. There are currently quite a few things wrong with the effects engine design in my opinion, but they certainly aren't bugs.

For example, it would be good if it was possible to change the mode of an effect and completely suppress any unused parameters when that happens: you currently can't do that. In my "DVE with vignette" effect I set up the size and shape with mask size and aspect ratio parameters. That's fine for the ellipse and diamond shapes, but not as good for the rectangle. I would have liked to have been able to use the more intuitive X and Y adjustments and suppress size and aspect ratio when in that mode. Currently you can't do that, so I was left with a workaround that's understandable across all three shapes, at the cost of being less than ideal for one.

What it comes down to is this: I have written more effects for Lightworks than anyone else who's posted here. For me, the single most difficult part of the process is designing the user interface. Once I've worked out what I want to do the code usually comes together very quickly. But then I will spend a fair amount of time just playing with the effect, fine tuning the interface, trying different versions again and again until I'm happy. I may have spent a few hours on the effect itself, but have spent days on the interface.

There are a lot of things that you currently can't do with it and that I would like to be able to. The ideal solution would be arbitrary interface layouts, but I'm enough of a realist to realise that is extremely unlikely to ever be available. The above suggestion addresses just one small corner of a much larger whole.

[EDIT] Possibly another method of setting up dynamic formatting would be to support arguments similar to those used in the C/C++ printf function. For example, %d, %3.4f or a new one, %3.2p for percent values might be a way to do it. That latter would be needed because %3.2f %% wouldn't convert parameters in the normalised Cg range to percentage values.

Where those arguments could go without doing other damage is another question though.
Last Edit: 3 months, 1 week ago by jwrl.

Re: Controling pixel interpolation when scaling? 3 months ago #169523

  • jasonrohrer
  • OFFLINE
  • Junior Boarder
  • Posts: 28
  • 3 months ago
I just realized that 2D DVE and every other effect in LW is editable as shader language code!

This is amazingly powerful.

I wrote my own version of the 2D DVE that rounds the location to the nearest pixel when sampling the texture, thus solving my own problem.

Old line:

ret = tex2D( FgSampler, fgPos );


New line:

ret = tex2D( FgSampler, 
             float2( round( 640 * fgPos.x ) / 640, 
                     round( 360 * fgPos.y ) / 360 ) );


640x360 is hard-coded for the source material that I'm working with (every pixel in the game footage is a 2x2 block of color at 1280x720), but I'm going to add some sliders for this setting as well, to make it work for any game footage with any sized pixels.


Wowee is Lightworks insanely great...
Last Edit: 3 months ago by jasonrohrer.

Re: Controling pixel interpolation when scaling? 3 months ago #169528

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 1994
  • 3 months ago
Great.
Welcome to the effect programmers.

You could also try switching off the linear filter setting further up in the effect code:
texture Fg;
sampler FgSampler = sampler_state
{
   Texture = <Fg>;
   MinFilter = Point;
   MagFilter = Point;
   MipFilter = Point;
};


If it's an image, then you could experiment with the image effect as well. The image will be imported into this effect in the effect settings menu.
Mainly automatically translated
--------------------------------------------
Windows 10, 64 Bit
Intel i5-4440 (3,1 GHz) ; Intel HD Graphics 4600
Last Edit: 3 months ago by schrauber.

Re: Documentation for developing Lightworks effects 3 months ago #169554

  • jasonrohrer
  • OFFLINE
  • Junior Boarder
  • Posts: 28
  • 3 months ago
I tried changing the filtering, but it didn't work the way I thought it would.

I'm using a test image of diagonally-placed 2x2 white pixel blocks.

I used DVE to zoom in by a factor of 8x.


The linear one looks as you might expect:

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


but look at the point one:

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


There are extra gray pixels in there that suggest something strange is going on.

The only thing I changed here was the filter type, exactly as you showed in your code snippet.
Last Edit: 3 months ago by jasonrohrer.

Re: Documentation for developing Lightworks effects 3 months ago #169556

  • jasonrohrer
  • OFFLINE
  • Junior Boarder
  • Posts: 28
  • 3 months ago
Whoa! Suprisingly, these artifacts are NOT visible in the exported video. With Point texture sampling, the exported video has super-sharp pixels.

I'm guessing this is a result of the way that LW is loading frames-as-textures in the graphics card. Maybe the textures are compressed to save bandwidth? I'm not sure.

But apparently LW is applying the effects "for real" at export time using some other mechanism.


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


Well, looking closer, these pixels are not all square, and there are black gaps between some of the white corners.

My other code that did the position rounding suffered from similar issues. Thus, I think precision errors are to blame. I think that 32-bit floats are used for texture position in HLSL.
Last Edit: 3 months ago by jasonrohrer.

Re: Documentation for developing Lightworks effects 3 months ago #169562

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 9122
  • 3 months ago
The artefact that you're seeing is caused by Lightworks scaling the shader output for display in the preview window. That will always have a degree of interpolation unless your preview image is unscaled, in which case every pixel in the display would match a shader-generated one.

jasonrohrer wrote:
looking closer, these pixels are not all square, and there are black gaps between some of the white corners.

My other code that did the position rounding suffered from similar issues. Thus, I think precision errors are to blame. I think that 32-bit floats are used for texture position in HLSL.

Yes, and I suspect that the result in Linux/OS-X would differ somewhat. Although possibly not, because the same underlying hardware engine is being used. Have you tried using floor() or ceil() instead of round() to see if there's a similar problem?

To rule out export encoding being the cause of the problem you could also export a single frame as a PNG image and see if it shows the same issue in the same place.
Last Edit: 3 months ago by jwrl.

Re: Documentation for developing Lightworks effects 3 months ago #169566

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 9122
  • 3 months ago
One further thought occurs to me. We are applying effects after whatever Lightworks has done to the video to decode it. That could very well also be contributing to the geometry errors. If it is I don't believe that there's anything that can be done to fix that part of the problem.
Time to create page: 0.80 seconds
Scroll To Top