SpiderPig

What's the correct way to store vertex normals in a pixmap so that it can be saved and actually look like a normal map? This is xyz mapped to rgb:

I can't help but notice areas like this. This is exactly what I wanted and got easily with voxels. This is a strong gravity area right to the edge of the world and will provided a sharp transition between two gravity regions. The player can tie a rope too a tree and jump off then quickly fall / land safely in another world.

Got a little side tracked and generated a gravity map. Red is 0% gravity and green is 100% with all the smooth interprolation between them as you approach the edge of the world. This is going to be used in the erosion calculations as well which should give interesting results. I'll add another element to this too - small pockets of reversed gravity where if you go over those, you'll have to be quick to get back down! I might also make some 0% gravity areas around mountains as well. Just for a bit of fun.

Yes he's focused on Ultra right now. If you can work around it, that might be best for now.

You can confirm it's a bug by making a simple application and posting the code in bug reports to see what Josh says about it.

I re-call this issue ages ago when my project was in Leadwerks. I reckon it's a bug but you can try this in C++. I can't remember if you can even call this function like this, but give it a go and see what happens. System::CollectGarbage();

I've been working on the foundation for the terrain. Currently the voxel terrain samples an SDF field to get the basic shape. It only ever samples what it needs to render so it is very fast. But, it posses problems in areas such as procedurally placing foliage, buildings, roads and paths as well as calculating erosion to get nicer looking terrain. While ray-casting the voxel terrain's octree is super fast I can't use that information to place things due to the fact that in the distance lower LOD levels won't give accurate height information. As the player moves the terrain will change, leaving trees and buildings in the air. I could update all these things to match the new terrain heights but that'll involve everything popping and moving around during game which I think won't be nice to look at. What I really wanted to do is create a 3D grid of floats for the entire voxel volume and just use that as the map for the entire volume. But at a size of 2048^3 that is about 3x10^10 bytes. Which is... something big in gigabytes. I can't math today. Subdividing the terrain's octree to store this information (even though it doesn't have to be all rendered at once) will still result in massive amounts of RAM and is just unmanageable. So I think the only way is to cast my SDF function into a small set of heightmaps. From them I can perform erosion, calculate normals maps (pass both of these maps to the shader to get some nice results at lower LOD levels) and use these maps to procedurally populate the world rather than ray-casting the octree all the time. As far as stopping the terrain from intersecting buildings and trees in the distance, I'll have to make the LOD algorithm to be smarter and reduce the poly count in areas where it won't matter too much to be noticeable. First attempt at ray-casting the SDF field gave more of a mask result. And it took 10 minutes to calculate! Got it to work a bit later though. These are top down shots and it took about 40 seconds to ray-cast this 2048x2048 heightmap. I'm pretty sure I can split this into workgroups and give it a compute shader. I will need six heightmaps. Once for each face of the cuboid terrain. This results in a manageable 100MB of RAM / GPU Memory usage. Now I need to make sure I can cast these heightmaps back into the voxel terrain. Should be easy though.

Found a shot of the old inventory made in Leadwerks. Ultra is much nicer.

Just tested this. Button needs to be set to nullptr (NULL) so that it is no longer keeping the widget alive. You need to do both of these to delete the widget. Well, it goes off screen so I'm going to assume it's gone for good. button->SetParent(nullptr); button = nullptr;

Just a few simple operators not working; iVec2 v = iVec2(30, 50); v = 2 * v;//Not Working v = v * 2;//Working iVec3 v1 = iVec3(30, 50, 60); v1 = 2 * v1;//Not Working v1 = v1 * 2;//Not Working Vec2 v2 = Vec2(30, 50); v2 = 2.0f * v2;//Not Working v2 = v2 * 2.0f;//Working Vec4 v3 = Vec4(30, 50, 80, 80); v3 = 2.0f * v3;//Not Working v3 = v3 * 2.0f;//Working

I'm not sure if the flip of faces for mesh colliders was right or not. This is the order I add vertices. It's the exact same order as I use for rendering. 3 vertices per face. If I reverse the order I add these vertices the collision works, I just want to confirm that this is how things should be before I make changes to my code? collision_patch->AddVertex(p[0].x - position_offset.x, p[0].y - position_offset.y, p[0].z - position_offset.z); collision_patch->AddVertex(p[1].x - position_offset.x, p[1].y - position_offset.y, p[1].z - position_offset.z); collision_patch->AddVertex(p[2].x - position_offset.x, p[2].y - position_offset.y, p[2].z - position_offset.z); All those vertices are added to a vector in order and I build a mesh collider like this; I could just reverse the order here too, but still, just checking. vector<vector<Vec3>> faces; auto total_faces = vertices.size() / 3; faces.resize(total_faces); int id = 0; for (int f = 0; f < total_faces; f++) { vector<Vec3> v; v.reserve(3); v.emplace_back(vertices[id]); v.emplace_back(vertices[id + 1]); v.emplace_back(vertices[id + 2]); faces[f] = v; id += 3; } collider = CreateMeshCollider(faces);

Got drag & drop working as well as placing items on your person to expand inventory slots. Only certain items can go on your person and only into certain slots. E.g. the backpack can only be equipt onto your back or your hands. This one expands the inventory by 5 slots. Larger packs will do more.

Hi, I don't think it does.

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

That works for simple cases but with a large project it becomes impractical. There's so many layers of if statements buried in sub classes and methods from all over the place. I think key hits should be auto reset at the end of every game loop, otherwise I don't see KeyHit() being a useful method in large projects. And the call only works once doesn't it, before it resets the hit state? I'll take a look, thanks.

There's an old discussion on this here. To re-iterate, if you check KeyHit() inside an unreachable if statement, press the key, and then later that if statement evaluates to true, the KeyHit() check will also return true. No matter the period of time since hitting that key. I know FlushKeys() can fix that but I believe it also resets the key down stats and makes KeyDown() unusable. Is there a common work around for this is can FlushKeys have an option to just resit the hit stats and not the down states? Maybe an enum flag? FLUSH_HIT_STATE, FLUSH_DOWN_STATE, FLUSH_BOTH_STATES?

Just confirming that seems to have fixed it, thanks.

Still working on crafting. Got locked items showing and items now add to the queue and are crafted one at a time with a progress bar at the bottom. Something's going on with the expansion of the crafting side which I need to fix. It thinks it's wider than it actually is.

Oh right, I thought it was called winding.

What is handedness?