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.
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.
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.
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.
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.
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?
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.
