Welcome, Guest
Username Password: Remember me

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

Re: Documentation for developing Lightworks effects 2 years, 2 months ago #180043

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12931
  • 2 years, 2 months ago
Yes, you're quite right - I did misunderstand what you were saying. I'm sorry.

You can achieve what you want by first changing these definitions to these values.

#define RADIUS_1 0.002
#define RADIUS_2 0.005
#define RADIUS_3 0.01
#define RADIUS_4 0.0175
#define RADIUS_5 0.028

You would then just change line 124 to this.

   float2 xy, radius = float2 (1.0, _OutputAspectRatio) * blurRadius * Size;

In fact I've just done that. Thank you. I'll also go through the other blurs based on the same algorithm and adjust them too.

I know that Lightworks blurs are based on pixel size - well at the least the ones that I've looked at are.

[EDIT] Having just checked the soft blurs and ghost blur, they do already work on frame size percentage and not pixel size. However anything based on the Lightworks effect is based on pixel size. Fortunately none of mine are. However other effects that I have written that use a variant of that algorithm will also need attention.
Last Edit: 1 year, 8 months ago by jwrl.

Re: Documentation for developing Lightworks effects 2 years, 2 months ago #180324

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4473
  • 2 years, 2 months ago
A compatibility question (multiple shader passes):
With Windows, the shader can output to the same target texture from which the sampler draws the samples from the previous pass.
For example, I can do 10 passes with just one render-texure.

Is this compatible with other platforms?

Example shaders:
texture Render : RenderColorTarget;
sampler render_Sampler = sampler_state {Texture = <Render>;};


Example Techniques:
   //pass P_1 ...
   // ...

   pass P_2
   <
      string Script = "RenderColorTarget0 = Render;";
   >
   {
      PixelShader = compile PROFILE PS_main(render_Sampler);
   }


   pass P_3
   <
      string Script = "RenderColorTarget0 = Render;";
   >
   {
      PixelShader = compile PROFILE PS_main(render_Sampler);
   }
// ...
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: 2 years, 2 months ago by schrauber.

Re: Documentation for developing Lightworks effects 2 years, 2 months ago #180330

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12931
  • 2 years, 2 months ago
Possibly, but not particularly good practice I would have thought. And what would happen if you were dealing with multiple displacement effects like blurs and DVEs is anyone's guess.

Re: Documentation for developing Lightworks effects 2 years, 2 months ago #181011

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12931
  • 2 years, 2 months ago
I have a favour to ask.

As some of you may have already noticed, I have been trying to simplify the alpha transitions recently. I have something for you to experiment with that is a different approach to the existing techniques that I have used. I feel that the existing method is too complex, and it has the two serious disadvantages that it can't be applied as you would a dissolve or other transition, and it requires the user to manually adjust the routing.

I have come up with a different technique based on difference or delta keying, which seems to be reliable in the tests that I have done. I would like you to try and break it. Feedback would be very much appreciated.

The rules are simple. Add a folded title or an image key to a video layer by placing cuts at the planned start and end of effect. This shows what I mean.


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


Once you have done that, add one of the four effects that are in the zip file in the same way as you would a dissolve. You should end up with something like this timeline, with the routing shown.


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.


That routing looks counter intuitive, but it's caused by the fact that in a standard dissolve the foreground is treated as the "from" source and the background is the "to" source. For that reason if you are doing a transition out of the title the routing will be inverted, and you will also need to tell the transition that it's a transition out. Everything else should work reasonably well on defaults.


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


In the timelines above you will notice that the second title has had two additional effects applied to it. That was one of my attempts to break the transition routing. In that version I had to disconnect the input to the title, because if I didn't the DVE wouldn't work as I wished it to. That was done before I added the transition, and was the only time that I had to touch the routing in the whole test process. The routing after I applied the transition came up like this. It sorted the routing out despite my attempt to break it.


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


To see my examples in action play the MP4, and if you're interested in testing them download the zip. I'd appreciate it.


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




PS: I didn't post this on Github, because I don't want these being included in the master zip file. Until they've been through a little more testing I'm not sure that I will ever release them. It feels too much like I'm getting something for nothing. There has to be a problem somewhere.

Also, this works the same way with the image key effect as with the title effect. I just haven't included that version in my examples.
Last Edit: 2 years, 2 months ago by jwrl.

Re: Documentation for developing Lightworks effects 2 years, 2 months ago #181054

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12931
  • 2 years, 2 months ago
No one interested?

Re: Documentation for developing Lightworks effects 2 years, 2 months ago #181055

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4473
  • 2 years, 2 months ago
Maybe the developer thread is not the ideal place to talk to all users?
I rarely use text in my videos.
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: 2 years, 2 months ago by schrauber.

Re: Documentation for developing Lightworks effects 2 years, 2 months ago #181056

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12931
  • 2 years, 2 months ago
I don't want to talk to all users at this stage. I want people with an interest in effect development who are likely to know how to break them. However you do have a point - perhaps I should post this in the main effects threads. I'll wait a day or so then possibly do that.
Last Edit: 2 years, 2 months ago by jwrl.

Re: Documentation for developing Lightworks effects 2 years, 2 months ago #181291

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4473
  • 2 years, 2 months ago
jwrl wrote:
I think that a structured code library is a good idea...

I called the new repository "Code_for_developing_Lightworks_effects".
I can also rename it if there are better ideas.

In the chapter "Basics" I sorted the summary, similar to the first post of this thread. The introduction and many other things I have only linked to the forum or quoted. I would be glad if you help with the optimization and extension.

On GitHub I suggested jwrl1, khavor, Marcin and Stephan as contributors. Github has probably sent you an e-mail. Who else is interested?

My suggestion: transfer that entire repository to https://github.com/fx-planet.
I do not have this permission.

Other main chapters are currently:
Graphic elements and
Remote control

There is still little in there, but maybe there is already an idea what could become of it.
In the future, other chapters will be added.
The codes have names to facilitate identification. I have used functions for the code because it makes documentation of the parameters and the return value easier. Another use is of course possible.
At the end of some pages I also have variants as a macro, which can be ignored when using the function.
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 2 years, 2 months ago #181292

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12931
  • 2 years, 2 months ago
That's a really good idea. I have some appointments today, but I'll have a look at it perhaps tonight my time or if not tomorrow morning.

Re: Documentation for developing Lightworks effects 2 years, 2 months ago #181320

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12931
  • 2 years, 2 months ago
I've had a very quick look. I don't seem to be able to post there, so I'll comment here. In the "Cross-platform compatibility" section you state:

In the "Techniques" section, use the default code: "... compile PROFILE ..."
or: Starting with Lightworks 14.5, the operating system can be identified. It offers new possibilities.

In my opinion that's misleading. At a quick glance it suggests that you can replace the word PROFILE with the name of the operating system, which is obviously incorrect. It probably would be better to say something along the lines of:

In the "Techniques" section, use the default code: "... compile PROFILE ..."

Starting with Lightworks 14.5 the operating system can be identified at compile time. This allows the profile to be set to explicitly suit the operating system used.

Further down you have the following:

Application of variables into CG standard functions:
Example: lerp (a, b, w); Quote Nvidia's Cg reference manual, page 729:

a and b are either both scalars or both vectors of the same length.

If you do not, then there may be problems on some platforms.

That last sentence would probably be clearer this way:

If you do not there will be cross-platform problems. The way that the Windows compiler and the Mac/Linux compilers handle this type of implicit variable conversion differs and you can get unpredictable results if you rely on it.

The next section about nested comments is also not really correct.

Avoid nested and incomplete comment delimiters.
The following erroneous example contain 3 opening comentar delimiters, but only 2 closing comentar delimiters:
/* Commentary 1 /* Commentary 2 */ /* Commentary 3 */
In Windorws, this will not cause a bug, but on Mac systems.

To be correct and cover all eventualities, try this:

Avoid nested and incomplete comment delimiters.
The following erroneous example contains 3 opening comment delimiters, but only 2 closing comment delimiters:
/* Comment 1 /* Comment 2 */ /* Comment 3 */
In Windows because of a compiler bug this may compile. It will not on Linux or Mac systems. However the following versions will fail on all systems.
/* Comment 1 */ /* Comment 2 */ /* Comment 3
/* Comment 1 */ /* Comment 2 */ Comment 3 */

The next is minor, but at the moment this whole cross-platform article looks very Windows-centric. I think that this would help mitigate that:

Linux and Mac: Only one sampler should be created per texture.

That would be better reworded to something like the following in my opinion:

Only one sampler should be created per texture. While it's possible to overload sampler declarations in Windows it isn't on the other two platforms supported by Lightworks, and doing so will break your effect in them.

The next point I believe could be reworded:

Sampler settings:
The sampler setting Clamp should not be used, because this has different function on Linux / Mac systems than on Windows systems. Starting with Lightworks 14.5, we can instead use ClampToEdge for all operating systems, but not on older versions of Lightworks.

What I believe is the case is this:

The sampler addressing mode Clamp should not be used because this behaves differently on Linux/Mac systems to the way that it does on Windows systems. For Linux/Mac you should use ClampToEdge instead, and starting with Lightworks 14.5 the Windows compiler has been modified so that you can use it there too. This makes that addressing mode fully cross-platform on 14.5 and up.

Obviously this will not work on versions of Lightworks prior to 14.5. For those cases separate Windows versions using Clamp addressing instead of ClampToEdge must be created for the effect to compile.

That's it, except for one general comment. The language used is Cg and not CG.

Anyway, those are suggestions only. Use them or not as you wish.

That's all that I've had the chance to look at so far. Hope it helps.
Last Edit: 2 years, 2 months ago by jwrl.

Re: Documentation for developing Lightworks effects 2 years, 2 months ago #181322

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4473
  • 2 years, 2 months ago
jwrl wrote:
I've had a very quick look. I don't seem to be able to post there, so I'll comment here...

Many Thanks.
Maybe you need to first confirm the email from GitHumb to work together on the repository?
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 2 years, 2 months ago #181340

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4473
  • 2 years, 2 months ago
I have updated the repository according to your suggestions.
Thank you.
Did I miss something, etc.?

I now see your pull request from yesterday.(however closed)
Did you create these in your forked version, and then closed yourself?

I suppose I could have restored the pull requests and merge?
Anyway, this version was 2 hours older than your forum post, so maybe it was better to manually transfer the changes?

So far, I have not found a way to easily update forked repositories, which is why they are quickly outdated. To create your own versions, these are certainly helpful, but working together on a version seems to me forked repositories unsuitable?

Working together in the same repository seems to me the best way,
either edit directly in the master branch or, if necessary, in temporary branches.

Marcin certainly knows more.

If there are problems with accessibility, it would be worth investigating.
If in doubt, just create a new test file and see what happens.
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: 2 years, 2 months ago by schrauber.

Re: Documentation for developing Lightworks effects 2 years, 2 months ago #181353

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12931
  • 2 years, 2 months ago
Please don't merge my pulls, because at least one of them isn't correct. That's partly why I closed them. Forking in our situation is probably not needed, since most effects projects are small and require little maintenance.

Re: Documentation for developing Lightworks effects 2 years, 2 months ago #181357

  • gr00by
  • Pro User
  • OFFLINE
  • Platinum Boarder
  • Posts: 1152
  • 2 years, 2 months ago
Working together in the same repository seems to me the best way,
either edit directly in the master branch or, if necessary, in temporary branches


If you have a team and well known and responsible teammates, it is better to work with one repository and use branches for experiments/bugfixes.

Forks are for people outside the team, which wants to share their ideas/proposals/fixes occasionally.

"Pull request" is a QA tool. You can discuss changes with teammates/maintainer, comment lines of code, make last changes, and finally someone responsible can accept changes. "Pull request" can be created inside repository (before merging a branch) or outside (before merging changes from a forked repository).

For example - schrauber and jwrl are very responsible people, and they're working together. It would be enough for them to work with one repository. On the other side there is a gr00by, a madman with insane concepts. He makes a fork of the repository and rewrites all documentation using SphinxDoc and RST. When he's done he creates a pull request for the main repository, which will be reviewed by suitable people. They can accept it or not. Or they can heal him.
Canon C100 -- Manjaro Linux User
Last Edit: 2 years, 2 months ago by gr00by.

Re: Documentation for developing Lightworks effects 2 years, 2 months ago #181382

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12931
  • 2 years, 2 months ago
I've just posted a feature request about the ability to Minimise groups in user effects. I don't know how likely it would be to get up. What do you guys think?
Time to create page: 0.52 seconds
Scroll To Top