Welcome, Guest
Username Password: Remember me

TOPIC: Documentation for developing Lightworks effects

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

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 8590
  • 3 months, 1 week ago
I've answered my own question: three pages back hugly raised the issue. My preferred approach would be to do something like this.

#ifdef EXTENDED_14_1   // Or whatever the flag is called
bool LW_14_1 = true;
#else
bool LW_14_1 = false;
#endif

You would then test the state of LW_14_1 in your main code and if it's false display a message using rhinox202's text technique or schrauber's cross out on screen.

Using a two step process like that may seem inefficient, but in fact it allows for the use of alternative compilation paths should that be necessary. You would get the best of both worlds.
Last Edit: 3 months, 1 week ago by jwrl.

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

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 1655
  • 3 months, 1 week ago
jwrl wrote:
...Schrauber, you have compiled the modified SineLights: how much bigger was the FXT file before and after? ...

With error text 479 bytes (.fxt).
Without I did not look.
However, Lightworks also always requires the original .fx file:
EDIT: Erroneous file replaced:
This attachment is hidden for guests. Please log in or register to see it.


I also considered simply checking the new variables for plausibility to indirectly check the current version.
However, this probably requires that the code for the error message, etc. would have to be incorporated in the regular effect code, which would increase the GPU load even in regular operation mode.
Mainly automatically translated
--------------------------------------------
Windows 10, 64 Bit
Intel i5-4440 (3,1 GHz) ; Intel HD Graphics 4600
Last Edit: 3 months, 1 week ago by schrauber.

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

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 8590
  • 3 months, 1 week ago
jwrl wrote:
...Schrauber, you have compiled the modified SineLights: how much bigger was the FXT file before and after? ...
schrauber wrote:
With error text 479 bytes (.fxt).
Without I did not look.

That seems remarkably low. Obviously it's not going to be a problem.

I've decided to raise this as a specific request in the build 101730 forums. Because it's developed into a more general discussion about effects design theory I have also moved all of the posts relating to the discussion about 14.1 flags here. If you have more to contribute to the original thread by all means do so, but since we now have a new beta I don't know how much attention anything there will get.
Last Edit: 3 months, 1 week ago by jwrl.

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

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 8590
  • 3 months, 1 week ago
After going through the 34 posts that I've just moved, one thing is clear. There appears to be a basic misunderstanding about the way that flags like the new WINDOWS work.

At compile time the effects compiler encounters the line "#ifdef WINDOWS". It goes looking for that flag, and if it's set acts on the code that follows. If it isn't set or doesn't exist at all the test will fail. The compiler will instead compile anything after any #else statement and before the #endif statement. That's it.

For that reason you cannot use the presence or absence of that flag to determine the version of LW being used, only the environment that it's in. The test will only succeed if the Lightworks version is post 14.1 build 101421 and running under Windows.

Don't read that as "The test will only succeed if the Lightworks version is post 14.1 build 101421 or running under Windows". That's a different thing entirely and isn't what happens.

( I edited the text above to make it clearer, but schrauber had posted his replies below well before I did that. When he posted "If LW14.1 is used on Linux or Mac, then no new version can be identified." I hadn't yet made the edit - in fact it was in part the reason that I did. )
Last Edit: 3 months ago by jwrl.

Re: Any new variables available to pixel shaders? 3 months ago #161836

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 1655
  • 3 months ago
From another thread:
rhinox202 wrote:
jwrl wrote:
thanks to the development team for the new variables and flags added to the effects subsystem. However, as usual, it's never enough.

No doubt this will be necessary later on, but with the current #ifdef WINDOWS you can detect new versions, no? Consider the code below. Because #ifdef WINDOWS is a new addition to the current Beta, only new versions will use the code. There is slight code reuse but the #else requires code anyway.

#ifdef WINDOWS
// do something
#else
// do the same something as above 
#endif


The code I used only for testing purposes on Windows.
If LW14.1 is used on Linux or Mac, then no new version can be identified.
Mainly automatically translated
--------------------------------------------
Windows 10, 64 Bit
Intel i5-4440 (3,1 GHz) ; Intel HD Graphics 4600

Re: Any new variables available to pixel shaders? 3 months ago #161850

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 1655
  • 3 months ago
From another thread:
lghtwrks wrote:
#ifdef WINDOWS
      #ifdef LWKS_14_1
            //
      #endif 
      #ifdef LWKS_12_5
 	    //
      #endif
#endif 

#ifdef LINUX
      #ifdef LWKS_14_1
etc.

#ifdef MAC
      #ifdef LWKS_14_1
etc.


s


#ifdef LWKS_12_5 It does not make much sense, because older versions of Lightworks would need to be changed.
A distinction between Linux and Mac seems unnecessary according to current knowledge.
Mainly automatically translated
--------------------------------------------
Windows 10, 64 Bit
Intel i5-4440 (3,1 GHz) ; Intel HD Graphics 4600

Re: Any new variables available to pixel shaders? 3 months ago #161853

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 8590
  • 3 months ago
schrauber wrote:
#ifdef LWKS_12_5 It does not make much sense, because older versions of Lightworks would need to be changed.

Exactly! This kind of misunderstanding was why I posted #161812, above. Even if the flag LWKS_12_5 was added it could serve very little purpose, because it doesn't exist in the version to which it refers and never can.
Last Edit: 3 months ago by jwrl.

Re: Any new variables available to pixel shaders? 3 months ago #161859

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 8590
  • 3 months ago
schrauber wrote:
A distinction between Linux and Mac seems unnecessary

I would go even further: explicitly defining either is pointless, because #ifndef WINDOWS will do exactly the same thing in version 14.1 post build 101421.

For those who still don't get this I'll try and explain it in a different way: #define is a compiler directive and isn't actually ever compiled at all. It just tells the compiler which of the following blocks of code to compile, nothing more. The test isn't performed at run time, so nothing that depends on the test being done then will work. You can do meaningful things with it if you set the state of a variable inside the #ifdef - #endif block, but that's it. Even then, transferring that compiled effect to an older version of Lightworks will inevitably fail.

If the source is available in Effect Templates it will recompile next time that you launch Lightworks so any error will be overcome, but if you don't have the source there you will have a faulty effect. I cannot think of a way to circumvent that limitation except to be profoundly thankful that Lightworks recompiles any user effects it finds in Effect Templates at launch.
Last Edit: 3 months ago by jwrl.

Re: Any new variables available to pixel shaders? 3 months ago #161860

  • khaver
  • Pro User
  • OFFLINE
  • Platinum Boarder
  • Posts: 3290
  • 3 months ago
jwrl, it’s still my belief that we need to maintain 3 effect file versions. One, your proposed Universal Windows/Linux/OSX version that can use the new variables. Two, a Windows v14.0 and below version. And three, a Linux v14.0 and below.

There will still be new effects created that won’t require any new system variables, that should be made available to outright license purchasers.
Work Comp: Retired!

Home Comp: Newer! Bigger! Faster!

Send me a tip: paypal.me/4khaver

Re: Any new variables available to pixel shaders? 3 months ago #161864

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 1655
  • 3 months ago
Effects that do not require new variables; low to medium complexity of the shader code:
That will not change. Only one file for all.
Compatibility, Windows & Linux & Mac: All Lightworks versions


Effects that do not require new variables but with high complexity:
One file, compiling in Windows with "ps_3_0" , Linux / Mac compiling "PROFILE".
Compatibility (one file):
Linux & Mac: All Lightworks versions
Windows: LW 14.1 and higher

Effects that require the new variables:
Compatibility: LW 14.1 and higher (Linux & Mac & Windows)

More compatibility: If the effect could determine the Lightworks version in the future, then there would be the theoretical possibility of assigning the missing variables to a version-dependent slider (usually unacceptable) or accepting worse effects.

Several files are also possible, the function insufficiencies of course remained on old versions of Lightworks. Whether that makes sense is probably dependent on the effect.
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: Any new variables available to pixel shaders? 3 months ago #161927

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 8590
  • 3 months ago
Schrauber has got it. You really don't need three versions. The existing two will work if the Linux version uses the WINDOWS check. And as people progressively upgrade it will be possible to retire those older Windows versions.

In reality the bulk of the user effects posted will almost certainly not require that flag at all. More important will be a means of determining whether we can tell what version of Lightworks we're using. To that end I have developed a block of code that can be added to any effect that needs it, which will display in yellow over a red band the text "LW 14.1+ EFFECT ONLY".

#ifdef _LENGTH     // or whatever flag is used!!!!

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

// Do the effect here, then after the techniques section add the following

#else

//--------------------------------------------------------------//
// LW 14.1 error handler
//--------------------------------------------------------------//

// NOTE:  In this section if _OutputAspectRatio hasn't already
// been declared ahead of the #ifdef it should be added here.

float4 ps_error (float2 uv : TEXCOORD1) : COLOR
{
   // The error message is stored as an unsigned integer [y][x] array
   // in 24-bit bit map form.  The text reads "LW 14.1+ EFFECT ONLY"

   uint _text [6][4] = { {  6424627, 8110112, 2046447,  9228702 },
                         {  7571507, 1622072,  412771, 14472099 },
                         {  8064371, 1688368,  396515,  5822371 },
                         {  7013731, 3721136,  396391,  7921059 },
                         { 16451555, 1622832,  412771,  3201459 },
                         {  6488783, 1818678,  408035,  3395998 } };

   // If the input sampler has another name it should be substituted below.
   // If the effect requires no input then some form of background must be
   // created instead.  float4 retval = 1.0.xxxx would work (but look ugly).

   float4 retval = tex2D (FgdSampler, uv);

   float t_idx = (uv.x * 8.0) - 2.0;            // The text bitmaps are 4 wide, so this places them centre screen

   int idx_0 = (int) floor (((uv.y * 175.0) - 150.0) / _OutputAspectRatio);   // Text vertical size and position is set here
   int idx_1 = (int) floor (t_idx);                               // The array x index is derived from t_idx as an integer
   int idx_2 = (int) floor ((t_idx - idx_1) * 24.0);              // The bit number is now derived.

   if ((idx_0 > -5) && (idx_0 < 10)) {          // This routine puts a red stripe across the screen for the text background
      retval.r  = 1.0;
      retval.gb = 0.0.xx;
   }

   t_idx = 0.0;                                 // We will now only set t_idx to 1 if the corresponding bit is set.

  // This is a nasty way of getting a bit from the bitmap.  I tried using the >> operator, but it didn't compile
  // in Windows even though Cg is supposed to support it.  I didn't try it in Linux because this works in both.

   if ((idx_1 >= 0) && (idx_1 < 4) && (idx_0 >= 0) && (idx_0 < 6))
      t_idx = fmod (floor (_text [idx_0][idx_1] / pow (2.0, idx_2)), 2.0);

   retval.g += t_idx;                           // By turning on green over our red background we get yellow text

   return retval;
}

technique ErrorText
{
   pass E_1 { PixelShader = compile PROFILE ps_error (); }
}

#endif

The error message looks like this. I tried to design the font to look as attractive as possible but still...


This image 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.


As you can see, this will work on any aspect ratio. To test it I coded an example built around one of my blur effects. If you would like to try it out, download the zip file then comment out "#define _LENGTH" in line 8 of the code. It should give you the error message. Uncomment it, recompile, and the effect should work normally.


And this is no longer speculation! Read the post below for details.


This attachment is hidden for guests. Please log in or register to see it.
Last Edit: 3 months ago by jwrl.

Re: Any new variables available to pixel shaders? 3 months ago #161975

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 8590
  • 3 months ago
In the beta threads for 14.1 Great White has posted this.

Great White wrote:
I've made some changes for the next beta; there's now a #define for each of the special auto-synced parameters so that you can test whether a parameter is supported by the running version or not. Each definition shares the same name as its associated parameter, but is in upper case. Eg.

#ifdef _LENGTH

float someVariable = someFunction( _Length );

#endif


The full list of definitions is therefore :

_OUTPUTFPS
_OUTPUTASPECTRATIO
_LENGTH
_LENGTHFRAMES
_OUTPUTWIDTH
_OUTPUTHEIGHT
_PROGRESS


I can't think of any reason to use the definitions for the old variables (eg. _Progress, _PROGRESS) but I included them for completeness. Any new variables that are added in the future will get accompanying definitions.

I also now define "OSX" when running on Mac, and "LINUX" when running on Ubuntu/Fedora/etc.

That means that polling any of the new non-OS flags will reliably identify the fact that we're running on a newer version of Lightworks. In my sample code above, you could do the following:

#ifdef _LENGTH     // or any of the newer non-OS flags

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

// Do the effect here ....

I have updated the code in the above zip file if you want to try it.
Last Edit: 3 months ago by jwrl.

Re: Any new variables available to pixel shaders? 3 months ago #162008

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 1655
  • 3 months ago

Great!
I will test it when the next beta is available.
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: Any new variables available to pixel shaders? 3 months ago #162010

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 8590
  • 3 months ago
Actually, I've gone further. The code is now entirely self-contained. Here it is, and a full zip file of the test effect is attached.

#ifndef _LENGTH       // This test will fail if we don't have LW 14.1 or newer

//--------------------------------------------------------------//
// LW 14.1 error handler triggered by earlier LW versions
//--------------------------------------------------------------//

texture Inp;
sampler FgdSampler = sampler_state { Texture   = <Inp>; };

bool Dummy
<
   string Description = "This effect only works on Lightworks versions over 14.0";
> = true;

float _OutputAspectRatio;

float4 ps_error (float2 uv : TEXCOORD1) : COLOR
{
   // The error message is stored as an unsigned integer [y][x] array
   // in 24-bit bit map form.  The text reads "LW 14.1+ EFFECT ONLY"

   // A 6x4 array means that we don't overflow the variable constraints
   // imposed by ps_2_b in Windows.  If a longer message is needed you
   // could increase the bitmap to as high as 31-bit by changing the
   // multiplicand used in idx_2.  Even though I have declared _text
   // as an unsigned integer there are problems if we use all 32 bits.
   // I suspect that's because of my method of recovering the bit state.

   uint _text [6][4] = { {  6424627, 8110112, 2046447,  9228702 },
                         {  7571507, 1622072,  412771, 14472099 },
                         {  8064371, 1688368,  396515,  5822371 },
                         {  7013731, 3721136,  396391,  7921059 },
                         { 16451555, 1622832,  412771,  3201459 },
                         {  6488783, 1818678,  408035,  3395998 } };

   // The text bitmaps are 4 wide, so this next places them centre screen.
   // The video is broken up into 192 pixel locations in blocks of 24 by
   // this operation.

   float t_idx = (uv.x * 8.0) - 2.0;

   // Text vertical size and position is set here.  The number of vertical
   // pixels that we have available is governed by the aspect ratio.  I
   // started with a figure of 108 in 16:9, but wasn't happy with the look
   // of square pixels so I trimmed the figures until I was happier with
   // what I had on screen.

   int idx_0 = (int) floor (((uv.y * 175.0) - 150.0) / _OutputAspectRatio);

   // The array x index is derived by simply rounding down t_idx and saving
   // it as an integer.

   int idx_1 = (int) floor (t_idx);

   // The bit number is then derived by subtracting that integer from t_idx
   // and scaling the result by the number of bits in the bitmap.

   int idx_2 = (int) floor ((t_idx - idx_1) * 24.0);

   // This is a nasty way of getting a bit from the bitmap.  I tried using
   // the >> operator, but it didn't compile in Windows even though Cg is
   // supposed to support it.  I didn't try it in Linux because this works
   // in both.  The technique used is to raise 2 to the power of the bitmap
   // position, then use that to divide the bitmap value and round it down
   // to a whole number value.  That is then divided by 2, and the remainder
   // is the value of the bit at that position.

   // How much simpler would (_text [idx_0][idx_1] >> idx_2) & 1 have been!

   if ((idx_1 >= 0) && (idx_1 < 4) && (idx_0 >= 0) && (idx_0 < 6))
      t_idx = fmod (floor (_text [idx_0][idx_1] / pow (2.0, idx_2)), 2.0);
   else t_idx = 0.0;

   // We have now set t_idx to 1 only if the corresponding bit is set.  The
   // next section puts a red ribbon across the screen for the text background.
   // It would be possible to have a semi-transparent red or any other colour
   // ribbon by doing something like
   // retval.rgb = lerp (retval.rgb, float2 (1.0, 0.0).xyy, 0.5) or similar.

   float4 retval = tex2D (FgdSampler, uv);   // Just a standard LW sampler ...

   if ((idx_0 > -5) && (idx_0 < 10)) {
      retval.r  = 1.0;
      retval.gb = 0.0.xx;
   }

   // By turning on green over the red background we get yellow text.  The
   // technique used here is safe because t_idx is only ever non-zero when
   // the bit is set in the bitmap.

   // If you've chosen to use a semi-transparent ribbon, this next must become
   // more complex.  Something like retval.rg = max (retval.rg, t_idx.xx) would
   // work.  If you decide that you don't want yellow text I'll leave it up to
   // you how you get there.  Simple primaries, secondaries and black or white
   // are easy enough, but you would need to define any more subtle colours and
   // use a lerp() instruction, with t_idx used to turn the text colour on.

   retval.g += t_idx;

   return retval;
}

technique ErrorText
{
   pass E_1 { PixelShader = compile PROFILE ps_error (); }
}

#else

// From here on is the actual effect code.


The code in the zip file is fully commented. This version not only puts the text on screen, it also displays a warning message in the settings. There is a disadvantage to that, but it's probably not too important. Read the comments in the zip file header for more details of the potential problems this approach may cause.


This image 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.






This attachment is hidden for guests. Please log in or register to see it.
Last Edit: 3 months ago by jwrl.

Re: Any new variables available to pixel shaders? 3 months ago #162014

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 1655
  • 3 months ago
schrauber wrote:
More compatibility ... the function insufficiencies of course remained on old versions of Lightworks. Whether that makes sense is probably dependent on the effect.

I think that some of my future effects will use the new variables to make the user's effects settings easier. For example, to make frequencies, wavelengths, and other speeds independent of the effect length.

Such effects will probably continue to be compatible with old Lightworks versions. The user would, of course, only from LW14.1 get the benefit of the new comfort.
Mainly automatically translated
--------------------------------------------
Windows 10, 64 Bit
Intel i5-4440 (3,1 GHz) ; Intel HD Graphics 4600
Last Edit: 3 months ago by schrauber.
Time to create page: 0.59 seconds
Scroll To Top