[Terrain Building API in Leadwerks 5 Beta]

Objects are separated into static and dynamic. When a dynamic object moves only the dynamic objects gets recalculated. The static data stays the same.

Shadow maps work with the same principle, so this is actually convenient because static objects can be marked as such for both purposes.

[How to Fix Slow Windows 10 (this week)]

In VS, you also need to go to Help > Send Feedback > Settings and disable feedback. This really grinds your hard drive up.

[Terrain Building API in Leadwerks 5 Beta]

1 hour ago, Marcousik said:

And what about Navmesh ? This should be updated too, the problem was regarding performances on bigger maps....

A static cache will be used for the terrain and other static objects, instead of reprocessing everything every time something changes.

[Terrain Building API in Leadwerks 5 Beta]

Yes, you can manipulate the terrain in real-time with no problems. Collision and everything will work just fine.

[Animation speed in Vulkan vs. OpenGL]

Actually I have found the bottleneck is in the data sent to the GPU. I added some tricks and now 1024 goblines are running at 450 FPS on my laptop, a bit faster than the original OpenGL version, even though everything is being drawn twice in the Vulkan renderer for the depth pre-pass.

I am satisifed.

[Animation speed in Vulkan vs. OpenGL]

If I use shared animations so that less data is being uploaded to the GPU each frame, I get 400 FPS in the Vulkan renderer.

[Animation speed in Vulkan vs. OpenGL]

The engine will now allocate threads for animation based on how many skeletons there are and the total processing time for the last frame. It will attempt to allocate as many threads as are needed to keep the total processing time down within 60 FPS.

 

[Animation speed in Vulkan vs. OpenGL]

I ran the test using the goblin model. On this machine 1024 uniquely animated goblins onscreen runs at 200 FPS. With the old renderer it runs at 380 FPS, but it's not exactly an even comparison. The Vulkan renderer is doing a depth-prepass, so all skinned vertices are actually being rendered twice, once for the prepass and once for the final pass.

If all things were the same, I am sure the VK renderer would be going faster. So we are within the same range as my original tests, and now we have full lighting, normal mapping, and other stuff being processed.

[Animation speed in Vulkan vs. OpenGL]

42 minutes ago, Ma-Shell said:

What happened to 

where you claimed 200 fps for 10000 characters? Was that all shared skeletons?

I believe the bottleneck in this situation is actually polygons rendered. I previously chose the goblin model because it was low poly, so I should do some more tests using that model instead of the 4000 poly crawler model.

[Skinned Animation in Vulkan]

19 hours ago, Genebris said:

I feel like this was already discussed but I forgot. Can you still move bones in script? How can you do procedural animation if bones aren't entities?

They still have a position and rotation, they just don’t have all the extra features of the entity class.

[Skinned Animation in Vulkan]

I believe that is just how the animation is.

[Game Analytics API Plugin]

The whole concept of “plugins” in C++ is probably erroneous. There’s just libraries you can import. In the case of GA you would prefer to use my nice commands over the ugly raw CURL calls.so a couple of C++ files or a lib you import is probably the right approach there.

[Game Analytics API Plugin]

Well in this case you can just include the lib in your project and you don’t really need a middle layer for any reason.

[Game Analytics API Plugin]

Is that the original Steam API command?

[Game Analytics API Plugin]

Yeah, I am just wondering how this should be exposed to the programmer. I can think of three different ways to interface with C++:

• Procedural DLL commands.
• Procedural DLL commands with OO wrapper classes.
• OO Static library.

[Game Analytics API Plugin]

Steamworks is another feature I would like to turn into a plugin.

[Package Plugins and Mods]

We could also use a Crunch CRN loader plugin:
https://github.com/BinomialLLC/crunch

[Package Plugins and Mods]

I think zip supports the same thing.

[Package Plugins and Mods]

1 hour ago, reepblue said:

Source Engine models have a lot of information in them so I don't know how easy/hard it would be.

But also, this means we can use vpks to store our game data?

Yes. I am curious why you would want to use that format?

[Package Plugins and Mods]

Someone needs to write a plugin to load Source Engine models. HLLib can handle this:
http://nemesis.thewavelength.net/index.php?p=35

[Leadwerks Plugin SDK]

You could create your own plugin and expose the FI functions to the engine, or just incorporate the FI library into your project. The source code for the plugin is on Github.

[Plugin SDK now available]

This has been replaced with this repo:
https://github.com/Leadwerks/PluginSDK

[Particle Plugins and More]

Another trick you can use is to place a script in the Scripts/Start folder that loads a plugin into a global variable. That way the plugin will always be loaded automatically when your game starts.

[Beginning with Particles]

I see the "values" as being script-defined properties. I am offloading all the particle features and settings into Lua scripts so that there is no limit on the features particles can support..In LE4 we had fixed emission volumes, in the new engine you can add a script for a new emission shape of your own, or whatever you want.

Does that make more sense now?

[Sprite Layers and the GUI]

Maybe it is being called somewhere else? I can’t tell without seeing the full program.