[Ultimate Action Game Controller ( UAGC ) - WL 2]

This is awsome.  Love the POI head tracking.  Good job!

[Finishing Touches]

Good to see all your hard work has paid off.

[Where Input Has A Name]

Did you manage to get this working for Ultra?  Input is something I've not really thought about for my game and I like the idea of actions instead Window::KeyHit().

[Colliders in Ultra Engine]

Can we enable physics shape visualization from within code yet?

[Voxel Terrain Part 3 - Dynamic Components]

Fixed a few issues.  I was only allocating enough voxel memory pages for the final level of subdivision that represented the surface.  I didn't take into account the fact that I needed space for the all their parent nodes too.

Also have finally removed double vertices with the TransVoxel method.  In one scene there was 108k vertices, after the fix it went down to 30k.  About a 72% decrease!

[The Seventh World - Part 1]

This is a 2k Voxel Terrain with tri-planer texturing.  It's just diffuse right now, and the red is an area that will be textured differently.   It's coming along nicely.  I think I'll work on normal maps and smooth shading.

The LOD algorithm needs work, the detail in the terrain falls off too sharply I feel.

[Voxel Terrain Part 3 - Dynamic Components]

Thinking about it, 14GB seemed way to high and I was right - the problem was I was setting up a components node pool like this;

voxel_pages = make_shared<VoxelPages>(node->bounds.size);

Using the bounds size when they were only small (16m to 32m) were fine but when I made components as big as the terrain itself (4096m) it wasn't a good idea.  Some components were allocating 2048*2048 page size, so about 4 million nodes at one (1.6GB) and it only used a dozen of them from the pool.

Making each page the size of the component fixed it right up.

voxel_pages = make_shared<VoxelPages>(component_size);

The 4K terrain now only uses 800MB.  

[Voxel Terrain Part 3 - Dynamic Components]

Promising results with a 4096x4096x4096 terrain.  Takes up about 14GB of memory but the creation and updating process are very fast.

[Voxel Terrain Part 3 - Dynamic Components]

Have it working in real-time now.  The small white sphere is the viewer.  It still needs refining, instead of deleting components and then creating a new one I'll probably add the components to a "re-purpose" list.  It will save a bit of time, mainly in the creating of a new model and voxel node memory pools.  Other than that there are a few minor memory leaks.

This is all in debug mode too.

[Voxel Terrain Part 3 - Dynamic Components]

A 4096 voxel terrain took nearly 3 seconds in debug mode to generate.  Without dynamic components it would be 16,777,216 components and would be generating long into the night.  With it, it is only 78!

[The Seventh World - Part 1]

Got it pretty much looking the way I wanted.

float CalculateTerrainSurface(shared_ptr<VoxelObject> voxel_object, shared_ptr<VoxelBrush> brush, VoxelNode* node, Decimal3& position) {
    float radius = 32.0f;
    float size = voxel_object->GetSize();
    auto centre = voxel_object->GetPosition();

    auto ratio = 1.0f;
    auto local_y = position.y - centre.y + radius;
    if (local_y < radius * 2.0f) {
        ratio = 0.75f + (local_y / (radius * 2.0f)) / 3.0f;
    }

    auto dist = sdfBox(Vec3(centre.x, centre.y, centre.z), Vec3(radius * ratio, radius, radius * ratio), Vec3(position.x, position.y, position.z), 16.0f * ratio);
    return dist + (noise->GetFractal(8, position.x / size, position.y / size, position.z / size) + 1.0f) / 2.0f * 16.0f;
}

 

[The Seventh World - Part 1]

Yeah I think if you spend too long trying to solve a problem then it's probably not worth it.  At least maybe until all other options have been explored enough to form a decision on.

[The Seventh World - Part 1]

An SDF cube with a corner radius was the way to go.  It's so annoying how you can spend months getting something to work then realise there is a 5 minute method that is so much better.

[The Seventh World - Part 1]

A cube is the base shape here.  I think it will work a lot better if I make a bevelled cube or simply squash the sphere a little for each face.  But the edges are practically seamless without any extra processing.

[The Seventh World - Part 1]

I didn't realise I could use 3D noise to create a heightmap without creating caves. 

This is using a sphere as the base and then sampling 3D simplex noise to create the terrain on that sphere.  What I did in Leadwerks was project a heightmap onto the face of a cube to render the terrain and I was going to do the same thing in Ultra too but the whole process of blending all the maps together is very convoluted.  This is actually very simple.

float CalculateTerrainSurface(shared_ptr<VoxelObject> voxel_object, shared_ptr<VoxelBrush> brush, VoxelNode* node, Decimal3& position) {
    float radius = 32.0f;
    float size = voxel_object->GetSize();
    auto centre = voxel_object->GetPosition();
    Decimal3 local_pos = {position.x - centre.x, position.y - centre.y, position.z - centre.z};

    auto dist = sqrt((local_pos.x * local_pos.x) + (local_pos.y * local_pos.y) + (local_pos.z * local_pos.z)) - radius;
    return dist + noise->GetFractal(4, position.x / size, position.y / size, position.z / size) * 16.0f;
}

I think I can apply this to the cuboid shape I made above and then further manipulate how the terrain is made before eroding it.  I'm not sure yet, but I think I'll have to project the height values onto some 2D planes so I can perform erosion on them and then map them back.  Otherwise I'll have to erode either a cube map of points or the voxel octree itself.  The former will take a lot of memory for large terrains and the latter will probably far too slow.

Food for thought!

[The Seventh World - Part 1]

I'm hoping it creates more of a floating island look rather than a cube with mountains.  Something like this but less of a point at the bottom.

[UltraEngine Utilities]

All good.  Will try it again this weekend, thanks.

[Editor Development Continues]

This is looking really good.  I used the Leadwerks editor the other day and realised how much I missed it.  Ultra is going to be great!

[Voxel Terrain Part 2 - Voxelization Methods]

Not really... because each node has a set amount of vertices and triangles, if you want to have a smooth shape you have to interpolate the vertices down or up the nodes edge toward the surface.  There's no visual stepping or anything, it just creates a lot of small triangles where the vertices have been moved really close to a nodes corner.  Mostly it is just wasted geometry because they are so small but I've found it does give a more non-uniform look in the geometry compared to the 2D terrain rendering method with set patch sizes.

In some cases the vertices could all be on top of one another and therefore the triangle is not visible at all, but it is still there.

This is marching cubes without interpolation.

[Voxel Terrain Part 2 - Voxelization Methods]

Marching cubes are not the best for displaying geometry.  It's fine if you want a blocky look (let the vertex be created at the centre of every node edge) but if you interpolate to better match the object you want to represent, you end up with lots of different sized triangles.  Below is flat shading so it's more obvious, but you can see in wireframe the steps where triangles are squashed as it goes up to the next highest node.  SurfaceNets and DualContouring should be much better (and faster to generate) but there are aspects about both I don't really like.

SurfaceNets, once the vertices are created, needs to be looped over a few times to slowly morph the vertices toward one another to create a smooth shape.  This means the object will shrink a little at the edges.

DualContouring seems much better but does use some fancy math I can't wrap my head around (yet) to better represent sharp edges.  I think I am going to try and make something that is a combination of the two.

MarchingCubes:

WireFrame:

[UltraEngine Utilities]

Oh okay, I'll wait.

[UltraEngine Utilities]

Hi,  I've added those missing files.  These libs however are missing... do we have to generate them ourselves somehow?

#pragma comment(lib, "Scintilla_d.lib")
#pragma comment(lib, "Lexilla_d.lib")

 

[UltraEngine Utilities]

I've include Utilities.h in my project but am getting errors on these lines because the files do not exist in those folders?

#include "../external/submodules/scintilla/include/ScintillaTypes.h"
#include "../external/submodules/scintilla/include/ScintillaMessages.h"
#include "../external/submodules/scintilla/include/ScintillaStructures.h"
#include "../external/submodules/scintilla/include/ScintillaCall.h"
#include "../external/submodules/scintilla/include/Scintilla.h"

#include "../external/submodules/scintilla/include/ILexer.h"
#include "../external/submodules/lexilla/include/Lexilla.h"
#include "../external/submodules/lexilla/include/SciLexer.h"

 

[UltraEngine Utilities]

Great stuff!  Will try out the compiler and watcher this weekend.  Thanks.

[Ultra Engine SDK Now Available]

Congrats!!  I remember when you started this journey.  So good to see it all come togeather into an awsome product!  Looking forward to the future of Ultra!