Crazycarpet

I get what you're saying, but the two physics libraries are very similar in how you implement them, switching the system out would be a rather simple process. Plus I would assume Josh uses some kind of higher level wrapper for the physics APIs that is used in both Turbo and Leadwerks. Changing one would like be nearly as simple as a copy and paste to the other with some minor changes. (That is a guess, I don't know how Turbo's physics were done.) If Newton does the job I'd say leave it... but it seems like it's causing headaches which with all the robust, free physics APIs out there these days there is no reason to go with a under-featured and under-documented one.

I've been using Bullet in a lot of projects lately, it's really come a long way in the last couple of years. Very fast, more than accurate enough, fully-featured (unlike Newton), and open source... The documentation is also decent, especially stacked up beside Newtons. If you are planning to switch I'd imagine Bullet would be a pretty quick and painless switch. PhysX is good too but honestly, I prefer Bullet it has more options. Performance wise it leaves Newton in the dust, the only downside is the rigid body simulations may not be quite as stable but I'm sure they're more than good enough for Leadwerks' needs. Multi-threading physics simulations with Bullet is also very easy and the source code comes with tons of examples.

This is really impressive Josh, can't wait for the release. However still I feel like the instanced rendering is carrying here I'd love to see how much faster LE5 handles animated meshes than LE4. Perhaps a demo of this in the future? Also, I thought you said LE4 has frustum culling when I was complaining about GPU occlusion culling?

The reason you'd want to multithread the command process is for situations where big, new, powerful GPUs are bored because the CPU's one thread can't send it commands fast enough to utilize it to the fullest extent. That's not a fair analogy so long as your GPU can handle it, why would you not want to throw more work at it? Modern GPUs (10 series, etc) can certainly handle it. A great GPU can handle anything a single core on your CPU can throw at it with ease, so you want to throw more at it. This is the most common bottleneck in games these days with how powerful GPUs are getting. The better your GPU, the better these optimizations will help, it's more planning for the future because as time goes on you'll see more and more improvements from this type of multi-threading, that's why DX12 and Vulkan moved towards it. Anyways like I said, it isn't usually necessary but it would be optimum, just food for thought so you consider this design if you move towards a Vulkan renderer. It'd be a shame to use Vulkan and just move all the rendering to a thread, instead of using all available threads for command buffer generation.

Again, Doom doesn't do multi-threading... Why would it be faster than it's OpenGL renderer? They've had years to optimize OpenGL drivers, of course it'll be at least as fast in a single-threaded environment. It's not magic, it's physics at that point.... Vulkan can use multiple threads to generate command buffers, more at a time; OpenGL can only do 1 at a time. It would indisputably be faster that's just the reality of it. As time goes on and GPUs get more powerful a renderer in Vulkan that generates cmd buffers on multiple threads would be even faster because not only are you sending more work to the GPU due to the threaded command buffer generation, but the GPU would also be able to handle any work you throw at it. With high end cards today you will see big performance gains, where you wouldn't is with integrated cards... but that shouldn't be a priority. Furthermore in Vulkan you can physically send draw calls from multiple threads and they are not send to the main thread by the driver, this is one highlight of Vulkan that only DirectX 12 has. Metal is planning this too, I have not read whether or not this is already the case in Metal, of if it's just a future plan.

Doom doesn't use a multi-threaded renderer. Of course Vulkan isn't going to magically make things faster on it's own, it gives you the ability to do it... On OpenGL you don't directly write to command buffers so you can't split the work up between threads. Vulkan in itself does not do anything multi-threading, this is something you have to implement. Vulkan just gives you the tools to design fast multi-threaded designs that were not possible prior to. I'm not saying this is necessary, your design will be great because the game loop does not have to wait for the renderer. I'm just saying with Vulkan you could get maximum performance, you could still keep the rendering separate of the game loop too then you would end up with both faster and independent rendering. Just spit-balling ideas because it sounds like you're trying to make LE as fast as possible, and this new API allows you to do what only DX12 could do without worrying about being locked to windows-only. This optimization would indisputably make LE's renderer way faster, which is perfect for VR. The only question is whether or not it is necessary, is LE fast enough without it in the situations it's designed for? No sense in writing a big complex renderer if the engine is fast enough as is. Edit: Also keep in mind that Nvidia's OpenGL drivers are extremely fast and complex, AMDs are not. On AMD cards Vulkan does "magically" make things faster just by implementing it because their driver team went above-and-beyond on their Vulkan drivers.

The benefit to the multi-threaded APIs is that every thread has it's own command pool, and each thread can write to a command buffer so you can use any available threads to write to the command buffers. They are in the end submitted together, yes, but getting to the point where all command buffers are good-to-go is way faster. That's why they designed them this way. In the end, less time is spent waiting for 1 CPU thread to write all the command buffers. Nvidia has a great document about this: https://developer.nvidia.com/sites/default/files/akamai/gameworks/blog/munich/mschott_vulkan_multi_threading.pdf

Very cool, but this is still more rendering separately on a thread than multi-threaded rendering. No matter how you cut it in GL the heavy work can't be spread across multiple threads so your GPU is always bored waiting for the under-used CPU to send it work, although in GL this is as good as it's going to get which is good enough. Still like your MoltenVK idea the best. Either way it is neat to be able to control the frame rate of physics and game logic separately of rendering.

Can't wait to see what the future holds for Leadwerks. You will be able to make way better use of the CPU's threads with Vulkan so that'll be fun (if it happens). Don't forget to always use RenderDoc when you're changing up the renderer. Best tool ever made, I swear... although I'm sure you've used it already

That sounds like a perfect solution. You shouldn't have to do much for smart pointers to work with ToLua++, they are simply a class. I'd be surprised if ToLua++ couldn't handle them out of box. (Assuming you don't have the std:: prefix in the pkg files.) http://lua-l.lua.narkive.com/JEUvLxvs/tolua-question Looks like it'd be quite easy to come up with a solution.

Yeah, but it doesn't have nil... so if you do something like access an out-of-range table element, instead of returning nil it will raise an exception... having nil is also what I rely on for my Lua callback system in my engine (although null might be distinguishable from false on the stack in Squirrel too). Squirrel looks like its come a long way since I last saw it, so I take back what i said. I'd go with Squirrel over Python. Still though, that's a big change for not a big difference. Not to mention I'm not seeing it being any easier for an auto-complete feature than Lua? You won't be creating your C++ classes in Squirrel, you'll be exposing them with t he stack, so it's not like you can parse the code files for auto-completion. If a switch has to be done thought Squirrel looks sweet.

If you're going Squirrel, you're better off with Python... why settle for Squirrel when it's a worse version of the same thing? (Granted it is more light-weight) I think the Squirrel syntax is ugly relative to Lua or Python. I just personally love Lua because it is really, really fast and communication with C is extremely easy. It seems unnecessary to change something like the languages scripting language solely for the autocomplete feature. Plus could you not do a hack where you just execute the Lua file, silently ignoring errors all the time and then generate auto-complete info based on object's metatable which contains all t's methods and members. I feel like you could find a sloppy way to make this work using a separate Lua state... might not be the easiest solution, but likely easier than changing languages entirely.

That would actually be really great to beable to draw widgets on the editor... maybe leave a little blank space for em Although I feel like this can be done regardless so long as the Editor uses LE's UI/Window system. Or if the widget sidebar was a scrollable panel, and you could add elements to it?

Clickbait at its finest.

" Leadwerks 5 is designed to be the most advanced game engine in the world " LE4 is a great engine, but I mean come on.