[SUGGEST]Manage shader's source with ES6 standard method. about filters HOT 7 CLOSED

The unfortunate part about this is that all other tooling related to writing these shaders breaks (syntax highlighting, compilation checking, etc).

from filters.

@finscn's approach is useful if you need to compose multiple fragments. It can help reduce common code and to create better maintainability and encapsulation of functionality. The tradeoff, like @englercj is that it makes the shaders less friendly with outside tools.

Since we don't have a big need to compose multiple fragments (other than maybe Godray #40), there isn't really a big need to convert .frag files to JS modules for the purpose of templating. And the common code eliminated is so small, the tradeoff doesn't seem worth it.

Interesting approach, but not the right choice for pixi-filters.

from filters.

@bigtimebuddy @englercj , I think we could Create a tool to convert the pure .frag / .vert files to js file .frag.js / .vert.js.

And import the .frag.js and .vert.js in filter js.

when build pixi , run the convert tool first , then do ES6 compile.

the convert tool fetch all .frag and .vert files that start with // convert-js (just a flag) , then add

export default ` 

and

`;

to the files , then create new files .frag.js and .vert.js.

The files don't start with // convert-js won't be converted.

And I think we can add this feature to pixify , the gulp script could do the work.

from filters.

@finscn, you are proposing more complexity for little reward. Introducing a lot of hidden magic into the build process is not a big win.

What problem are you trying to solve? If you want to chop a bunch of small files into even smaller files so that you can reuse single lines (e.g., varying vec2 vTextureCoord;), that's not worth the effort. If your goal is to compose fragments, doing a simple JS string replace with a token will do the same thing without a lot of custom build operations or plugins.

I agree with you that glslify or babel-plugin-static-fs are not great solutions for PixiJS. But Rollup allows us to easily import non-JS as strings and has lots of benefits over Browserify and works with Webpack and browsers.

from filters.

I don't want to solve any problem.
I just love standard ES script.
So I don't like that there are some non-ES-feature in pixi's JS file.

When will you use Rollup for pixi.js ? Is there a roadmap or plan ?

from filters.

As soon as @GoodBoyDigital finishes merging dev into next then I'm going to start implementing Rollup and Lerna for v5. I'm hoping sometime in the next few weeks.

from filters.

Waiting that pixi.js uses Rollup and Lerna.

from filters.