SpiderPig

There are some holes in the mesh but I don't think its causing the shadow problem.

Well I disabled my material and it's not that... I'm only setting vertex positions. No normals, tangents or bitangents... maybe that's the problem...

Been noticing this a bit but not sure what it is... it seems to grow as the camera moves but certain camera orientations make it disappear. It's probably my material, or my mesh updates causing it but I do not know. https://www.youtube.com/watch?v=1QE3NEumHxU

This is what I'm doing at the moment too... I do it to set individual custom widget members like; left_pressed = true; mouse_over = true; etc. I did it because I wanted to know if the mouse was over a panel which was full of buttons or other widgets and I had to setup a recursive function that sent the event_id up the chain to a widgets parent. So are you saying the events work in reverse now? They go down from the root widget down to all the respective children?

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.

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

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.

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!

Took some time to figure out the best approach to do this but I've got it now. To start with I created components that are all the same size. I am using 16x16x16 components. The voxel terrain is 128^3 so dividing that evenly is 8^3 components. In this image there is 512 of them. The red are inactive and the green are active (they have a model the represents the surface). This posed a problem for very large terrains. I would need a component size small enough so that LOD and real-time editing are fast but too small and the component count would become unmanageable. So I made an option to create dynamic components. voxel_object->EnableDynamicComponents(true); This means instead of a component being exactly 16m cubed in size (the lowest LOD level would have 4 vertices and two triangles for a flat plane) it would now be resized to have a mesh that is 16 nodes cubed (16x16 vertices for a flat plane regardless of LOD level). Which mean it now looks like this; Instead of 512 components there is only 36 and 10 of them are active. It means I can lower the component size to something really small like 8x8x8 or even 2x2x2. I can experiment with this to find a balance between speed of LOD updates and editing updates. Wireframe; And the terrain can be represented by a minimum of 1 component. It also means I can try creating steaming voxel terrain which would be fun! I need to finalise the real-time LOD system to work with this and then I can begin making large terrains and test it's performance.

Ah of course. I didn't think about that. I was toying with the idea of making my own widget system using sprites so that I could do this because all of my widgets are going to have textures anyway.

I'm just going to throw this out there - I wonder if we should be able to change a widgets material? For example if I assign the below image to a large panel the image would stretch. However the corners of the image (red dots) should maintain their aspect ratio as defined by the green grid. The other 5 regions of the image can be stretched to fill in the regions between the corners. I've been experimenting with custom widgets and can separate the regions into their individual pixmap's and assign them to their own block to get the desired effect, some effects may need lots of blocks though. But a custom shader that does this would be better I think. Thoughts? I can think of a few others cases where this might be useful. Glow effects, animated textures, etc.

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; }

What code are you having problems with in the docs? Do you have a subscription for Ultra?

No ETA yet but Josh said it is progressing faster than expected. Hopefully soon we will see a small asset editor. (like for a model or a material).

There is no editor yet and I believe Josh said that the price of $7.99 will stay the same if your subscription stays current. I think the price goes up to around 10 when Ultra is more stable.

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.

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.

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.

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!

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.

After months of work on various base classes I have finally started to re-build my game in Ultra. There is still a lot of work to do to these classes (voxel terrain especially) but my aim is to keep the ball rolling by getting them to a workable state so I can build a playable game and then work on fine tuning later. Plus, I find it more fun to fine tune classes when there is a working game at your finger tips rather than just a bland test project. I started off with voxel terrain. Basically the terrain is a cuboid structure with 6 terrains projected onto each face, each one being called it's own world (six worlds). Each face has it's own gravity direction. First I created 8 points to form a cube where the bottom 4 corners are pulled in slightly. The yellow lines indicate each worlds up direction. Gravity is simply the inverse of this. Then I can project a heightmap onto each world. First worlds heightmap: All six: All maps are the same at the moment and the edges need to be blended together so they don't form sharp 45 degree angle slopes. But in some spots the maps line up and the blending is quite nice. This is so much better than what I achieved in Leadwerks and I'm really excited to knuckle down and get the terrain completed.

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

Yeah that'd be great.

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!

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.