I was thinking about making a simple voxel based puzzle game and ran into a design question for the coding. If I use an array to represent the voxels, how could I store information for custom objects like doors?
How do voxel games represent objects like doors that can take up more than one voxel of space? What about “L” shaped objects that aren’t rectangular? I assume that each voxel would have an index location of x, y, and z and would be stored in that location in the array.
Thanks for any insight.
For the case of the door, you can have two separate voxels that make up a door: door bottom and door top. If you place a door, place the door bottom and the code should automatically also place the door top voxel above, if there’s room. If not, don’t allow the door to be placed. If you delete either door top or bottom, both door bottom and top should be removed. You can generally use this method for objects that take up a larger amount of space - just compose it of multiple voxel types.
Thanks for the response. I will give that a shot.
Depends on your voxel density. If you’re going for a minecraft-like “large cubes” environment then the above answer is probably the easiest and quickest to implement but you might deal with many exceptions. Otherwise you want to define 2 things, your object’s origin (the root) and it’s density as a separate voxel volume.
Then the rest is basically what you’re doing with collision detection except that instead of a bounding box, you’re using an arbitrary volume and shape.
With this method you could then give a complex shape to any prop, character, vegetation, etc… in a simple binary format where the origin would be, for example, at the bottom center (or define it manually).
Then again, it’s best to experiment various techniques. I’ve used the one I explained above in a rudimentary 2d landscape generator but this would work just the same in a voxel based world. It’s just an extra dimension. : )
You could as well store “absolute” position of non-voxel object as a XYZ triplet (with Vector3 structure).
This. Use the right tool for the right job. Just because you have a hammer does not mean you should treat everything like it’s a nail.
The voxel data structure is specialised for the storage of voxels. I’d consider something like an Octree for arbitrarily-placed generic 3D objects. Or maybe lists for each world chunk. Or whatever suits the way your game works.
1 Like
I was, indeed, thinking of a more Minecraft-like engine as the wording made it sound similar (despite the puzzle part).
I use the method I use because there can be a great amount of doors or other non-voxel objects placed by the player. And because I use ushorts, I can have 65,000ish block types. Having two for a door is a very simple and effective solution. Treating it as a voxel means using the same tile sheet and the same mesh.
Of course, my method is less ideal if you’re dealing with objects that may take up a very large amount of voxels. It depends on what you’re trying to do.
1 Like
Oh, I don’t necessarily think there’s anything wrong with your solution. In fact, it sounds like it fits your problem quite well. I was just saying that you don’t have to do everything the same way in cases where it’s not a good fit, and should consider that before jumping into a solution.
2 Likes
Thanks for the discussion. I’m planning on using larger voxels so making everything a voxel type seems to make the most sense to me.
If I were using more complex objects, it sounds like keeping the voxels and other objects separate would be best.
Out of curiosity, why does the size of the voxels matter here? What kind of “other objects” are you talking about having and what rules will they need to abide by?
1 Like