Electric Arc Demo with RBXLs

The attached RBXL files are the geometry-based electric arc effect that I’m using in my Electrical Lab place, and a crudely hacked version of the same file for the purpose of adding some extra visualization of how it works (hard-coded to one arc and a specific world orientation, because no point spending time generalizing it). Conceptually, the way this works is that the arc path is modeled as a set of rotated vectors perpendicular to the axis (red in the screenshot), semi-randomly spaced and with length that is random but also subject to an “envelope” that describes the outer bounds of the path. What limits keeps the arc from zig-zagging too severely to look natural is a limit on how much each of the red vectors can rotate about the axis relative to the previous one, along with limits as to how closely spaced they can be. The long, hot arcs that wander a bit are achieved by generating two paths, and tweening from one to the other over several steps (lerp).

I spent a few hours today ripping out my initial Lua implementation which did everything in world coordinates with all the transforms in Lua, in favor of letting CFrames do all of the heavy lifting. So now all the arc generation is done neatly relative to an x-axis unit vector, and then transformed into world position by scaling and CFrame multiplication at the end. I am new to Roblox and Lua, so there are probably still things that can be further optimized. But, my baseline tests indicate that animating with tons of parts like this is expensive, even with the objects in a pool and everything in local scripts. Still, it could be useful for making discrete lightning strikes even if the continuous multi-arc version is too much.

ElectricArc.rbxl (19.4 KB) Updated to run on heartbeat event
ElectricArcIllustration.rbxl (20.6 KB)


Maybe a tip: since this effect is not dependent on the camera or anything, you can consider running it on Heartbeat rather than RenderStepped. It just needs to update every frame, it doesn’t need to hold back the rendering pipeline to update it, it can do it in parallel for the next frame while the current one renders.

This puts me back at a stable 60fps when I toggle it to Heartbeat, at least.

Cool effect and really nice that you explain how you implemented it.


That’s really cool! Thank you!

Btw, are we allowed to share this to someone else or is it for members only? If it isn’t, have you uploaded it as a model already?

Cool. I tried both and couldn’t figure out the what the difference was (or see any difference), but if heartbeat is where calculation intensive stuff belongs, this makes sense to connect it to that instead.

1 Like

I will make it a model after I respond to suggestions I get here and tune it a bit more. I don’t intend to publicly share/host it as the rbxl, but if you want to send it to someone personally who’s interested, that’s totally fine by me.

1 Like

So, about packaging this up as a free model… what’s the best way to distribute a model that has a LocalScript? Ideally, I would want the model to be able to be added to the Workspace scene from the Toolbox, as usual, and just have it work, rather than need to be put into ReplicatedFirst or one of the starter folders prior to publishing. But, LocalScripts don’t appear to work the way I expected: I thought I would be able to add a LocalScript to a model and it would just run on everyone’s clients locally without replicating its behavior on the server. But the LocalScripts don’t run at all. I’m guessing this is intentional, perhaps to avoid people inadvertently coding up a whole game with LocalScripts that works in solo play but results in completely out-of-sync parallel worlds once deployed?

Is there a clever workaround to make a model with a LocalScript that works right from the Workplace without a manual step of moving it prior to publishing?

I also need to rip out the FoV part of my camera direction animation pausing, since it was a special case for my world and does not work if you walk right up to the arcs (you’ll see the animation pause if either of the arc endpoints goes out of view of the camera).

Why do you expect this to be an insert and forget script? I would think developers would prefer using it as an API to create controlled arcs. In this case, publishing as a module with maybe a demo model+script which parents the local script itself would be appropriate.

1 Like

I’m not that much into scripting so I may be wrong right now, but can you write in the script that the LocalScript be moved where it should be? Or clone it?

The endorsed assets all do this with an FE bypass for ClickDetectors.

1 Like

What? This sounds like something i should know.

When I press play and then in explorer expand the model in the camera, it starts lagging intensely, even after collapsing everything. Sounds like a studio bug.

I’ve observed this also. I suspect it’s related to updating the properties pane.

Explorer updates usually cause lag when a lot of stuff is being reparented.

This is my lightning effect:

It doesn’t lag. It uses a modified version of Trey’s particles. They are GUIs so unfortunately they can’t have neon applied to them.

LightningEffect v1.rbxl (16.8 KB)