klepto2

@Josh I have provided the extra parameter in the function: auto env = make_shared<Environment>(world); world->AddHook(HOOKID_RENDER, CalculateEnvironment, env); The Print was just for testing, of course this should be removed. [Edit:] I should mention taht it still isn't called in the render loop or otherwise

I have now tried a very basic setup for the new Hook-Feature, but can't get it to work While the setup works, it just does nothing in the loop. #include "UltraEngine.h" #include "ComponentSystem.h" using namespace UltraEngine; class Environment : public Object { private: shared_ptr<World> _world; public: Environment(shared_ptr<World> world); friend shared_ptr<Environment> CreateEnvironment(shared_ptr<World> world); }; void CalculateEnvironment(VkCommandBuffer cbuffer, shared_ptr<Object> extra) { //Vulkan code Print("Hello World"); } Environment::Environment(shared_ptr<World> world) { _world = world; } shared_ptr<Environment> CreateEnvironment(shared_ptr<World> world) { auto env = make_shared<Environment>(world); world->AddHook(HOOKID_RENDER, CalculateEnvironment, env); return env; } int main(int argc, const char* argv[]) { //Get the displays auto displays = GetDisplays(); //Create a window auto window = CreateWindow("Ultra Engine", 0, 0, 1280 * displays[0]->scale, 720 * displays[0]->scale, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR); //Create a world auto world = CreateWorld(); //Create a framebuffer auto framebuffer = CreateFramebuffer(window); //Create a camera auto camera = CreateCamera(world); camera->SetClearColor(0.125); camera->SetFOV(70); camera->SetPosition(0, 0, -3); //Create a light auto light = CreateLight(world, LIGHT_DIRECTIONAL); light->SetRotation(35, 45, 0); //Create a box auto box = CreateBox(world); //Entity component system auto actor = CreateActor(box); auto component = actor->AddComponent<Mover>(); component->rotation.y = 45; auto environment = CreateEnvironment(world); //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { world->Update(); world->Render(framebuffer); } return 0; }

I will check it out and report back later

I get this when running the 2d sample. I get a bunch of shader module errors: Loading shader family "Shaders/PBR.json" Error: Failed to load shader module "Shaders/DepthPass.frag.spv" Error: Failed to load shader module "Shaders/DepthPass_Masked.vert.spv" Error: Failed to load shader module "Shaders/PBR_dynamic.vert.spv" Error: Failed to load shader module "Shaders/PBR_Animated_dynamic.vert.spv" Error: Failed to load shader module "Shaders/DepthPass_dynamic.vert.spv" Error: Failed to load shader module "Shaders/DepthPass_Animated_dynamic.vert.spv" Error: Failed to load shader module "Shaders/DepthPass_Masked_dynamic.vert.spv" Loading font "Fonts/arial.ttf" Loading shader family "Shaders/Unlit.json" Error: Failed to load shader module "Shaders/Unlit_transparency.frag.spv" Error: Failed to load shader module "Shaders/Unlit_Tess.frag.spv" Error: Failed to load shader module "Shaders/Unlit_Masked.frag.spv" Error: Failed to load shader module "Shaders/Unlit_Masked_Transparency.frag.spv" Error: Failed to load shader module "Shaders/Unlit_Tess_Masked.frag.spv" Error: Failed to load shader module "Shaders/Unlit_Tess_dynamic.frag.spv" Error: Failed to load shader module "Shaders/Unlit_Tess_Masked_dynamic.frag.spv"

This looks more like you accidentally activated a clipplane as everything is clipped at an exact plane. Do you have added some posteffect which uses clipplanes?

Hi, game middleware can be in many forms, but mostly you develop your middleware in an abstract manner. This can mean the following: You just make methods which calculate things and give out these data. The user has to decide how to integrate them into his engine. (e.g.: Pysicsengines like Newton) You have provide some kind of abstract classes which your middleware can consume and which wraps up the functionality you need in your middleware. (e.g.: Graphics Engines with multiple Drivers, UI-Engines in most cases) for the abstract way there are some more things to consider than just OpenGL or DirectX. Each engine can have a unique coordinate system, for exsample, some have an upvector of [0.0,1.0,0.0] but also an upvector of [0.0,0.0,1.0] is very common. That means that unlike in Leadwerks the y-axis is up, but the z-axis is up. You need to provide some kind of driver or interface for the middleware to interact with the engine. So everyone can implemnt the engine specific needs themselve.

Maybe you should use the common mutex approach: m_singleInstanceMutex = CreateMutex(NULL, TRUE, L"Some unique string for your app"); if (m_singleInstanceMutex == NULL || GetLastError() == ERROR_ALREADY_EXISTS) { HWND existingApp = FindWindow(0, L"Your app's window title"); if (existingApp) SetForegroundWindow(existingApp); return FALSE; // Exit the app. For MFC, return false from InitInstance

1. For me the avatar is distorted as well: 2. Windows Defender marked the zip file as a thread, but a more advanced scan with other scanners don't; 3. The spinner animation looks a bit off, I mean it isn't spinning at the center, It looks like the center is off by one pixel or so.

svg itself ist just static, you could look up this: https://github.com/chadly/lottie-to-svg with this code you can extract a svg frame by frame.

Hi, You need to clear the posteffects per camera and then add them again one by one. https://www.leadwerks.com/learn?page=API-Reference_Object_Entity_Camera_ClearPostEffects

The position in the editors is measured in centimeters while the engine itself works with meters.

I think your results are correct. The compute shaders are great when you need more complex one time calculations or when you can benefit from cross thread calculations. Eg. Pass the result from one compute batch to another. Also it is very important either fragment or compute to align your memory for your uniforms or buffers in case of vulkan. in my experience, while compute shaders can be faster when used for certain scenarios modern fragment features can be better for others. Sometimes it is not only about performance but also about maintability of the code base. And the in my opinion compute shaders are very good, eg terrain editing or particle, agent simulation. one should always decide which one fits better to the subject of the shader.

hi, the c# one is not for C# script, the C# part will be a full engine wrapper of the cpp part, so you could develop completely in C#. But for sure i will create a C# Script adapter as soon as UltraEngine is alive. I have written a prototype one for LeadwerksEngine previously and it should be nearly the same in Ultraengine.

If the branching is based on uniform data the performance impact is nearly zero. ( depends on gpu and driver) other branching has still a big impact on performance. Normally the shader will execute every possible branch for each processing unit ( vertex, fragment, etc.) and only keep the latest valid result. As the first this can be optimized by the gpu itself or the driver but can vary from gpu to gpu and vendor to vendor.

I think the shader families comes close to that what unity does, but slightly different. Under the hood, there are different shaders compiled and linked for each configuration ( i guess only when needed of course) . In unity, you define this more or less directly in the shader and not in a separate file format. It is more like CG and HLSL style of shaders. I like the separation in UltraEngine, so shaders are shaders and nothing more. And with SPIRV under the hood you have a lot of more control flow in the shaders than in direct GLSL, just to name the #include directive as one example.

I think these coordinates are based on the terrain resolution. The real size and height later displayed on screen is based on the used scale factors u set with setscale. I would assume with a scale of 1 it could be interpreted as 1 m but this depends what you define in your app as 1m.

You could also try another approach: Pseudocode: class GameAction { public: virtual bool IsCalled() = 0; } class KeyHitAction : GameAction { private int key; private Window* window; public: KeyAction(Window* window, int key); virtual bool IsCalled() { return window->KeyHit(key);} } class MouseHitAction : GameAction { private int button; private Window* window; public: KeyAction(Window* window, int button); virtual bool IsCalled() { return window->MouseHit(button);} } std:map<string,GameAction*> actions; actions["THROW"] = KeyHitAction(window,KEY_T); actions["SELECT"] = MouseHitAction(window,MouseButton::Left); //in Loop if(actions["THROW"]->IsCalled()) { } This could easily to be extended to Gamepads and other input devices. Also you could add MouseDownActions or other types of Actions.

Just a side node: On intel integrated gfx card this glsl code is producing horrible noise. But you can overcome this issue by significantly lowering the 43758.5453f I think Josh's code is a conversion to c++ code. Yours is correct for glsl. Edited: As a side node, this should always replaced with a noise texture lookup in glsl when possible. While it is faster in c++ than traditional random generators it will slow down glsl shaders when it is used to much. A simple texture lookup is much faster. (one way is to pregenerate a texture with this function and later use this texture to lookup the random number.

It is a lot of lod and optimized meshes and a lot of optimized level design and tricks. But the most important thing is that these commercial engines are highly optimized for the exact use case. While Leadwerks is designed to meet a lot of diefferent kind of games or scenarios the commercial ones are mostly ( not all) modified for each game. Also the engine developer have a lot of support from gpu vendors and the gpu drivers are commonly updated to work best with these engines. Another point is that at least on windows mainly dx12 is used which gives a lot more room for optimization than OpenGL. Once ultraengine is out which uses Vulkan, which is much closer to the hardware and dx 12 I think we will see a close competitor to the current “state of the art commercial engines”. But in defense to Leadwerks I think with a clever level design and the use of lod and other tricks the mentioned levels can be done in le as well.

That is all I needed to know It looks very promising, and I am curious to see how it all works together.

I came across a lot 3rd party libs (eg: nvidias waveworks or shader libs, eg: vkFFt) need at least access to the vkInstance. If the vkInstance is known everything else can created in the app context.

Keeping everything structured and separate with a public only api is a real good step forward. This will make access to other languages much easier as you just need toward the public interface. But you need to keep in mind that the integration of some third party code especially in Vulkan may need some access to some lowlevel details, eg.: the Vulkan context these pointers should be made public in some way as well. Otherwise I really like the way ultraengine is structured..

This can be done in LE as well

hi, if you want to sell it or make it public in any other way, you might consider adding multiple texture-sets (rusty, new, painted in different colors) maybe as well some variations with some spray or signs on the pipes. If you need it for internal only, it highly depends on the pipes' usage. Industrial-pipes are often colored by their meaning, e.g.: yellow usually means gas, etc. If the pipes are older ones you should use some old metallic with some rust on it, newer ones should be, if not painted, a clear steel like material.