Ok so I had to sacrifice some performance(Using heartbeat wouldn’t work so I had to use wait() 
). But these are the results
comparison.rbxl (42.1 KB)
Results
Roblox is already doing the physics, whether you are listening for touch events or not. Surely having it fire those events is less expensive than also running dozens of raycasts per object every frame.
It almost feels like you are trolling me when you say that raycasting in 3D onto 3D objects is not 3D math but 1D math.
It is possible that an object could miss one of the rays, since it isn’t doing volume collision detection.
That is y u cast multiple rays 
. Also raycasting wouldn’t had been recognized as the best hitbox method by ppl with big names for such a long time without a reason.
My point is that rays are a discrete representation of a moving surface or volume, unlike the math that is going on in the physics engine for the surfaces/volumes.
Here’s the deal probably with weird shapes you’ll need more raycasts, raycats are continous collisions which are usually more expensive then discrere collisions. Discrete collisions is what the roblox physcis engine does.
However .Touched isn’t good for fast moving objects since it introduces the problem of tunneling.While continous collision implementations like raycasting solve this. But the tradeoff is performance.
Underneath the hood the physcis engine is constantly checking for collisions and when a collision is found it fires .Touched event. Even if you connect to it or not those parts are being checked for collisions, so .Touched isn’t less performant because if it was we would be seeing that lag in a game with lots of parts. Collision checks are already running in the backround what is expensive is what you connect when .Touched Happens.
I think the question of why this should be used over RaycastHitbox has still been left unanswered or at least to a detailed degree, after I’ve gone through the thread. I’m just seeing a bunch of back-and-forth but I want to be able to see the points in a condensed post.
Could you explain what significant changes this boasts over that module and why you felt they were better suited as an independent module over having suggested these changes to RaycastHitbox? There is a GitHub repository if you want to contribute and the thread’s replies are also viable for providing feedback and suggestions for improvement, not just for getting help.
Contributing to original source code (in this case, RaycastHitbox) would better help that developer improve on their resource and in turn allow more developers to have access to those improvements and changes if they’re actually necessary.
For reference: I use RaycastHitbox in my game, and want to know if it’s worth changing over to yours and why. I use it and the other developers on the team are familiar with it as well, so it’d be nice to know if the switch is worth and what can be gotten out of it.
Additionally, @Gojinhan, I think you’re confusing overengineering and the like with accessibility and I’m not fully confident you know what you’re talking about, rather finding a reason to pick a bone with big name developers for the sake of doing so. That’s not welcome here.
The Resources category is meant to contain resources that are accessible to developers of all skill levels and the inclusion of the extra materials is to help extensibility and tooling, from novices to power users. Extra configuration methods are not pointless and being modular is absolutely not pointless (so I have zero clue what you’re talking about here).
When you provide more methods and modules, you grant developers more freedom to tailor a resource to suit their needs and to make clear distinctions around in your code. Two examples:
-
MockDataStore contains modules to split up the functionality between a mock GlobalDataStore and a mock OrderedDataStore: those need to be there and should not be amalgamated. They also contain DataStore constants (a large table of values intended to help emulate DataStores in Studio), DataStorePages emulation and other goodies to bring everything together.
-
CameraShaker splits into three modules, one of which helps developers pick presets for how their explosions should look. This saves you time of having to spend hours experimenting with values just to find one you like. The other one is mostly internal. Then the last one is the actual module itself, which is meant for… shaking cameras.
I won’t disagree with you that a big name does not automatically render the developer’s resource efficient, but nine times out of ten they will know what they’re doing. Even then, they often open up contributions so developers can help them improve on their resources. That’s what we should be encouraging on this category: helping build upon things, be it knowledge or free assets.
As for being against “pointless inclusion of other modules” or “useless methods”, I encourage you to get into a serious well-structured project on or off the platform. Most of them will be split up into many different modules, each responsible for tackling a different system or subsystem which are all brought together to form a whole application. Frameworks are literally based on everything being in modules and you absolutely do not want to minimise in that scenario. Things will get lost, readability will be hampered and you won’t have much of a clear grasp on the distinction and division of systems.
I’d also encourage you to read up on the single-responsibility principle which is an actual software development concept. Amalgamating things is an anti-pattern, splitting systems up is good. You can still be wary of performance, negligible or not, while writing a program that supports many methods and modules in it.
More methods and modules could just mean that a developer wants to cater to a larger variety of use cases out there, that they want to show how systems are worked together to establish the system or to make working with it easier. Having more methods and modules has nothing to do with anything: performance doesn’t slow down just because you have more of those, lol. Performance is based on the work that something actually does.
12 Likes
I agree with what you said and I’ll read further into it. One thing I disagree with is this;
I’m not fully confident you know what you’re talking about, rather finding a reason to pick a bone with big name developers for the sake of doing so. That’s not welcome here.
Thats quite presumptuous, I don’t like the way they write their modules but I have nothing personally against them nor is it baseless because it’s just my opinion on how they write them. I’m not sure where you got that from.
Extra configuration methods are not pointless and being modular is absolutely not pointless
Believe it or not a couple hours later after my original reply I learned the other side of the coin and know why people make those “pointless methods”. But once again, I’m not sure where you’re getting some of this from? I don’t hate being modular at all? In my personal projects it’s pretty much entirely modules just being modular. I don’t usually write code that I don’t intend to be modular.
As for being against “pointless inclusion of other modules” or “useless methods”, I encourage you to get into a serious well-structured project on or off the platform. Most of them will be split up into many different modules, each responsible for tackling a different system or subsystem which are all brought together to form a whole application. Frameworks are literally based on everything being in modules
So you bring up that I should go into a personal project to know why people add so many “useless” methods? I’ll admit I’ve never gotten very far into development, the furthest I have gotten is having wrote 80% of the core mechanics for one of my projects. But this seems sort of contradictory, in a personal project you don’t need those extra methods, you don’t need the extra “bloat” that like you said module devs use for ease of use when they post resources. So this makes no sense, in a personal project where I am writing core modules and I know exactly how and when they will be used, why would I add more? I understand why I would add “bloat” if I were making some sort of hitbox module, that would make sense because the result and functionality wouldn’t be consistent, but you’re talking about modules in general.
Having more methods and modules has nothing to do with anything: performance doesn’t slow down just because you have more of those, lol. Performance is based on the work that something actually does.
It’s not always about performance. And when I evaluate modules, it usually isn’t, what you said is true; performance does not slow down just because you have bloat. it’s dependent on the work it does, however I follow my own personal principle, if I will never need it; I will never have it. saves memory and potential processing that could have gone into the main work. (e.g calling a bloat function)
Overall good argument, I learned some things I didn’t know; but i think you’re assuming a little more about me than you know.
I tested both modules which can be seen in this message.
Btw, I’m starting and stopping the hitbox via HitStart and HitStop with Raycast Hitbox and my versions of them, not creating a new hitbox every frame(that would leak to memory leak xdd).
I appreciate the reply, but that’s almost exclusively against what I’ve posted. I’m not just interested in the performance of your module, I’m interested in what significant benefits this provides in contrast to RaycastHitbox and whether making a switch is worth it.
What else does your module support in the way of API and such that RaycastHitbox doesn’t? Could you please read the post again and answer beyond comparing performance? It’s not really that critical for me, but I’d like to know if the same use cases are supported.
There isn’t a lot of benefit from using my module other than code shortness and performance unfortunately(which would be one of if not the only reason I’d switch modules). I’m pretty sure my module can do anything that raycast hitbox can(excluding debug rays ill make them eventually).I appreciate that u appreciated my reply 
.
1 Like
Hey, I really like how simplified HitboxCaster is and I’m glad you found the inspiration to try and improve my module with your own interpretations. Even if the low chance that you weren’t inspired by my own module, I hope it can still be a resource to you to improve your own and make HitboxCaster your own identity with its own unique features that every developer can enjoy.
I’m sure there is still going to be questions and comparisons between our modules from curious onlookers, so let’s end that today. To add to @0Shank 's request for fair comparisons, I have compiled a list of benchmarks comparing both modules in similar environments for readers.
I do have to preface that HitboxCaster currently has a glaring inaccuracy bug that I’m unsure is intentional. Before we get to the benchmarks, HitboxCaster seems to be detecting hits even when the attachment points are nowhere near the designated subject. Video footage can be seen below. The code was used from the original thread post (and comparison place). Regardless, even if this bug was fixed, the performance data should still be relatively the same.
(the one being moved is using HitboxCaster)
Open Me For Benchmarks
For these benchmarks, I have used the most recent versions of both RaycastHitbox and HitboxCaster for the best accurate data possible. HitboxCaster seems to be listening for each part hit so I will be enabling RaycastHitbox’s PartMode to reflect the similar functionality. Each benchmark will have its own .rbxl file. My computer is running a Ryzen 3700x, 1070 TI so there should be no performance skewing due to studio.
Benchmark 1: @MLGQuickSkopur’s Test
See Results
I dislike this test specifically because it’s a bit misleading. No developers will realistically enable / disable the hitbox within a frame of each other constantly. That is not how the module is supposed to be used and should be discouraged. However, for the sake of comparisons and to end the misconceptions that RaycastHitbox module utilizes more script activity, I will be utilizing the same tests as your earlier comparisons.
From the comparisons, it seems that both RaycastHitbox and HitboxCaster share the same script activity, and any differences can be seen as negligible.
benchmark1.rbxl (41.6 KB)
Benchmark 2: The Accuracy Check
See Results
As a game owner that has AIs in the dozens at one time, it is an absolute requirement for me to have the module be able to smoothly detect a large number of humanoids. I will be tweening this part with 30 DmgPoints through 50 humanoids.
HitboxCaster Test
RaycastHitbox Test
Tweening through 50 AIs in 2 seconds allowed both modules to get all targets. However, tweening faster than that, HitboxCaster will have an accuracy advantage as it detects more targets than RaycastHitbox. Do note that, since HitboxCaster still has that inaccuracy bug listed above, take this benchmark with a grain of salt.
benchmark2.rbxl (52.1 KB)
Benchmark 3: The 350 Attachments Check
See Results
Raycasts are light and performant, and our modules should be made to reflect that quality. I will be reusing the test and code from Benchmark 1 for this one.
HitboxCaster Test
RaycastHitbox Test
From the tests, RaycastHitbox did not seem to drop any frames while HitboxCaster capped the micro profiler, dropping frames. This is a good example that you should not rely entirely on HitStart/HitStop performance and that using real-world benchmarks can go a long way to prove your point.
benchmark3.rbxl (41.9 KB)
Overall, I hope you can keep improving on this module as I know a lot of developers do value smaller resources. Many developers dislike RaycastHitbox for the same reasons and HitboxCaster seems like it would be a great alternative for those people. Keep it up, and if you need any pointers, I’ll be more than happy to give a few tips or suggestions.
8 Likes
Thank you so much for the feedback, I didn’t think you’d be talking about my module. I’ll make sure it gets better.
1 Like
Hey, can I get an update when the inaccuracy bug will be fixed?
Before I use this, I want to ask one question, would this be a good module to use when making an fps game? I’m probably gonna use this for the projectiles, but I wanna know if it’ll be a good design choice.
I don’t recommend using stuff like these for projectiles, projectiles are usually more lightweight and require lots of them being made in seconds. Using attachments in projectiles get’s memory-hungry, hitboxes are only ideal for things that will last long, such as swords.
Projectiles have a very short lifespan, what I recommend for projectiles is updating the projectile manually via CFrame and casting a ray to the next point, or using fast cast which does this for you.
1 Like
I think I’m better off staying with RaycastHitbox.
Try using the latest version and check if it’s inaccurate or not.
The performance benefit of this now seems useless because of a fairly recent update to Raycast Hitbox.
Can you make a tutorial on HitboxCaster? Because I have no idea what I’m looking at but I’m interested
That would be possibly except I’d like to focus on revamping the code beforehand.