Ultra Engine testing

[klepto2]

the new Character Controller and Physics looks very smooth.

The PBR-Pipeline still seems to be somehow broken: The result from this sample 

 

 

now looks like this:

 

Also it seems that the IBL textures have nearly no effect on the ambient colors.

 

Side question: Is it possible to get the current VkrenderPass in the Render Hook? if not is it possible to add a custom RenderPipeline or RenderPass to the actual renderer?

[Josh]

55 minutes ago, klepto2 said:

Side question: Is it possible to get the current VkrenderPass in the Render Hook? if not is it possible to add a custom RenderPipeline or RenderPass to the actual renderer?

The engine uses the dynamic rendering Vulkan extension, so no render passes are ever used.

https://www.khronos.org/blog/streamlining-render-passes

[klepto2]

Ah i remember, this is cool. Thank you. that was the missing hint.

[Josh]

5 hours ago, klepto2 said:

The PBR-Pipeline still seems to be somehow broken:

I updated the shaders to fix this. I had just hard-coded the IBL intensity to 0.1 in the shader while testing.

[Josh]

Shaders updated again to fix box light shadows.

[klepto2]

I am currently refactoring and reorganizing my Compute Pipeline to gain more performance and to make it a bit more flexible to use:

In my current implementation, you always have one Shader with one Set of data to use, so you internally the descriptorset is always switched and the buffers,textures are always bound on every dispatch, while this is no problem for one-shot computes it could and will slowdown the pipeline for recurring compute passes like particles or realtime pbr calculations. So i started refactoring it to allow shared Descriptors between multiple compute shaders. You can call them something like ShaderGroups, this means you can still creatte the same behaviour like my first apprach, but also you can group several compute shaders with the same descriptorset to one batch:

This is how it will look like (kind of pseudo code) :

	auto pipeline = CreateComputePipeline(world, ComputeHook::TRANSFER);
	auto sharedPipelineDescriptor = CreateComputeDescriptor();
	sharedPipelineDescriptor->AddSampler(0, texture1, 0); //slot, texture, set
	sharedPipelineDescriptor->AddSampler(1, texture2, 0); //slot, texture, set
	sharedPipelineDescriptor->AddSampler(0, texture3, 1); //slot, texture, set
	sharedPipelineDescriptor->AddUniformBuffer(1, &buffer, 1); //slot, buffer, set
	sharedPipelineDescriptor->SetPushConstantSize(sizeof(PushData));

	auto environmentComputeShader = CreateComputeShader("compute/environment.comp.spv", sharedPipelineDescriptor);
	auto particleComputeShader = CreateComputeShader("compute/particleDescriptor.comp.spv", sharedPipelineDescriptor);
	
	environmentComputeShader->SetPushConstant(&pushdata1);
	particleComputeShader->SetPushConstant(&pushdata2);
	environmentComputeShader->SetDispatchSize(16,16,1);
	particleComputeShader->SetDispatchSize(8,8,8);

	pipeline->AddShader(particleComputeShader);
	pipeline->AddShader(environmentComputeShader);

	pipeline->Dispatch();

What do you think? Any ideas how to improve the code experience?

 

[Josh]

That functionality is pretty advanced, so I think ease of use is probably less important than whether it handles everything the user wants to do.

I would like to replace Texture::GetVkTexture() with Texture::GetImage() and Texture::GetSampler(). That means there would be no access to the VkImageView objects the engine uses, and you always need to create your own. Would that cause problems for your code?

[klepto2]

Well, it wouldn‘t break it, but it would make access to it a bit harder. I don’t mean my implementations , as i already create my own views for cubemaps but why create extra views if the correct ones are already there? Providing this info doesn‘t hurt and could help to encourage to extend the engine for other users. Maybe, and I think I have mentioned this idea already, it would be nicer to have some external scope to get all these informations. So you can keep the main classes clean, but for those who need it, you can provide these information ( undocumented of course, maybe later supported). 
I could imagine something like an extra namespace like UltraEngine::Transfer and there you could have something like getvktexturedata( shared_ptr<Texture>).

this is just my opinion, I like it if the code is protected, but also accessible for advanced cases. The decision is up to you.

[reepblue]

You might question why I'm doing this, but I have hit a dead wall with this. 

For some reason, when I after compiling an Ultra Engine project built by my premake script, the application throws an exception when I call CreateWindow() from the default main.cpp. I went back and forth between my solution and the one generated by the project manager. I could not find a difference minus the /sdl flag not properly being set, but that's not the problem.

Here's my project script if you're curious. Also, I think compiling the engine libraries with static runtime disabled will prevent the engine being linked with other static libraries if I recall correctly.

g_LeadwerksHeaderPath = "D:/Ultra Engine/Include"
g_LeadwerksLibPath = "D:/Ultra Engine/Library"

project "ultratest"
    location "../../unittests/ultratest"
	language "C++"
    cppdialect "C++17"
	staticruntime "off"
	editandcontinue "on"
    flags { "MultiProcessorCompile" }
    conformancemode (false)

    targetdir(path_bin)
    debugdir "%{path_game}"
    objdir "%{prj.location}/%{cfg.buildcfg}_%{cfg.architecture}/%{cfg.system}"

    -- Include Directories
	includedirs
	{
        "$(UniversalCRT_LibraryPath)",

        -- Game files
        "%{prj.location}",

        -- Leadwerks Game Engine
		"%{g_LeadwerksHeaderPath}",
        "%{g_LeadwerksHeaderPath}/Libraries/Box2D",
        "%{g_LeadwerksHeaderPath}/Libraries/freetype/include",
        "%{g_LeadwerksHeaderPath}/Libraries/OpenAL/include",
        "%{g_LeadwerksHeaderPath}/Libraries/RecastNavigation/RecastDemo/Include",
        "%{g_LeadwerksHeaderPath}/Libraries/RecastNavigation/DetourCrowd/Include",
        "%{g_LeadwerksHeaderPath}/Libraries/RecastNavigation/DetourTileCache/Include",
        "%{g_LeadwerksHeaderPath}/Libraries/RecastNavigation/DebugUtils/Include",
		"%{g_LeadwerksHeaderPath}/Libraries/RecastNavigation/Recast/Include",
		"%{g_LeadwerksHeaderPath}/Libraries/RecastNavigation/Detour/Include",
        "%{g_LeadwerksHeaderPath}/Libraries/sol3/include",
		"%{g_LeadwerksHeaderPath}/Libraries/Lua/src",
        "%{g_LeadwerksHeaderPath}/Libraries/enet/include",
        "%{g_LeadwerksHeaderPath}/Libraries/newton/sdk/dExtensions",
        "%{g_LeadwerksHeaderPath}/Libraries/newton/sdk/dlkSolver",
        "%{g_LeadwerksHeaderPath}/Libraries/newton/sdk/dJoints",
        "%{g_LeadwerksHeaderPath}/Libraries/newton/sdk/dModels/dVehicle",
        "%{g_LeadwerksHeaderPath}/Libraries/newton/sdk/dModels/dCharacter",
        "%{g_LeadwerksHeaderPath}/Libraries/newton/sdk/dModels",
        "%{g_LeadwerksHeaderPath}/Libraries/newton/sdk/dParticles",
        "%{g_LeadwerksHeaderPath}/Libraries/newton/sdk/dNewton",
        "%{g_LeadwerksHeaderPath}/Libraries/newton/sdk/dCore",
        "%{g_LeadwerksHeaderPath}/Libraries/newton/sdk/dCollision",

        "%{g_LeadwerksHeaderPath}/Libraries/NewtonDynamics/sdk/dVehicle/dMultiBodyVehicle",
        "%{g_LeadwerksHeaderPath}/Libraries/NewtonDynamics/sdk/dVehicle",
        "%{g_LeadwerksHeaderPath}/Libraries/NewtonDynamics/sdk/dMath",
        "%{g_LeadwerksHeaderPath}/Libraries/NewtonDynamics/sdk/dgCore",
        "%{g_LeadwerksHeaderPath}/Libraries/NewtonDynamics/sdk/dgNewton",
        "%{g_LeadwerksHeaderPath}/Libraries/NewtonDynamics/sdk/dAnimation",
        "%{g_LeadwerksHeaderPath}/Libraries/NewtonDynamics/sdk/dgTimeTracker",
		"%{g_LeadwerksHeaderPath}/Libraries/NewtonDynamics/sdk/dContainers",
		"%{g_LeadwerksHeaderPath}/Libraries/NewtonDynamics/sdk/dCustomJoints",
    }

    files
    { 
        "%{prj.location}/*.h",
        "%{prj.location}/*.cpp",
    }

    -- Global Defines:
    defines
    {
        "_NEWTON_STATIC_LIB",
        "_CUSTOM_JOINTS_STATIC_LIB",
    }

    -- Shared PCH
    pchheader "pch.h"

    filter {"system:windows", "configurations:*"}
        systemversion "latest"
        entrypoint "mainCRTStartup"
        pchsource "%{prj.location}/pch.cpp"

        links 
        {
            -- Leadwerks Game Engine
        }

        libdirs 
        { 
            -- Leadwerks Game Engine
            "%{g_LeadwerksLibPath}",
        }
            
        defines
        {
            "NOMINMAX",
            "_HAS_STD_BYTE=0",
        }
    
        buildoptions
        {
        }
    
        flags
        {
        }
    
        linkoptions
        {
        }
            
    filter {"system:windows", "configurations:Debug"}            
        links 
        {
            "UltraEngine_d.lib"
        }

    filter {"system:windows", "configurations:Release"}
        links 
        {
			"UltraEngine.lib"
        }            

        filter "configurations:Debug"
            defines
            {
                "DEBUG",
                "_DEBUG"
            }	
            kind "ConsoleApp"
            targetsuffix "_d"
            runtime "Debug"
            symbols "on"
    
        filter "configurations:Release"
            defines
            {
                "NDEBUG"
            }
        	kind "WindowedApp"
            runtime "Release"
            symbols "off"
            optimize "on"	            

 

[Josh]

You're including Leadwerks and Ultra in the same project?

There's also a Leadwerks.h file in Ultra for the translation layer I was experimenting with. Maybe that is causing problems?

[reepblue]

No, sorry. The Leadwerks term is there because I used my script for a Leadwerks project as a base. This should would make a blank project much like the one your generator does.

I will probably make a small isolated demo to see if it still doesn't work.

[Josh]

An update is available. This makes some small API changes to bring the engine inline with the online documentation.

Camera::UpdateControls() is removed and a CameraControls component is added to the project template.

Some small changes tot he component system as well. Component now has an "actor" member, instead of having to call GetActor().

The preprocessor source code is available here:
https://github.com/UltraEngine/Preprocessor

I also noticed the default project was not set up to call the precompiler at all! So this would prevent any new components from being evaluated. I think @reepblue mentioned this a while back. I fixed this and removed the premade ComponentSystem header and source files, so the project won't compile at all unless the precompiler is called successfully.

Some of the terrain examples are currently not working, FYI...should be easy to fix.

[reepblue]

1 hour ago, Josh said:

The preprocessor source code is available here:
https://github.com/UltraEngine/Preprocessor

Thanks for making this open source. I am positive this will be beneficial for me.

I'll definitely try this this weekend. I've been waiting for this fix for a while.

[SpiderPig]

Just updated a project a few times and my project directories are looking like this.

Also after each restart of the client it will still say that these files need updating for each project I have.

Going to test out the player controller soon!

[SpiderPig]

Is CurveValue() now CurveAngle()?

[Josh]

@SpiderPig The backup files are working as intended, but I agree that it turns into a lot of unwanted garbage in your game's folder and should be changed.

The vcxproj and filters files were modified to add the CameraControls component into the project. If you press the diff button for both those files you can see what was changed and insert in the changes if you want them. If you then save the files, it should stop considering them to be outdated.

[Josh]

6 minutes ago, SpiderPig said:

Is CurveValue() now CurveAngle()?

CurveValue was removed because it's the same thing as Mix() if you just flip the last argument:

CurveValue(0.0f, 20.0f, 10.0f) is the same thing as Mix(0.0f, 20.0f, 1.0f / 10.0f)

I think CurveAngle should also be removed and replaced with this:

Mix(a, a + DeltaAngle(a, b), 1.0f / amount)

Or maybe MixAngle(a, b, 1.0f / amount).

[Josh]

Shaders updated. All the terrain examples should be working now.

[klepto2]

the Terrain samples work, but it seems that the pbr properties have no effect to terrain materials, they are too refective. Do you have there some hardcoded values for experimenting as well?

[Josh]

I can reproduce the problem. Let me see what is going on here...

#include "UltraEngine.h"
#include "ComponentSystem.h"

using namespace UltraEngine;

int main(int argc, const char* argv[])
{
    //Get the display list
    auto displays = GetDisplays();

    //Create a window
    auto window = CreateWindow("Terrain Paint", 0, 0, 1280, 720, 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->SetFOV(70);
    camera->SetPosition(0, 60, -60);
    camera->SetRotation(-45, 0, 0);
    camera->SetClearColor(0.125);

    //Sunlight
    auto light = CreateDirectionalLight(world);
    light->SetRotation(65, 35, 0);

    //Create terrain
    auto terrain = CreateTerrain(world, 512);
    terrain->LoadHeightmap("https://raw.githubusercontent.com/UltraEngine/Documentation/master/Assets/Terrain/512.r16");
    terrain->SetScale(1, 100, 1);

    //Create base material
    auto ground = CreateMaterial();
    auto diffusemap = LoadTexture("https://raw.githubusercontent.com/UltraEngine/Documentation/master/Assets/Materials/Ground/river_small_rocks_diff_4k.dds");
    auto normalmap = LoadTexture("https://raw.githubusercontent.com/UltraEngine/Documentation/master/Assets/Materials/Ground/river_small_rocks_nor_gl_4k.dds");
    ground->SetTexture(diffusemap, TEXTURE_DIFFUSE);
    ground->SetTexture(normalmap, TEXTURE_NORMAL);
    ground->SetMetalness(0);
    ground->SetRoughness(1);
    terrain->SetMaterial(ground);

    world->SetEnvironmentMap(LoadTexture("https://raw.githubusercontent.com/UltraEngine/Documentation/master/Assets/Materials/Environment/Storm/specular.dds"), ENVIRONMENTMAP_SPECULAR);
    world->SetEnvironmentMap(LoadTexture("https://raw.githubusercontent.com/UltraEngine/Documentation/master/Assets/Materials/Environment/Storm/diffse.dds"), ENVIRONMENTMAP_DIFFUSE);

    //Camera controls
    auto actor = CreateActor(camera);
    actor->AddComponent<CameraControls>();

    //Main loop
    while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false)
    {
        world->Update();
        world->Render(framebuffer);
    }
    return 0;
}

 

[Josh]

Okay, it's fixed now.

[DooMAGE]

6 hours ago, klepto2 said:

the Terrain samples work, but it seems that the pbr properties have no effect to terrain materials, they are too refective. Do you have there some hardcoded values for experimenting as well?

Wow! This is water simulation in Ultra Engine?

[Josh]

15 minutes ago, DoomSlayer said:

Wow! This is water simulation in Ultra Engine?

No, that is very shiny terrain. However, it does demonstrate that there is no need for any special water reflection technique in Ultra, since the default PBR reflections look quite good.

[Josh]

Here is a bunch of components I don't even remember writing. Maybe someone feels like looking through them to find what they think would be useful to include by default:

Components.zip

[Josh]

 

New update

• Fixed point lights not getting a shadow refresh triggered when an object moved.
• Fixed static shadow cache, so this rather nice example now works correctly: https://www.ultraengine.com/learn/Entity_Staticize?lang=cpp
• Removed CurveAngle, added MixAngle.