Following one man's task of building a virtual world from the comfort of his pajamas. Discusses Procedural Terrain, Vegetation and Architecture generation. Also OpenCL, Voxels and Computer Graphics in general.
Monday, June 13, 2016
A simple creative mechanic
For some people, a pencil is all they need to create something amazing. For others, the blank page can be discouraging. It is not an invitation to create, rather a reminder you may not be a creative person after all.
I see voxels as a creative medium far superior in terms of simplicity to anything that came before. They are closer to working with physical matter, your mind just gets what you need to do. If done right, they can be as simple and intuitive as using a pencil on paper. But again, pencils can be quite daunting.
I keep asking myself if there is a way around this. We all like to feel creative. Is there a framework where technology can help? Dumbing the medium down to large boxes to level the playing field worked for Minecraft, but this giving both Shakespeare and the village idiot a total vocabulary of five words. They may have a good time just do not expect Julius Cesar.
What if you are not asked to create something entirely new after all? Drawing with a pencil is not the only way you can feel good about your creative self. Remember coloring books. They remove all the stress in the creative act, but you still feel you are creating something.
Here is the equivalent of a coloring book using voxels:
If you are a Landmark builder you will know exactly what is going on. The shapes are already there, they are just filled with air. A paint tool converts the user brushstrokes into visible matter by applying the user's material of choice.
I see games in the future exploiting this mechanic. My five-year-old kids had a lot of fun filling up the different shapes I set up for them. A game could make building rich objects and structures very accessible and stress-free by just hinting where things could be built, and leaving enough for the player to discover and decide on their own.
Subscribe to:
Post Comments (Atom)
You are correct this would be a neat tool for a resource based game like landmark. Damn, that prefab house/castle is almost finished there is a hole in the wood floor boards that requires more wood to fill, and a hole in the chimney that requires more stone.
ReplyDeleteYes, and better resources will make your house/castle prettier.
DeleteAlso consider the addition of physics. You have to think about what and where to place next. You have to fill the blocks in the right order otherwise unsupported fragments will fall.
Speaking of physics, any opinions on ways to simplify member stress calculations? I doubt dynamic stress simulations are coming anytime in the near future, but fresh static simulations every time a cut is made or material is added could be possible.
DeleteWe did a solution a while ago. It would thin the voxel data until it found a skeleton for the structure. The same thinning process would yield the approximate mass attached to each segment of the skeleton. That in turn could be used to determine fracture points, which would be regular subtractive voxel edits. At some point we will get back to this, but so much stuff to do...
DeleteThat's what happens when you work on the frontier I suppose =P.
DeleteHow difficult would it be to have a plasticine object in Voxel Farm? I feel like bending some object into shape is as easy and more creative than filling in models.
ReplyDeleteI think it could be achieved with the current toolset. The smooth tool can be used to make things rounder, the grow tool to create protuberances, and bending would be a cut&paste using the FFD modifier.
DeleteThe trick is how intuitive this can be. For the filling paradigm it is just clicks of a single tool. It is hard to beat that in terms of simplicity.
Could you use the skeleton-system you've been working on for the structural/stress mechanics?
DeleteI guess knowledge of an existing skeleton could help here, but for most structures you do not have one. We still need a robust method to find it.
DeleteHow the engine deals with the stores of information?, let me put an example; I use procedural generation to create a random enviroment. While im walking through it on a straight line i see new object, new forms, etc.. and of course i choose to interact with them, lets say i broke a tree, so the three stays cut and i keep walking on straight line, so even if i dont see it, it should still exist, then If i decide to come back from the same path i should see this cut three again. How stores this information? is there a limit?.
ReplyDeleteThe engine stores only the changes you do. In the case a tree you have chopped down it would store all the voxels that used to be a tree as air.
DeleteWhen you come back after a week of visiting other distant places, these air voxels are still remembered. They will be written over the procedural tree, making the tree disappear again (this happens before any info is presented to the viewer). You will see the spot exactly as you left it.
Everything has a limit so the question is how efficiently can we store these changes. It is about 0.5 bit per voxel after compression. For something like deleted content as your tree example, the compression rate is much more.
This comment has been removed by the author.
DeleteWhy is it so much more compressive? Is it because the air voxels are lighter? Haha I kid I kid, I assume it's because you don't have to store things like uv maps.
DeleteWhen you say 0.5 bit/voxel, you mean the smallest variant of voxel your engine supports?
DeleteAnd I suspect the tree will be less data because it can detect "No voxels for this tree exist, therefore, tree doesn't exist" so you don't need to save all voxel data for the tree, but instead can just tell the engine the tree doesn't exist, right?
Air voxels do not compress more than dirt voxels or any other material, it is more about how much repetition there is. When you delete content by writing air, the information is very repetitive since all materials written are the same. For this reason this is likely to compress more.
Delete0.5 bit per voxel is for a typical voxel. They are all the same in the engine.
It never gets to the point of telling the engine the tree does not exist. There are a couple of reasons why this is not very practical. First in most cases it is a section of the tree what is removed. Even if it seems completely gone the roots may remain underground. Second, there are some procedural entities that are constrained to a certain space like a tree, but others may span for kilometers like a section of terrain. We still need a mechanic that removes data from the procedural layers.
We never record the existence of the tree in first place. It is put there by a formula. Remembering that we should not put the tree in there would take additional information. It is simpler to assume there is a procedural world layer that can be rewritten by the user data layer.
Just goes to show how little I know =P. Thanks for always answering our questions by the way!
DeleteRegarding user edits, is that 0.5 bits per "uniform" voxel, or does that number include voxels with actual geometry?
ReplyDeleteI would imagine it's hard to get that kind of compression rate if the majority of voxels actually have boundary vertices inside them.
As a side question, do you store hermite crossing info?
I think the geometry gets generated based on the voxels, so it's got very little to do with what shape the geometry has etc.
DeleteThat figure includes all voxels, actual geometry is counted there too.
DeleteIf the content is very noisy, yes, it will compress less. For the majority of voxels to have a surface in them you would need really noisy stuff. The ratio between solid voxels versus surface voxels is usually from 40 to 20 times for typical content.
... and we do not store the hermite data.
DeleteThanks!
Delete(Was out of the country for a couple of weeks, just read this)