RbxShader: A robust shader engine, for everyone

Resources Community Resources
21

I don’t think this is possible.

1 Like
22

dang, roblox should really add that. Though i do remember seeing a comment where someone mentioned being able to use Viewport frames as buffers. Anyhow im going to try this shader engine, i hope it not too laggy on my pc :<

2 Likes
23

v1.8.5 has been released…

and some changes introduced are not backwards-compatible, meaning you can’t just plug this version of the engine, and expect everything to run without errors, so read the update log thoroughly.

Before this, another version (v1.5.3) got released though I couldn’t be bothered to announce the changes here. If you want to read the changes done in that version, you can do so by following this link. This version is backwards-compatible.

Notice

Yes, the usage of Ethanthegrand14’s CanvasDraw has been dropped in favor of a more minimal canvas API, which is specially built for the use case of this engine. The reason for this is simply because a lot of CanvasDraw’s features simply aren’t used, indirectly becoming bloatware.

Repository Changes (Can be skipped)

  • Updated README.md to be more informative of changes.

  • Changed default.project.json to be the project file that contains the demo, and the project file for the package has now been renamed to package.project.json.

  • The engine has now matured enough to be published as a package, therefore wally* files have been made.

  • CHANGES.md has been made to keep track of all the changes since last release.

General Changes

  • Optimized local function IsAVector4() at the Vector4 library.

  • Cleaned up and updated some types at Common.luau.

  • Added OriginOffset as an engine configuration. It is a unit Vector2 that describes where on the screen is the origin point. Its default value is (0, 1), bottom-left in other words (this is an OpenGL convention).

  • Added CountDirection as an engine configuration. It is a unit Vector2 that describes where the pixel coordinate counts upwards to. If X is positive, then the X counts upwards towards the right-side, and vice-versa. If ‘Y’ is positive, then the ‘Y’ counts upwards towards the bottom of the screen, and vice-versa.

  • The aforementioned configurations are meant to resolve OpenGL shader port compatability issues when it came to pixel mapping, which I discovered and faced while adding the four new shader examples.

  • Added four new shader examples, namely:
    Plasma by @Xor,
    ZippyZaps by @SnoopethDuckDuck,
    ShootingStars by @Xor,
    and Currents by @s23b.

  • Re-ordered the parameters of the Shader constructor to represent its priorities better.

At Canvas.luau

  • Refined type definitions.

  • Redefined Canvas constructor to be a pure constructor. To set the initial color and alpha content of the canvas, the new :Fill() method should be used.

  • Fragment coordinate can now be cached onto the canvases. Since fragment coordinates assigned to the pixels of a canvas don’t change over time, we can calculate them all at once, and fetch them whenever they’re needed during operations. As a consequence, two new methods have been introduced, :RecalculateVirtualPixelMapping() and :GetVirtualPosition().

At Worker.client.luau

  • Changed comment stylization, section-marking comments are not denoted with # at the beginning.

  • Proper type references to Common.luau are finally possible and have been made. This is all thanks to the aformentioned project file JSON restructuring.

  • Fixed an embarassing oversight with the implementation of shader buffers, meaning it never worked in the first place. How TF did I do that?

  • PerFrame variable has been renamed to Renderer, as it fit the use more.

  • Renamed action Initialize to SetContext, as the action is meant to set the environment context that the worker threads act for.

  • Reorganized the parameters of actions SetContext and MakeCanvas to purely represent their action names. These changes obviously cascade to whose responsible for what variable/function.

  • Reorganized RunProgram()'s internal logic.

At init.luau

  • iMouse SharedTable and culler references are now properly garbage collected when shaders are cleared via :Clear()

  • Optimized the disconnection of the Mouse.Move connection by reusing the responsible function.

  • Calling for the action SetContext to all workers is now done first before the MakeCanvas action.

3 Likes
24

Thank you for actually spending your time and updating this shader engine. I’ve made my own fork of engine when it became non-compatible with EditableImage updates a while ago and it was actually very very slow, unlike v1.8.5, ty. Might use this engine when will be making actual game (for cool stuff like loading screens)

Here’s my old fork VS v1.8.5 comparison



(had to downscale 2nd one, because it was 400 kilobytes above limit)

1 Like
25

is that balatro’s background?

chars chars chars

1 Like
26

of course. you can check it out here → Shaders Test V2 - Roblox

1 Like
27

Holy smokes, this is so cool… I play tested it out for myself, and was surprised to see it run so smoothly on my device (which is considered low-end by 2025 standards) despite being displayed at such a high resolution and a low interlacing factor.

I usually test RbxShader in-studio, with a resolution and interlacing factor exact to that from the examples at the main post; and even then framerates rarely get to up to 60. Is it usually better to run tests in-client rather than in-studio? Or was it some crazy good custom optimization with the engine / shader program? Or both? :thinking:

Anyways, I’m really glad to see that there really are people using this resource; more so, making awesome stuff with it!

You’re welcome! I really appreciate you taking the time to say that. :blush: I’m always working to make it better, so hearing things like this mean a lot.

Oh, BTW, a new release might be out soon, which unfortunately will not be backwards-compatible again due to file restructurings, etc. Thank you for your patience and continued support as the project develops. :slightly_smiling_face:

1 Like
28

Thank you for checking it out!! :smiling_face:
Studio definitely eats up some performance (like 10-20%), so I test shaders on client.
I’ve just heavily optimized shader (just by baking some magic numbers (unsure if !native already does that)) and used unmodified v1.8.5 RbxShader.

Here’s place file:
Shaders Test V2.rbxl (125.6 KB)
Some shaders under client script are not finished since January, so they might look bad if you try them. (also note that balatro shader was written in January too, and some custom functions it uses might’ve been added to GraphicsMathLib after it was written :stuck_out_tongue_winking_eye:)

edit: also my fork of RbxShader is inside ServerStorage and is called RbxShaderOld

2 Likes