Видео

Wow that's really good to know ! Thanks for the insights Yes even with my very basic implementation it was much faster so I guess it might work great with your approach ! Are you planning to release what you made publicly ?

@@AdrianPokojny no, I think it makes no sense to release a generalized Godot-Bepu bridge because of the way Bepu is designed. It makes much more sense to create a new custom integration for every project that needs this level of performance. Bepu is a high-performance low-level physics engine afterall, using manual memory management and unusual paragidms for C#. Making it compatible with the Godot API for the sake of ease of use would throw its biggest advantages out of the window.

How do you use this thing, have you an tutorial on installing?

@@user-ub4hw4zo8s - add bepuphysics2 as dependency, NuGet should work out of the box - create the physics simulation and step through it in _physics_process - sync back the physics simulation results to Godot

Yes the comment described it nicely, this solution must give better performance. I'm not in charge for the visual side but we tested it on older hardware and didn't have any issue, it runs smoothly as Unreal Engine disable raytracing automatically if the hardware isn't compatible. Also baking lights doesn't solve the artifact sadly, might be because the light is really huge and a matter of distance and way too high attenuation range

I'm not the one working on the visual part, but I get your point and agree that it must be the best in terms of performance, the nice part about having this big spot light is the volumetric fog effect and light seen from distant which plays a big role in the game mood, but if it's possible to display light and shadows in some kind of 3D mask we could get the same with directional light and low quality spot lights

You're welcome ! It has a slight impact on the performance, also we tried a build on older computer and Unreal Engine automatically detect the hardware and disable raytracing in case it's not supported, it's good cos at least the build is working smoothly on every computer, but it means that the glitchy effect come back on older computer as well, as Unreal disable those settings So I guess that's why it's not enabled by default because it doesn't work on every hardware

Agreed. Would love to see a comparison of C++ and C# used in Godot. And see what is faster during runtime. Seen such a comparison of Blueprints and C++ in Unreal. C++ proved to be much faster. When it comes to making games, runtime speed is important, not only to hit good frame-rates, but for stability also. Seen the difference years ago, between what is know of as Dark Basic Pro, and Dark GDK. Dark GDK is a C++ SDK version of Dark Basic Pro. And it runs way better, but is also more complex to use.

C# performance in Godot are way slower, so bepuphysics is definitly not running at it's full potential. Godot seems to plan C# integration as GDExtension which should make it way faster, we'll see. Otherwise GDScript is slower than C# for math calculation, currently the best is to use C++ with Godot. I think I won't experiment more with godot + bepuphysics until there's an update on C# integration in the engine

@SomeRandomPiggo Yeah but the result is impressive !! maybe the author didn't want to bother with memory management ?

@@AdrianPokojny You're right, I only said that because it seems performance focused

​@@AdrianPokojny This is not true at all, C# is only slightly slower than C++ or other systems languages, and bepu is already using a bunch of operations that are turned as efficient assembly by the JIT, particularly it makes heavy use of the System.Numerics and vectorized operations. You would probably not gain much more speed by converting the code, and the gains would probably would be much more by the game architecture on itself than the language.

Yes this physics engine deserves way more credits ! I tried it locally and it's so smooth, give a look at the demo video it's impressive ! ruclips.net/video/tjtwSq3u6Dg/видео.html