It has been a while since the last devlog! Hope you enjoy this one. I enjoyed making it and I have more explosive plans. Let me know what you think of the new video style and don't forget to join our discord if you want to be notified for the demo weekend! discord.gg/eSS2pYU7Nw
At 2:43, I really like that the background for the code explanation is a screenshot from the game and not only a plain dark color. feels more appropriate for the game :)
I'm glad you're actually focusing on performance first for a lot of things! My computer is an absolute potato so I was worried I wouldn't be able to play smoothly!
Will be potato friendly for sure! Long term plan is to have a mobile version with some form of cross play. I love the idea of being able to log onto your pc world when out and about.
One thing I've noticed in these devlogs is that the player movement looks very jerky and the jump seems floaty as well. Maybe some player movement updates would be helpful before a demo release. Great video
Definatly, it one of the main things i need to do before the demo weekend. It was thrown together orignaly just so it was good enough to test the world.
1:00 of course voxel just means volumetric pixel (which in turn just means picture element) so i feel like the hexagonal blocks of planetsmith could still accurately be called voxels. but hexel is fun too
Excellent job! I'm in the hopes this project doesn't go down as many other minecraft clone projects and fail, this one has future and I see it. Keep working on it and it could turn out to be surprisingly popular! But that's just my theory. Cheers.
In my opinion I think the interaction should remain the same way, with being able to place through fences etc. As soon as you did that I was like "Woah thats so awesome I wish minecraft did that" then you said you might change it lol.
There's sthis revolutionary GI tech invented for PoE2 which might work for you too, and it has shocking performance, basically reinventing lighting, Radiance Cascades. It can be made both in screen space and world space, the PoE example is screen space because that's good enough for an isometric game.
an ideas for the double mesh method, so long as the ray mesh and player collision mesh are the same, all you would need is two bits and one mesh data. The first bit toggles it’s use for player collision and the second bit toggles it’s use for the ray. You wouldn’t need to actually store an secondary mesh unless the raycast mesh was different from the collision mesh (which it probably shouldn’t be)
i think it would be cool to have a colored block that can be changed to any color hex value. I'm not sure how it would work in survival game mode setting, but it could be a great building block for building in a creative mode
Might be worth using a GPU buffer/texture where you render all the hexels' positions (either world-space or per chunk?) and then your raycast would just need to be a texture look-up. Hell, you wouldn't even need to render the entire screen, only like a 16x16 texture or less of the center of the screen where the crosshair is. This would eliminate issues with stair hexels and other odd-shaped hexels. For things like grass and flowers, you could render the untextured plane instead so it would be easier to raycast with.
Problem is that prevents raycasting against culled blocks making the laser imposible, also this method is super easy to calculate its blisteringly fast
6:59 you probably already though of this, but since the stair blocks are facing corners, you could set it to position with the back to the nearest corner. That would make placement here easier while still allowing the other corner to be placed against. But I kinda suspect that's what you're about to make possible now with this ray stuff, so I'll watch the rest of the vid now.
There needs to be a "highlight" around the block that you're interacting with (like in Minecraft), or a preview of where the block you're placing will go. Right now it looks really difficult to know where you're digging and where the block is placed.
3:24 Hm, another potential method you could use to determine which block the player is trying to interact with would be to find the block that has the lowest score calculated by (Nearest pixel to cursor distance plus one)*(Block depth), if something is far away it is less likely to be chosen, if the nearest pixel from that block is far away from the mouse it is also less likely to be chosen, however, finding the nearest pixel of each block to the mouse pointer would be extremely slow. This would be pretty much infeasible, but it's worth a shot as it would ensure you don't have really awkward collision like Minecraft, in what world am I trying to hit the tall grass when I very clearly had my cursor on the other block behind it?
Merely because you may need it later: the usual method for different types of collisions is collision masks, or collision groups. I'm not sure if Unity has them but I would be incredibly surprised if it didn't. Either way, it should be a matter of assigning each face to a group/mask while building the mesh, and that becomes a single integer per face (which is probably already being stored by unity anyway) instead of a whole new mesh.
True you can, I could, but this still has the issue where it doesn't work for blocks that are not meshed at all because they are behind another block and are culled. Also i plan to make it so there are no collison meshes as this is currently the bigest bottleneck. (by a lot)
Whilethe laser is cool if you look closer the blocks there is a visible delay. I assume that's because of the low amount of world update ticks. You've said there's only 20 per second. Upping that to at least 30 could help.
@@IncandescentGames Yeah, I'm a game dev myself, so I get it. I of course don't know the exact details of your implementation, but many games use a queue and apply those changes on a separate thread to handle them as fast as possible while not blocking the main thread. That makes the delay only happen if that thread can't catch up to the changes. Multithreading in unity isn't something I have a lot of experience in, so not sure how hard that'd be. I know of a library called "UniTask" that pretty much replaces coroutines and allows you to use the c# async syntax. It also has mechanisms to run on separate threads and is zero alloc. Might be worth checking it out.
Have you put any thought into the possibility of semi procedurally generated animals/enemies for other planets. Like, make the first planet always earth like, so Earth based animals/enemies, but on other worlds, get a little more out there with it, one more interesting reason for people to explore further, maybe bring their new weird animal friends home? -V
Really cool progress! I'm wondering if there was any issues with the raycasting calculations around the pentagons within some chunks, and if so, how you solved that. Also, it would be cool to see if you could generate planets which are "inside out", so it's hollow but the inside edge has trees and grass growing upside down. (I understand some blocks would be difficult because of how they might work such as grass blocks, but I'd love to see it anyway xd)
Inside out planets would work! And yes your right to be worried about the pentagons... currently they can't be raycasted but its not a big issue i just havent written the code for it yet, its no more complex just difrent and wasn't a priority for this video.
Speaking of destruction, will you ever be able to figure out how to allow the player to mine all the way through the planet? I know you mentioned that you have a layer of "bedrock" because as you get closer to the center of the planet, the hexagons get thinner and thinner, so why not just make the layers that become too thin for the player to fit hollow?
It's a shame you aren't gonna be able to go to the center of the planet. Makes sense though, since that would be a hastle, and the way it works with the hexels would have to fundamentally change in order for them to not just be a twig.
i love this and have since around EP1 or 2 but cant help but notice that the player movement seems a little jittery? Possibly because the player is being moved every game tick instead of frame. I really can't tell if this is an issue though and if its not i am sorry for making you check.
The stair block is really bothering me. I haven't tested every possible use case, but isn't a stair step cut corner to corner significantly more versatile than the ones cut as they are, edge to edge? You could then make rings or curves, and straight stairs would just have the rounded character that all the hills have. Part of "the aesthetic". Perhaps both sets of stairs to allow 12 directions of stairs, that would be sick.
Stairs are half baked currently need a lot of work still. I have a redesign i talked about in a livestream it will remove the flat faces and get them to connect when appropriate. On my TODO list and that's half done but not currently working on it.
1:37 Hm, you should be able to get away with moving a few hexels into the future with more standard grid calculations ignoring the spherical warping before having to perform a check to make sure the ray didn't stray too far from the actual hexel it is meant to be on.
I wonder how possible it is to do this using rhombic dodecahedra for the blocks and allowing completely exposed vertices to be truncated. ( or do something similar with cuboctahedra, but i haven't thought that one out yet ) Sounds like an absolute pain to implement but i've been meaning to try it for forever now, just need to get other stuff out of the way The biggest problem i see is having to deal with hexagonal co-ordinates on the GPU somehow and then actually making it efficient But if you can render 5D space on a GPU and not have it explode, surely you can do this
I hope this project doesnt fall into the earth normalisation paradox thst AAA space games so often do, where every planet regardless of size always has 1G.
For raycasting onto objects which don't collide with the player, why didn't you utilize Unity's layer collision matrix? That way the player layer doesn't collide with a non-collidable hexel (such as foliage) and the raycast can still hit its collider?
You still have the problem that culled hexels don't exist in the world. Also this method is a lot faster! I plan to remove collision meshes completely soon!
What happens when you fly through the planets core? How does everything orient as you get close to the centre of everything? Also, it would be an interesting fast travel method to jump into a hole through to the other side of the planet, fall and accelerate through the planets core, then be slowed as you pass the core until you safely pop up on the other side of the planet. it would also be funny if you could get stuck in the core and become soft locked with no way out of the simulated gravity well. Mining the planets core could also be an interesting game mechanic, if you made a crystal or something at the very centre. What happens when you take the planets core? Game over? Portal to another dimension? Or it allows you to fly into space to build a new planet? Achievement unlocked?
you never showed what happens now whenever you try to remove a water block, and, importantly, if you lose the functionality of removing a block on the other side of a water block, which is a useful feature for say, draining pools, or creating a river, or making a river deeper, especially if when removing a water block is instantly replaced by the water around that block, such as in terraria and (i believe?) minecraft.
At the minute it just removes the water block, but in the future i will make it tool dependent (ie you need a bucket or whatever tool i decide to use) outerwise it will remove the block below like in MC. Water doesn't flow yet either its just a transparent block.
calculate radiance for each triangle (voxel) surface async, for example using cubemap view (6x projected camera) either with raster or equivalent ray tracing, for recursive diffuse lighting bounces nice and complex? not if you use normal free orientation triangles as the voxels. so why not automatically calculate a default sphere collision mesh for all objects. that default collision mesh is only for rough first check, you can do accurate collisions then with the triangles. prevents excessive triangle-triangle (pixel-pixel) testing. so why are you not updating the voxels block immediately after edit. queue why. there are some major data structure design issues going on here. spherical coordinates are not worth the hassle logical complexity, keep it rectangular. no matter if the original triangles are generated in spherical coordinates, the most simple is to the results coordinates be in cartesian coordinate system. even if game logic is in spherical coordinates. for graphics gpu reasons. triangles for everyone, no reason to need to resort to different systems for different stuff. design to prevent head-aches.
Yo! to anyone in the comments, I'm looking to bring three of my favorite games back into playable states, by making my own versions. very simple games, but I have zero experience and could use a slight but of guidance.
@@UltimatePerfection you can't make a sphere no matter what you try as squares have zero guassian curvature. You can make a donut though that apears to be a sphere when on the surface.
@@UltimatePerfection watch devlog video one, UV sphere have huge distrotion. At the seams they look more like triangles than cubes (from the side not top down) Everything you build would look weird!