Jump to content

SpiderPig

Developers
  • Posts

    2,285
  • Joined

  • Last visited

Posts posted by SpiderPig

  1. 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. :D

    FoundationGravityMap_002.jpg.5207db77392623e4fe0b4966909a82e4.jpg

    • Like 2
  2. 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. ;)

    FoundationGravityMap_003.thumb.jpg.7c1a2bb20dcce54219c3b4283fa595bc.jpg

    • Like 1
  3. 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();

     

    • Confused 1
  4. 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. :P

    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! :blink:

    FoundationMap_001.thumb.png.31e11682a6195258e2d7261af607d81c.png

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

    FoundationMap_002.thumb.png.739d5c76c062d9358d06c995ed5f4c98.png

    Now I need to make sure I can cast these heightmaps back into the voxel terrain.  Should be easy though.  ;)

    • Like 1
  5. 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

     

  6. I'm not sure if the flip of faces for mesh colliders was right or not.

    CollisionIssue.gif.28b55838fdbdff58b4453ef26c77b6c7.gif

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

     

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

    InventoryInUsage_001.gif.b56e8939876fa480010f07602fb17691.gif

    • Like 5
  8. 2 hours ago, Josh said:

    Put the key hit call outside the if statement so it is always called each frame 

    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?

     

    2 hours ago, reepblue said:

    I think my input system fixes this because you're looking for actions instead of raw key presses.

    I still need to convert my system off of WinAPI and this seems like a good reason to start that soon.

    I'll take a look, thanks.

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

     

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

    Crafting_002.thumb.jpg.0050c5f11a6e335d6ec4b55041d44bee.jpg

    • Like 4
  11. Yeah these are the normals shown in blender, they appear correct.  I might remove the top and bottoms caps, although I don't know what that means if something does collide at the top or bottom...

    PhysicsNormals.png.cb4d7687a5711fda684a043606a53c1a.png

×
×
  • Create New...