Update: My afterimage works almost perfectly now thanks to the newest update, but I get this type error in the output during runtime.
It leads to this line.
I’ve had the “Unable to cast Vector3 to float” error happen a bit while working on V1.0.4 and I believe I know how to fix it but it might be a little bit before I can work on the fix.
As for the CFrame property - I’m not sure what you mean, do you mean like a method to get the CFrame of the particles?
Hi, I mean being able to use a CFrame instead of a Vector3 for Rotation.
I could add that feature pretty soon. Shouldn’t be too difficult.
Seems promising, are there any videos showcasing it? I’d test it by myself if i was at home, but I’m not right now.
There used to be videos but not now, all the videos were in the documentation but with the more properties I added the more videos I had to make, and environments were difficult to replicate so nearly every video looked different and it just looked like media slop.
I can make some videos showcasing performance and more, but don’t expect multiple coming after.
In the mean time the best video’s you’ll get are in the post itself (expand the drop down menu here
umm, why not have an editable game, that shows the examples from your docs of templates?
I’ve been working on an editable test demo place for a while but I’ve been caught up with life and other real world stuff.
I’m consistently working on one same with a plugin for creating emitters.
Hi,
Ok, … and editable place would be nice to check out whatever features it might demo.
Thanks
Like I said I’m consistently making progress on an editable demo place, there are many properties and smaller systems to make sure people on lower end devices can still see and experience the VortexFX systems even without intention of copying the game.
As of right now your best bet is to go to the documentation, that walks you through how to use VortexFX by hand-holding and making sure you can get through making particles.
I second this, having a place to showcase the capabilities of the system would benefit me greatly. I’m on the edge as to if I should use this in my projects, a full demo would be fantastic to help me test the limits of the system.
I’m aware you’re making progress on this, figured I would check in on it.
can the collision detection have a variable that then does damage?
Thanks
This doesn’t work out of the box. Line 1574 of V1.06 will literally always error, the :Kill() method calls a ‘Dispose’ method of the ObjectCache module that doesn’t actually exist, and the module currently does not destroy any parts that exceed their lifetime automatically, even if Kill() is called (this does successfully destroy the parts in the cache, but not the parts in the particle folder).
Ah, I must have forgotton to switch the Dispose with the new cache I use, before I used PartCache which did have a Dispose function, I will release a patch as soon as I can, as well as a fix for the other errors.
So i thought i would see if that is really true. As a creator of Collideable Particles Module i decided to see both positive things about your and my module, and also the negatives of them.
First i thought of benchmarking both.
So, for the benchmarks i tried to make the particles behave as close as it was possible to eachother. While doing the benchmarks, any performance options could be enabled, only if it didn’t degrade the quality or looks. So options like frustum culling or DistanceThrottling could be enabled (DistanceThrottling had to be adjusted to not be too much visible).
Benchmarks:
(Collisions Enabled)
VortexFX - 50 FPS (700 particles)
Collideable Particles Module - 90 FPS (6600 particles)
VortexFX
(Without Collisions)
VortexFX - 30FPS (2000 particles)
Collideable Particles Module - (17 000 particles) 55FPS when steady, 40FPS when moving camera, 35FPS when all particles are visible
VortexFX
Ok, it probably now looks like it’s rigged, but remember, that i used techniques like frustum culling, distanceThrottling and Parallel Processing not available in VortexFX. Which greatly help with performance. Even i was shocked that the difference is so big. (Also remember that i could have messed up while setting the VortexFX properties, as it could probably add to the lag.). Tho in tests where there are many particles next to each other instead of spread out in large distances the max of particles my module can simulate without lag is about 3 thousands.
But hear me out, it doesn’t mean that my module is better. While my Module is Faster, his module is way easier to use.
His module can change transparency, color, material, rotation, flipbooks of particles
And my module can change… only position???
Ok, maybe that’s not entirely true, as my module can indeed change those, but it is not as easy as just changing a property in VortexFX.
You need to make your own script for changing all of these in my Module. Want to change Color of particle? Script it. You want to chage material of the particle? Script it.
While in VortexFX all you have to do is just change a single property. Want the particle to react to audio? Simple, just change a property. You want it to Emit light? Again simple, just change a property.
And while it might seem like: “Well, it is probably more worth it to get a module that is harder as it gives you more FPS”, it’s not as easy as it sounds, as my module uses Parallel Processing, some users had problems like trying to play a sound when a particle collided, but couldn’t do it because it was in parallel state so it errored. Or making the player take damage on collision, but again, it was running in parallel state so it also errored. There are of course workarounds for this, but most of the users didn’t even know what parallel luau is.
Ok. So let’s Summarize this:
My module is faster and uses various optimization techniques, particles can collide with eachother instead only with the world, but it is also harder to use. Setting up particles may take more time. Requires more workarounds. It is also centered more on collisions.
VortexFX is more artist friendly. It has a many many properties, each doing it’s own thing. Very highly customizable, beginner friendly. It is also centered more on the Artistic Vision.
So if you are not going to be simulating crazy amounts of Particles, VortexFX might be a better choice.
I will probably recommend VortexFX under my post so people can pick which one is a better option for them.
Remember that this is not a Rivarly. I am kinda curious what will VortexFX look like in future.
Also if the Benchmarks are wrong, please correct me.
Also i will probably make more benchmarks later, as the only benchmark is for snow, while the VortexFX might be slightly faster in other cases.
This is a great benchmark, I really enjoy how you’ve actually spent the time to test the module to it’s fullest extent.
While I agree that VortexFX definitely isn’t as optimized as I’d like it to be nor as optimized as Collideable Particles Module, every update I try and optimize something that wasn’t before, like all good things, VortexFX will get better with age and updates.
Also, if you want I’d really like to see if we can message on Discord or some other platform, I’d really like to see if you have any ideas for getting VortexFX to it’s most optimized state.
If you want you can, go ahead and friend me at “distinguished_duccer” if you’d like.
Maybe i’ll add you later. But for now, first thing that you should do to make it more performant is using the BulkMoveTo function on workspace, as it makes updating the visual positions faster. You basically put all the referenceObjects of particles to the list, and their position that they whould be in. It makes it around 1.5x-2x faster.
