[6 Reasons You Should Use Ultra Game System]

I have a seventh reason

7. It is simply awesome and easy to use. 

Very nice work. 

[Finishing Touches]

5 hours ago, Josh said:

1. In Ultra, every surface is reflective, so there is actually no need for a special water surface (AAA games nowadays are taking the same approach, see Phantom Liberty). Water consists of two things:

• An animated or scrolling texture
• Some kind of buoyancy physics volume

I do not have the second part set up yet, but plan to do so. Also, we can probably do something interesting with the player physics to allow swimming.

This is true. It is very easy to modify the current pbr shaders into a new shader family to achieve a water effect. But therefore a few other things need to be (re)added:

• animated textures (currently not included, but can be achieved by creating a new shader family with a modified fragment.glsl file) 
• adding some advanced material options:
  • Refractionindex (is already in there, but not used)
  • Thickness (also included, but not used)
  • a custom alpha calculation method based on visibility

If this is all included, i can only think of one case, where a special surface is needed (mainly for performance) is the usage of oceans. 

 

[UltraEngine Utilities]

Sorry for the delay. I have added the missing lib files. You need to add the "external/libs" folder to the link path in your project.

[UltraEngine Utilities]

I will provide them, but it will take till tomorrow. You can create them by yourself, but you need to modify the scintilla and lexical project to build as libs and modify the debug output name.

[UltraEngine Utilities]

Hi, i just came back from vacation. Normally if you cloned the repo you just need to run this from cmdline in the main folder:

 

git submodule update --init

On 1/26/2023 at 2:27 PM, Josh said:

Same here. I can't even see the missing headers in the Scintilla repository here:
https://github.com/mirror/scintilla/search?q=ScintillaStructures.h

this mirror is out of date for a long time I use this one: 

https://github.com/missdeer/scintilla

but I will remove the scintilla submodule and just try to include all relevant files in the repo.

 

[UltraEngine Utilities]

On 1/16/2023 at 6:12 PM, Josh said:

Do you think Scintilla can be compiled as a DLL module for Lua to call? It would be interesting to see if we can add a script editor tool as an extension:

local function hook(event, scripteditor)

    --Catch menu event to open script editor
    if event.id == EVENT_WIDGETACTION then
        if event.source == scripteditor.menuitem then
            scripteditor.window:SetHidden(false)
            scripteditor.window:Activate()
        end

    --Intercept asset browser open asset event
    else if event.id == EVENT_OPENASSET then
        ext = string.lower(ExtractExt(event.text))
      
        --If it's a code file let's steal the event
        if ext == "vert" or ext == "frag" or ext == "lua" then
            local code = LoadString(event.text)
            scripteditor.codearea:SetText(code)
            scripteditor.window:SetHidden(false)
            scripteditor.window:Activate()        
            return false --the rest of the program will never see the event! ha-ha 
        end
      
    end
end

local menu = program.menu:FindChild("Tools")

local scripteditor = {}
scripteditor.window = CreateWindow("Script Editor", 0,0,800,600,program.window, WINDOW_TITLEBAR + WINDOW_RESIZABLE)
scripteditor.ui = CreateInterface(scripteditor.window)
scripteditor.codearea = CreateCodeArea()---TODO!
scripteditor.menuitem = CreateMenu("Script Editor", menu)

--Listen for events
ListenEvent(EVENT_WIDGETACTION, scripteditor.menuitem, hook, scripteditor)
ListenEvent(EVENT_OPENASSET, program.assetbrowser, hook, scripteditor)

Some ideas which you might consider. The createcodearea should be extended to get the filepath ( for parsing includes or imports) . A way to configure the required highlighting. Instead of pass these things one by one I would create a table ( maybe Document) containing all the infos required by the codearea. 

[UltraEngine Utilities]

What errors do you get? I only got problems, when i tried to link libs which where not exported for the correct project configuration.

You need to reference the debug libs or release libs depending on you current build configuration. Otherwise you only have the option to use dlls together with the small lib files. For Scintilla i do something like this in my header:

#if _DEBUG
#pragma comment(lib, "Scintilla_d.lib")
#pragma comment(lib, "Lexilla_d.lib")
#else
#pragma comment(lib, "Scintilla.lib")
#pragma comment(lib, "Lexilla.lib")
#endif

 

[UltraEngine Utilities]

The original design of scintilla on win32 is based on dll usage,  but I have decided to use the lib approach because this will make it much easier to make it crossplatform, and it is much easier to debug. Nevertheless this will not limit you to create a DLL plugin using scintilla. If I think about it it is much better than the original scintilla way, as you don’t need any 3rd party dlls and you can create a shared lib for Linux or macOS the same way on all platforms.

[UltraEngine Utilities]

Just added: 

shared_ptr<SyntaxEditor> CreateSyntaxEditor(const int x, const int y, const int width, const int height, shared_ptr<Widget> parent)

This will create a scintilla component. It works both for 3d Interfaces and Window-Interfaces, But in 3d it is just an overlay on the topwindow, so it is not available for render to texture targets. For Details on how to use the Control: https://www.scintilla.org/ScintillaDoc.html 

I have seperated the Scintilla Function calls from the base Widget. You need to call: syntaxEditor->GetCall()->CurrentPos() for exsample. It is more oriented the way it is used by the original author in his Scite project.

[SyntaxEditor - Widget]

Will check it. I haven‘t looked at this for a while, but I think it will be just some adjustments.

 

[Finalizing Terrain]

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.

[Finalizing Terrain]

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. 

[Finalizing Terrain]

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. 

[Better Intellisense in Ultra Engine]

That is all I needed to know  

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

[Better Intellisense in Ultra Engine]

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. 

[Better Intellisense in Ultra Engine]

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..

[Finalizing Shaders and Real-time Global Illumination Progress]

This can be done in LE as well

[Voxel Cone Step Tracing - Cascaded Volumes]

Hi, your blogs are very interesting to read, and I am looking forward to see the results

I have 2 ideas regarding this post: 

1. Maybe you could stabilize the movement if you make the cascades slightly bigger and move them in tiles instead on a per-pixel basis. It is not the same, but i have done this with my water mesh tiles and that has eliminated most artifacts like swimming etc.

2. with the voxel data it should be much easier to create something like a global distancefield , this would make it possible to calculate a lot of effects in shaders with nearly no additional cost. (e.g.: vector fields, water flow, directional waves, boids etc.) 

 

Looking forward for the progress.

[Direct Lighting with Sparse Voxel Octrees]

I don’t know if you already use it. But take a look at Nvidia nsight. 

https://developer.nvidia.com/nsight-visual-studio-edition

you can fully debug OpenGL Vulkan or directx calls and even modify the shader code on the fly and check the registers and texture states. It was very useful for me to fix some issues with my atmospheric scattering shaders.

 

[Editor Scripting API]

I would extend the CreateSceneObject function with some kind of key or type element. And also methods to get,filter,iterate and modify all Scene objects of a certain type. This would make something like this possible:

box = CreateBox(editor.world)
box.name = "box"..(GetSceneCountForType("BoxCreator") + 1)
o = CreateSceneObject(box,"BoxCreator") --make editor recognize the entity and add it to the scene browser with a specified key or type
o:SetSelected(true)

 

[Basics]

Made some progress with the ScintillaWidget: 

Scrollbars are native SliderWidgets from UAK

Also i have the Notifcationsystem aka Events from Scintilla integrated to UAK.

[Leadwerks and C#]

A small hint: 

if you take a closer look into the Include directory you will find this: DLLExport.h

This file already contains a lot of exports yu may use as it is the dll code used for the editor.

[Leadwerks and C#]

Hi, 

I'm working on a similar project and i'm currently preparing a github repo for my Wrapper. It will still take some time and cleanup until it is up, but it will provide full access to the API (same as in lua + some extras). Meanwhile you may take a look http://www.swig.org/ or https://github.com/mono/CppSharp for generating bridges between Cpp and CSharp. The nicer way would be CppSharp, but i can't get the parser to work, so i will stick with swig. 

Currently a small sample looks like this:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Leadwerks.Core;

namespace Leadwerks.Test
{
    class Program
    {
        static void Main(string[] args)
        {
            List<Entity> entities = new List<Entity>();

            Window window = Window.Create();
            Context context = Context.Create(window);
            World world = World.Create();
            world.SetLightQuality(2);
            Camera camera = Camera.Create();
            camera.SetRotation(35f, 0f, 0f);
            camera.Move(0f, 0f, -6f);
            Light light = DirectionalLight.Create();
            light.SetRotation(35, 35, 0);
            entities.Add(light);
            Model model = null;

            model = Model.Box();
            model.SetColor(1.0f, 0.0f, 0.0f);
            model.SetPosition(-4, 1, 0);
            entities.Add(model);

            model = Model.Cylinder();
            model.SetColor(0.0f, 1.0f, 0.0f);
            model.SetPosition(-2, 1, 0);
            entities.Add(model);

            model = Model.Cone();
            model.SetColor(0.0f, 0.0f, 1.0f);
            model.SetPosition(0, 1, 0);
            entities.Add(model);

            model = Model.Sphere();
            model.SetColor(0.0f, 1.0f, 1.0f);
            model.SetPosition(2, 1, 0);
            entities.Add(model);

            model = Model.Create();
            model.SetColor(1.0f, 0.0f, 1.0f);
            model.SetPosition(4, 1, 0);
            entities.Add(model);

            Surface surface = model.AddSurface();
            surface.AddVertex(-0.5f, -0.5f, 0, 0, 0, -1);
            surface.AddVertex(0.5f, -0.5f, 0, 0, 0, -1);
            surface.AddVertex(0.5f, 0.5f, 0, 0, 0, -1);
            surface.AddVertex(-0.5f, 0.5f, 0, 0, 0, -1);
            surface.AddTriangle(2, 1, 0);
            surface.AddTriangle(0, 3, 2);
            surface.UpdateAABB();
            model.UpdateAABB(Entity.LocalAABB | Entity.GlobalAABB);
            model.Move(0,0.25f,0);
            entities.Add(model);

            Terrain terrain = Terrain.Create(512);
           
            while (true)
            {
                if (window.KeyDown(Key.Escape)) return;

                foreach(var entity in entities)
                    entity.Turn(0.1f,0.1f,0.1f);

                Time.Update();
                world.Update();
                world.Render();

                context.DrawText("Hello World", 20, 20, 100, 100, 1);
                context.DrawText("Hello World", 20, 40);
                context.Sync();
            }
        }
    }
}

 

[Workshop Design]

This will improve the workshop a lot. How about a way to choose on a per project basis which workshop items you want to have in the project. This way you can handle updates globally (on the user machine) but seperate from your current project. I don't want to have all workshop items available in my projects espeacially if i just want to test something out. You can replicate a local version of the steam - workshop on the user machine.

[Teaser from Tron land]

Very nice stuff

 

Small hint: In most "planetary scale" terrain renderer they use a noise texture to overcome the lack of detailed data and mix it with the lower resolution map to simulate very high detailed closeup views.