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.
Tuesday, May 28, 2013
Video Update for May 2013
This update sums up a few nice additions done over the last month: the ability to use meshes as brushes for creation and how you can go off-grid.
Youre killing me, all these awesome features and videos, and no way to play around with them! XD. Brilliant work once again.
So, how will you select the brush-models? Will it be something like a tool wheel (Much like choosing weapons in an old FPS), will there be a point and click menu, or will it be through the use of hotkeys?
Furthermore, would it be possible to actually build something, and then make that into a brush? How about Brush scaling? Will you be able to make it so the same brush can be used for different sizes?
Then now on to orientation, do you have a button which toggles snapping to the grid? Or will you always have to be careful with how you place things? What might be an interesting idea to consider, is for the player to be able to set the grid orientation, then they can use that to build straight walls etc. without having to screw around with orientations and stuff, and when they want curved stuff, they can just switch back to free-form editing.
Yes, I was tempted to do that. I rather try it without any visual cue first to see how it feels. In general I don't like adding a new display element unless it is absolutely necessary.
I'm thinking about potential users using the game in sandbox mode to create cities/world like in mc. I like the "wild" approach to place blueprints approximately too, but to avoid too much place/undo, maybe in this case, you could add an option to snap a brush to the last placed in the world.
He did say in the beginning of the video that you could design a brush to do something like that, no idea how that would work, but yea... Without the snapping it would require more skill from the player though =P.
(No edit button >.>) I just thought of another question: Will you also allow for rotations which arent around the vertical (Y?) axis with your brushes? If so, how will you do it?
In the Dark Mod (FPS project I worked on), there is a hotkey (Z for me), so when you're holding an object & it hovers in front of you, while you're holding down 'z', moving the mouse rotates the object (left-right on z-axis, front-back on x-axis; another approach is using WS+AD+QE to move all 3 axes, but using the mouse lets you still the move the player & rotate object at the same time, which is useful) and mousewheel (or pgup pgdn) moves the object towards & away from you to some limit. When you lift 'z', the object freezes in the new position as you walk around. (A 'reset to vertical' key might be good too.)
I find it very intuitive for precisely placing hovering objects at the orientation and place you'd like. So I recommend a system like that, or anyway just mention it as a data-point for you.
Yep. You have to imagine the mouse controls and how it'd translate to brushes, but this is how it looks in-game. http://www.youtube.com/watch?v=eR_0oW1VNSY
Ahoy Miguel, awsome work as always. After your last blog entries I thought myself about simple interface solutions to place blocks/meshes off the grid. Placing them in relation to the point of view of the player, is so simple and still so brilliant, that I wasn't able to come up with it myself.
Beeing a little bit offtopic: I really appriciate your laid-back approach concerning the release and financing of your engine, wisely ignoring the many demands, to put it on kickstarter or make it open to alpha/beta tests. But the last video get me so excited that I have to ask: Is there any chance, that you release something in the near future - even if it's "only" the minecraft-like sandbox without any game mechanics? Thank you very much and I wish you all the best! :-)
Did not expect a different answer but it was worth the try ;-) But do you even still plan to make a game out of it or is your work soley adressed to game devs who can already license it and build their own games based on it? I'm sure there are plenty of reasons, why you keep quite calm about such things, but guess I am not the only one who would die to read something about your longterm goals.
Minecraft was fun before it got traditional game mechanics, its the building that is fun XD. I bet people would already enjoy the hell out of this game in its current state, just building stuff, maybe (if it is finished enough) play with other people, either LAN, or (if its supported) through the internet. Really, usually when I play Minecraft, I play creative anyway XD. (And yes, I am trying to persuade you to release it earlier, since I have difficulty waiting =P.)
This looks insane dude, just magical! Do you have any info on release date and price? Anyway, could you do like a 20-30 minute video of you just walking about in the world as when watching this update I just really wanted you to go off and explore the mountains in the foreground! Anyway thanks dude please reply! :)
That's what I think aswell. Of course the primary purpose of the update videos is to demonstrate recently added features. But nearly in every video there are at least 2-3 seconds the camera is showing a mountain range in the distance or a panoramic view over a forested valley making me think "Please! Don't move around so fast!" :-D
I would love a showcase video demonstrating the pure beauty of the landscape by just wandering through it - specially after the addition of undergrowth, clouds and day/night cycle. I think something like that could massively boost the attention for voxel farm. But I guess for the moment it isn't really Miguel's goal to address the mainstream majority...
Yes Sauerbraten is a constant reference. It is great teach, maybe too complex for average players. If you know 3D or game design, or have a good visual-spatial mind you have no problem picking it up. For everyone else it may be too daunting.
You got little kids playing Minecraft. I wonder if an on-grid, cube-only approach is the only simple option.
I understand the importance of keeping the editor simple and intuitive. I would caution you, however, to not sacrifice the potential power of more sophisticated editing tools in favor of a purely simple solution. Minecraft's place-on-the-wall individual block based system is enough for most people, and maybe all that can be handled by others. But often it is not sophisticated enough for someone who is agile with computer software or spatially minded. In the case of Minecraft, a number of community tools and addons have been made to cope with this, but, being 3rd party, they are often not very well integrated. If you were to give your interface a range of tools from the simple and intuitive to the advanced and sophisticated, I think it would give your engine something unique – a simple while powerful sandbox with a learning curve only for those who wish to take advantage of it. Why not have a system in which little kids can build a structure out of blocks alongside an architect sculpting complex forms?
Yes, maybe there is no other option than to provide a wider range of tools, and people will stick to what they can use. This is always an option, still to some degree it means we have failed at finding an universal simple interface.
We can debate whether such interface is even possible. Odds are we are set to fail on this one. It does not mean we should not try to minimize the set of tools.
The problem I see with a range of tools is that the overall complexity of the system does not come from the tools you use, but from the all the tool options you have.
Let's say a game using this is out and you start looking at the top 10 user creations. In the back of your mind you will always have "I bet this guy is using one of the good tools I don't know how to use", even if what you see is built with the basic tools. When you don't know you just assume the worst.
This creates a barrier. In your mind you now need to learn and get used to some UI to be good at this game. If the tools are so simple nobody has to explain them to you, you intuitively know you will be limited only by imagination. This is a very inviting feeling.
Then maybe the more advanced tools should be hidden from the default game and manually enabled by the advanced user? I don't see this as ideal because it creates even more of a divide between advanced and basic users. However, it does seem to be successful in Minecraft, where some people are content with the original system while others use addons to achieve what they want. In my experience, people using the original and the more advanced modified editors are able to work side-by-side to create ultimately equally complex constructions. The difference is often the time it took them to get there.
By all means, the 'simple' tools should be able to create anything that the more complex ones can as well, but certain constructions may call for functionalities that the complex tools are better suited to provide. Ultimately, it comes down to efficiency. A user can place every stone like in your demo, or pull out a wall tool and just throw it the path they want. Likewise, someone could simply spawn in a tree, or build it branch-by-branch, or open a grammar editor and put in their code. All three methods could provide the same result ultimately, but it is a matter of how much control the user wants over the result while keeping the time it takes for them to achieve it reasonable, even if it requires more knowledge on the user's part.
As usual you are doing amazing work! I wish I would have found your engine before we locked into Unity. Keep on inspiring i.e. kicking us mere mortals with voxel dreams in the pants!
Looks insanely easy to use. I would echo the previous reader's comment though, perhaps adding a wireframe preview of the brush before adding would speed up positioning. (even a toggleable one?) Particularly as the mesh brushes get bigger and the datum position is less obvious... Apart from that, awesome work, as usual.
There is purity to the simplicity of your current model for editing, yet I think more is warranted.
A sandbox, or any tool's, ability to draw people into content creation is really dependent upon WYSIWYG fidelity. More advanced settings like rotational chaos can be hidden away, but knowing what is going to happen when you click goes VERY far into getting people comfortable using it. Otherwise, you'll need to spend time and resources on the building the opposite function, unlimited undo, when it doesn’t do what is expected.
I’m sure you are already thinking about many of the below points, but wanted to mention some of my thoughts, as someone who gravitates toward content creation tools and building content within sandbox games:
__Alignment and Precision settings for Brushes__
The off grid ability, and the randomization when instancing the brush are awesome!!! When building ruins, it will create some amazing stuff, but sometimes you need to build the sparklingly perfect marble 'temple of the god's', and that requires alignment and precision. To that end here are a few settings for advanced brushes that I think would leverage what you’ve already done:
>> Ghost or Bounding Box Brush placeholders - I know you don't want to add too much UI for an overlay, but I do think that displaying a ghost or placeholder of the brush selected and where it will be placed will be well worth the effort and overhead, when it comes to getting people both old and young, novice or advanced to use this engine to create content.
>> Alignment & snap-to existing/recently placed brush strokes - Akin to your ‘cornerstone’ concept, or building Hadrian’ s Wall. Place a brush and easily place the next one right beside it or on ‘top’ of it, in an aligned way. Without that, you will limit what people without becoming inordinately frustrating, and ease of use should be paramount.
>> Settings for Algorithmic positional/rotational chaos - Alignment should still work, but a setting for how much chaos should be applied will introduce all those wonderful details and offset bricks so everything isn't too "perfect", much like your procedural content creation algorithms do. If we set this setting to 0 it's perfectly aligned, if it's 100 it's completely random each time. A setting of 3-5 might be nice for a new brick wall.
>> Settings for Algorithmic Age/Decay - Similar to what you showed with the new instances being slightly degraded upon placement, being able to set this would allow us to get much more use out of existing brushes, as we could build both the clean and the ruined version of things using the same brush, just with different settings. 0 = no decay, 100 = a crumbled mess barely recognizable (algorithmically weighted toward the 'down direction', ie. what remains from the base of a weathered roman pillar)
__Copy and Paste Ideas__
MCEdit's selection tools work nicely for copying instances of data for naming and pasting later, in game, it would be a floating drag-able bounding box.
If the world grid is kept to some broad value like 1 meter we could build things up into the air with space around them and then either use a bounding box approach, or you could use cursor's position when pressing a button to search the voxel data, starting at the cursor intersection and it goes until it is stopped by empty voxels on all sides, with a timeout/distance limiter. (Of course this is a gross simplification).
P.S. if you can nail the ability to share these brush/template items easily throughout the world or with downloadable sets of files, you will RULE the procedural/sandbox universe... and I'll release a medieval brush set soon after release. :)
------
Awesome work, as always! What an amazing update for May! and 'lo June approach'eth, I'm so excited!!! Loving all of this!!!
Because your goal is to create a game, you can give progressivly tools to the player by using experience/levels. Tools to be a better architect can even be build by finding materials. A new character can pickaxe/dig/harvest/construct low quality objects and build structures without guides and helpers. Structures needs a certain amount of materials.
Time after time, player will gain experience and he will raise skill in construction. (with more tools). Exemple: - the player can build a set square. the game show now a ligne to represent alignment.
From a certain level, you can give the possibility to create blue print. -the player must build plots/paper/stylo. he place 4 plots arround the existing construction and click on one plot. The construction is copied on the paper and create a blue print. He can name the creation, and the game indicates materials needed on the paper too. Now he can share blueprint paper with others player.
-you can find rare chests in caves with specials blueprint on them...
Hi, I have one question, will be subtraction with brush added?
Than about content creation, I think the best approach will be to allow player to create rough model, than offer tools for precise editing (like normal sculpting), than allow player to save selection and than use it like brushes you've presented.
On the subject of more precise/advanced tools, I have tried the Sauerbraten program, and it really didnt feel like a game at all, the interface was so complex that you actually had to learn it. I personally am completely for it being simple, I believe that, because it is going to be a game, and not a tool, the extra time spent on it is perfectly acceptable, and as mentioned before, mods can potentially be made that have better tools. Simplicity is exactly why I have spent so much time in Minecraft, and far less time in Sauerbraten, sure, in Sauerbraten you can do a LOT more, but minecraft is just: I have an idea, lets make it! And the only tools you really use, is your movement, sometimes crouch, generally left and right mousebuttons, and the scrolling wheel (And space to jump), there is no moving through menus to get what you want, no going through help-pages to see what what tool does, I personally would prefer less accuracy, slowness and simplicity over accuracy speed and complexity. But that is just my opinion =P.
Both myself and my 5 year old son build things in Minecraft. I build cathedrals, towns, and replica's of his school. He builds huts and 5 story brick "hotels" with a bed on each level, on my iPhone :)
We must keep in mind though, that in Minecraft the simplicity of the square voxel allows for a UI shorthand that won't be possible for here. In Minecraft, you hold the cursor over one of 6 sides of a block, which highlights itself as feedback, and the block of your choice is either created on that side, or the current block is destroyed.
When Miguel was building only with blocks, the same concept applied somewhat, but even then I noticed that it was slightly more difficult to "know" what was about to happen when he built or destroyed voxels, though the red highlight helped greatly.
As soon as the brush can be any shape, this becomes problematic. Perhaps it would help if the red highlight would actually display the intersection of the "bottom" of the selected brush and the current terrain. But even if that was the case, orientation is still an issue, and it matters in oddly shaped brushes.. like a house.
With the awesome power of brushes of any shape, size and orientation, the old Minecraft way of doing this is inadequate. Orientation now matters greatly, and even Minecraft began having problems getting orientation right, with only 6 sided cube voxels :)
Also, Minecraft has a fixed world grid as well, one block can only replace one full block. Where as a misplaced pillar segment in Voxel Farm might blow out the terrazzo floor, a wall and the carefully built planter on the far side.
Miguel has build some serious power into this engine with the ability to use brushes of these types... and don't get me started on the awesome dynamic noise 'decay' upon placement! It would be a shame to have its usability hampered because we have a limited ability to place things right where we need them to go.
I think additional effort to keep it simple, yet not impede the usable power inherent in these brushes will be well worth the effort.
For my money, I still think that a ghost overlay of the current brush with modifiable orientation will still be necessary, at some point... that and the basic snap vs. free alignment modes.
I agree with the ghost thingy. And I will trust Miguel to find a nice balance between tool-ness and game-ness =P.
But anyway, on your points: I have nothing against precision modification, however if you add too many tools in there, it basically becomes 3D photoshop, all these things which are nice to have, but you really dont use the majority of it ever. The tools that get chosen for the final product should be often used, versatile and easy to use. The only tools I can currently think of which are necessary are: Placement (of brush) Removal (of brush) Selection (of brush) Scaling (of brush) and rotation (of brush)
Now, these are already five different tools, which will already require hotkeys etc. Then you would also need a key to toggle the grid, and this would probably happen either based on what you are holding your cursor on, or where you are looking.
All of this is quite a lot already in my opinion =P, but these are just the things which I would see as important, are there any others you might need? (Pointed at anyone who reads this) I ask, so I can actually see what people do with their stuff, as I am not a very artistic person =P.
I agree with everything said here, even if these are apparently contradictory views. It is a difficult problem.
To me it is about having many different brushes and only one very simple tool mechanic. Depending on the brush you pick the entire behavior of the tool will be locked down. I want the brush to feel intelligent, so things like snapping or rotation can be left to the brush definition.
Finding new brushes and experimenting what they do can be part of the gameplay. Let's say you go into some ruin city and do a quest there. The reward could be a few brushes that allow you to easily replicate the look of the ruins on your own.
These ruin brushes would not have any form of snapping to previous strokes and would be fully off-grid. If you wanted to build straight with them you will certainly get an aneurysm somewhere. But dilapidated ruins are not meant to be straight. So if you are building a new perfect temple for the Cube God, you better use the squeaky clean set of brushes, not the ruin brushes.
The community should be able to contribute new brush sets. This would be a collection of meshes for the brush profile and some rules about how the clicks should be interpreted.
Once you get a new brush, you should take some time to get used to it. This is to understand what look it produces, also how it reacts to your input. I think we humans are good at learning that kind of pattern. It is something you cannot explain in a manual, but you just get as soon as you try it a few times.
Still the input that is available to you remains the same. There is no psychological pressure because you are not learning a new tool mechanic. This is what I believe makes the system simple.
Note the system already features Undo. This is a must if you are meant to experiment. You actually see me trying things and quickly undoing them in the video.
(BTW, brush is not a good name for this, but it will do for now.)
Mould? =P Anyway, I kind of like that idea, but I do suggest playtesting it first before fully going for it, it is so different from what most people do, that it would be smart to do some research into it =P. Then a future question: In the final game, will these brushes cost resources? Like in Minecraft? Or are they free to use? (Some form of build energy would also count as resources in this case)
I agree with everything above too! Thanks for your further thoughts on this Miguel, I like the way you are defining it, and think you'll do great making it easy to use. keeping the tool simple and allowing the 'brush' to define those characteristics could be cool.
I still wonder if some of those chaos type things like random offsets or decay, that you can so easily apply when instancing the voxels would still be good to have as modifiable advanced settings.
If someone makes a bunch of great brushes for different types of rocks and stones, it would be nice to be able to "paint" them into a scene with some of that procedural randomness that the engine already excels at, almost like we're painting with Procedural Voxel creation with that brush.
I do think the pure manual placement methods will be fine as a start. But sometime it'd be fun to play god-mode laying huge swaths of stones to create an old road down the mountain... but I can understand your idea of putting that type of complexity into custom 'brushes' that can be designed to deal with the inherent issues with that idea :)
Should take a look at Kerbal Space Program and how they position things to build a spaceship. You have constrained vs free placement, attachment nodes, rotation and it is all pretty simple to figure out. Not sure how much can be used but worth taking a look for inspiration.
The problem with Kerbal Space Program, is that unless you use the symmetry functions, it is usually quite hard to place parts precise, which is why so many people want more tools.
Just keep in mind that to some extent, personal expression might be limited by too strict tools/brush rules. Take Minecraft for example, where a lot of magnificient architecture is the result of diregarding the building blocks original intent, i.e. using hatches as decoration. I believe it should be possible to put down ruin brushes perfectly aligned, because someone might develop an architectural style based on that mix of ruined and rigid.
Now imagine you are trying to invent Minecraft and got to the point where you explain to people they can only do cubes. That's very limited and strict. Still people got on board and created amazing things. Even in the vanilla version.
If you instead look at Sauerbraten (which I think predates Minecraft) or the game Love by Eskil Steenberg, they are brilliant interfaces which give you a lot of freedom and options... but they did not have mass appeal. I think that means something.
Ooh, Love was an interesting game for the time I played it, I had no idea what was going on, didnt bother to look at any help files, but just screwed around, it felt like I was in a world left behind by some old civilization, and I was just trying to make sense of it all, and seeing what did what, sometimes I had no idea what I just did, for example, whether the water was actually rising because I changed the path of that beam? Or because of some random effect? The confusion in this game was fun surprisingly enough.
RTS games have a bit more leeway when it comes to menus though =P, I cant remember what the interface looks like though, so it might be good, but just saying just in case =).
Hey, you don't want to make selection saving and using it like brush?... I think having this feature and having simple cube brush could be enough (for beginning)
I'm curious about your thoughts on voxel based player characters or props, or other sorts of things that would be more dynamic in terms of movement and physics. I know I have seen grass and leaves blowing in the wind of your worlds, but how about interactions between voxel based objects like tools and the environment. Would an implement like an ax or something only act as a brush in the gameplay setting or could it be made of voxels also? I think this would be exciting, especially in terms of crafting highly customizable tool and weapons. Is this sort of thing a possibility?
I'm no expert, but Miguel has touched on this in the past. The impression I got was having voxels as entities, and even the application of physics and moving voxels parts and stuff like that is a difficult set of challenges, and probably has many added factors that must be hurdled.
The voxel engine he has created generates a lot of data quickly, and to keep voxels lean and performance oriented there are storage and access mechanisms required to do it fast.
For me, I think about voxels as a 3d array of pixels. Think about a circle made of pixels in a paint program. To transform that pixel circle to a new position each pixel must be updated and transformed twice, for both the starting location and the end positions, when you do this you must do many separate calculations, per pixel. Now imagine scaling the circle to an elipse, the calculated approximation must be done to find the right location, and depending upon the resolution there are lots of calculations you'd have to do.
Many early demos from the demo scene used voxels, with a fixed grid and just using the music or other animations to make it seem like it was a tunnel or waveform you were looking at. That requires tons of calculation, compared to the way many "regular" games load the mesh scene and then let you move around within it, moving just entity values and then rendering the results.
I think the ideas you are talking about are before us in the future, but I would be they are quite a ways off.
Like Jonathan says, it is very hard to transform and animate voxels in their native form. There are some projects that show some success at deforming sparse voxel octrees.
I think I have cracked this. The key is not to use the voxel form, but to convert to polygons first. Assuming you manage to find a skeletal representation of the voxel content, you can have the resulting mesh deform following changes in the skeleton. This is how polygon-based game characters work in games.
Let's say you create a voxel dog. The system can identify this is a quadruped. It can find a matching skeleton for that structure and apply a set of premade or procedural animations to that skeleton.
If you create an axe or a cross, you will probably have the same skeleton for both, which is kind of alright I guess.
In general the idea is to have a set of skeletons on one side and a pattern matching algorithm that will match a set of voxels to a skeleton. If no skeleton is found, it means the system does not know how to deal with that object.
Once a skeleton is established you can refine its behavior a little more. For instance, you may have several animations for quadrupeds some may apply to cows, yaks and triceratops but will not do well with wolves and dogs. So you would need to filter that.
Would any of that facilitate a more realistic handling of trees in-game? I.e., chopping them down, chopping off limbs, etc.
Even though it sounds very exciting to use voxels for character/objects, wouldn't a conventional polygon model of a dog, cow, axe, or cross for example remain far easier to implement? And look better/more realistic?
Applying physics to a large object like a tree or a wall is a pain in the ass. I am not going there for now. You always have the option to not have voxel trees at all. I am not sure voxels are a good fit for trees if you want a realistic behavior when you chop them.
Like you said, a conventional polygon model for characters and objects would be far easier to implement. The thing is most people are not able to create with polygons. Somehow you need to make this accessible.
Voxels help here. Let's say you want to build some sort of menacing quadruped to guard your ruins. You could start by picking a skeleton for it. Then you could use a brush that does muscles and hang some meat on the bones. The brush would be smart, so it would create a nice muscle definition depending on where you paint.
Then you could use a brush that adds fat, or maybe you will skip this one at all since you want this creature to be very lean.
And last you would use a brush that adds skin and hair. This brush would be only a few voxels thick.
Voxels are well suited for this kind of layered constructs. Once the creature is done it will be stored and rendered as polygons, but all the information that came from the voxel layers (the bulging muscles, the blobs of fat) will be there.
Do you think this kind of stuff will ever be in your game? Because that sounds AMAZING! XD. And I wouldnt be surprised that if you set your mind to it, you could find a (relatively) easy solution to the whole physics problem =P.
this Looks great. love that new Feature, you could really build nice neoithic looking temples or monuments with that, or ruins. however if i was to build a luxorious temple or building, it would be good if everything is perfectly symetrical and smooth looking. will this be edited too ?
I suggest you read the rest of the comments here, but since I know how annoying that can be (to read a lot that is, the comments are actually quite interesting): Basically what Miguel seems to be planning, is for each brush to have its own behaviour, so not just its own look, but it might snap to things or look more pristine. This basically means that some brushes will be great for natural things, or things that have been exposed to nature, while other brushes would be great for human made stuff. I might be wrong in the interpretation though.
In the long run, are you planning on hiding the voxel grid altogether?
I mean you'll want to retain snapping to the grid (or to the cardinal directions, gameplay-wise), but in the video you show that you can still manipulate the raw voxel grid that underlies the brushes. Is the final goal to do everything with brushes, with the grid just being the substrate that supports them?
I think you could get very powerful control over brush placement with only a few modifiers: free placement (like when you're building the circle), "cardinal snap" (like the slabs), or "snap to neighbour", where the edge of the current brush aligns with whatever's next to it.
I'm not sure how easy it will be to calculate the edge of an object once it's been "painted" into the scene as voxels, but it would be a powerful tool if it's practical.
I agree Kagato, and those three really cover a lot of functionality. I think modifier keys is a good option for keeping the tool inherently simple.
I'd also suggest a rotation modifier with either mouse or key's to adjust pitch/roll.
I just realized there is another editing paradigm used in other programs, rather than the single click edit Migue ha shown. The other is a two-click place/adjust/set function, which could be toggled on/off as a precision mode by something like the caps-lock, with the default behavior being simple 'snap to grid' no adjustment (easy-mode) behavior that he already has. In advanced mode it could work like this:
- Click ONE - Sets the anchor fo the brush placement. (adhering to the snap/free/snapNearest modifiers)
- Precision adjustments pitch/roll/rotation are made, - either by keyboard WASD/QE keys -or by Mouse movement.
- Click TWO - Sets the brush and instances the voxels.
--------------------------------
Just a different advanced mode model that might be easier to work within without hampering novices with these features... yet still allowing precision. I'm sure some programs have implementations like this that could be modelled after.
Great comments and great stuff from Miguel as always!
I know this is slightly off-topic, but I'm really curious about something. In the future, will it be possible to have round worlds? Like Earth, a massive sphere, with all the top surface buildable on. There would be a center of gravity, so no matter where on the sphere you are on, you're always attracted to the center. Just think, someone could make a replica of earth, with jungles, forests, the pyramids, etc.
Also, possible beta-test/release date? Thanks for reading!
It is possible to have rounds worlds now. I am not very interested in that however. I still need to make a small patch of flat land interesting, this is the challenge. Then we can see about making huge spaces interesting.
What makes Earth appealing is not that is round. It is the many cultures, cities, biomes, etc. Even then it is a very big and boring place for the most part.
So the topology does not matter much. It could be a sphere or a doughnut, what matters to me is what is going on these places.
Actually, a doughnut WOULD be more interesting, since, if you are on the inside, you can see another piece of land on the other side, and go "Ooh, that looks interesting, lets go there!" =P But I understand your point. Also, something I thought I posted, but apparently didn't make it to the site: You can also make the illusion of it being a round planet (As long as you don't add space travel), by simply making the world wrap around at the edges =P.
Yes, a world that wraps around the edges is a doughnut.
This topology provides a finite, limitless space, pretty much like a sphere. Without a space view, you don't really have to render the whole doughnut. People experiencing this would would have to be very smart to figure out what kind of topology it is.
Erm, I didn't mean to create the illusion of a doughnut planet, as you would still have to be able to see the planet in the distance if you are on the inside =P, what I meant was to create the illusion of it being a spherical planet. The only way people could figure out the world was flat, was by checking shadows, and comparing sun-sets and sun-rises =P.
Reading the doughnut pieces reminded me of halo. I'm not sure if you are a fan of the halo series (the books primarily), but it would be awesome to build a halo and be a forerunner. Wow, my mind is swimming with the possibilities now. Miguel, I admire your work extremely, and I am glad you started ProcWorld in the first place. Thanks for being awesome!
What about a massive Stanford Torus with terrain inside of it? Following a space-themed gamemode. Or not. I could imagine a game entirely about being inside of one such space station.
If the goal were truly to create an interplanetary sandbox, it might make sense to have contiguous 3d voxel (low detail) representations of planets for space views and then switch to flat mapped terrain when editing a planet's surface.
With hex tiles, not all of them could be hexagonal. Assuming an icosahedral structure, there would have to be 12 pentagonal tiles among the hexagons for a complete sphere. With triangles, on the other hand, there would be corners (again, the number being 12) where five as opposed to six join. The question is, is it better to have all of the tiles have the same number of sides, but have corners where varying numbers of panels join, or the other way around?
The concern is that someone happens to build a house centered on one of these corners, and because all of the angles are slightly less than 60* (or 120*, whichever scheme is used), the walls don't quite align after the player goes all the way around with 90* corners. I should think that having a voxel grid that isn't 100% rectilinear is highly undesirable, so maybe the only way to solve this is to have so many tiles that the distortion amounts to less than a voxel. Of course, in the real world on a fully 3d sphere this is just as much of an issue, but only noticeable for large constructions, and as the Earth is (practically) a perfect sphere, the geometric phenomenon is global. The goal in a game is to make this just the same, with it happening equally whether on the corner of tiles or inside of one. If the world were represented by tiles of an icosahedron, really weird things would happen near the vertices. What it comes down to is that Euclidean geometry does not play well with spheres. It is a dilemma as old as the basic understanding of the Earth being round.
Yes you are right about this. For a sphere tiling you would need to sprinkle some pentagons too. http://upload.wikimedia.org/wikipedia/commons/thumb/3/39/Truncated_rhombic_triacontahedron.png/600px-Truncated_rhombic_triacontahedron.png
Like you said, I would tile at a frequency that is enough so the angle difference at a corner is not noticeable at plain sight. The voxel space itself would be warped, either by making upper voxels larger, or by distorting voxels along the edges. Either way you need massive planets. I don't think you could do a body like our Moon, it would be too noticeable.
Why not make the voxels count as the most basic shape in computer graphics, Triangles and/or prisms They can represent any of those shapes, just how you set up the corners and angles of the triangle would change the fields perspective.
Because that is completely different technology and graphics cards aren't designed to do that. It has been done (http://code.google.com/p/efficient-sparse-voxel-octrees/) using CUDA/OpenCL, but it is still limited and the GFx card doesn't have the optimizations it needs. With that demo, on my relatively average Nvidia card, a reasonable resolution runs at 12 FPS and that is for a very small scene. It could improve, but far better performance and comparable detail can be achieved with polygons.
Anyway, for something like the Moon or even smaller (an asteroid?) What if the planet were represented by a single, solid voxel grid. Now, this is not ideal for building, where someone wants Down in the editor to be Down towards the surface of a planet. When someone starts to edit, it creates a new grid where all of there changes exist. It is rectilinear and has a fixed orientation. When extracting polygons, the planetary voxels are mapped to the new grid and mixed with the player's changes before the final polygon mesh. My description is a bit convoluted but that's one way I could see it working.
Sphere is interesting, but it wouldn't be one massive voxel grid with changing gravity. It doesn't really make sense. A more sensible solution would be to have triangular sections of flat voxel space. The polygon extraction algorithm could be fixed so that it can seamlessly render the edges between voxel grids at different angles, and as for the curvature, it could be done simply by distorting the resulting polygons to a spherical form when rendering.
Also, leave the making of an entire Earth replica to polygon or point-cloud technologies. Google Earth has practically done it already, although with not as much detail. Sure, if you wanted to go to a specific place and edit there, the data could be translated to voxelfarm.
And last I checked, Miguel was already aware that fans want to see a release. You don't need to keep asking this. He is going at his own pace, and the last thing I would want, personally, is an inferior product that is rushed.
Your thoughts on the sphere are interesting, definitely changing how I see things. Also, I never asked him to hurry, I'm just severely anticipating playing with the engine. It looks absolutely incredible.
Miguel, I have a question for you, regarding rotation of objects in the voxel space. In raster systems, things often cannot be rotated too many times without becoming distorted, with what once was a smooth edge becoming more like the teeth of a saw blade. However, the system you use stores additional information about angle and position of the faces of the voxels, giving sharp edges and flat surfaces when needed. Assuming no details or gaps thinner than 2 or 3 voxels, would this be enough information to take a region, rotate it, and map it back to the same grid, without losing or 'corrupting' any detail?
I myself being a wee bit of a programmer, am just astonished at what you have accomplished on your own, Miguel. I hope you go far with this project, and make it the next big sandbox engine out there!
Any plans of incorperating your L-System objects into the brushes ? Or perhaps as a large macro brush or sorts (it might need some dialog boxes for parimeters).
Yes, this is how I see brush scripting to happen. I don't think I want dialog boxes, the brush code has to be smart enough to figure out the expected behavior from the context.
Here's how I see more powerful editing tools working in a game. In a complicated, professional program like Blender, just clicking around often gets the user nowhere, or causes unexpected things to happen. It is when they go to the manual that they learn all of the commands, modifier keys, and dialog boxes they need to do what they want. In a game, the basic controls should be very simple and intuitive. However, the menus and key actions should all be there. The player should feel encouraged to chance upon these options, but not forced to use them. And if they are truly not comfortable with using these, they should simply be able to ignore the buttons that trigger them and use the basic controls, without having to turn any sort of 'advanced' mode on or off.
will the controls be changeable, i can only Play with using the arrow keys xD Thi Project Looks really good, do you have any estimiation on when Alpha Version could get released?
I am totally for changeable controls, but just a suggestion: Try to learn to use the WASD system, it allows you to play far more games, and also gives you way more buttons to play with =P.
So, basically first you put your middle finger on the W, your ring finger on the A, and your index finger on the D. This will take care of your left(A), Forward(W) and Right(D) movement, now, if you need to move backwards, you will just move the middlefinger over to the S for as long as you need, and then move it back to the W.
Using the WASD keys often leads to a more comfortable experience when playing games, it is ofcourse no requirement, and using the arrow keys is equally viable. But I put this up just in case you do want to use the WASD keys =P.
Youre killing me, all these awesome features and videos, and no way to play around with them! XD.
ReplyDeleteBrilliant work once again.
So, how will you select the brush-models? Will it be something like a tool wheel (Much like choosing weapons in an old FPS), will there be a point and click menu, or will it be through the use of hotkeys?
Furthermore, would it be possible to actually build something, and then make that into a brush? How about Brush scaling? Will you be able to make it so the same brush can be used for different sizes?
Then now on to orientation, do you have a button which toggles snapping to the grid? Or will you always have to be careful with how you place things?
What might be an interesting idea to consider, is for the player to be able to set the grid orientation, then they can use that to build straight walls etc. without having to screw around with orientations and stuff, and when they want curved stuff, they can just switch back to free-form editing.
Selecting a different brush or block type will be left to the application. What you describe are all good implementations.
DeleteI have now a button that toggles the snap-to-grid.
Can be cool to see the brush by using wireframe/outline or ghost effect before to place it.
DeleteYes, I was tempted to do that. I rather try it without any visual cue first to see how it feels. In general I don't like adding a new display element unless it is absolutely necessary.
DeleteI'm thinking about potential users using the game in sandbox mode to create cities/world like in mc.
DeleteI like the "wild" approach to place blueprints approximately too, but to avoid too much place/undo, maybe in this case, you could add an option to snap a brush to the last placed in the world.
He did say in the beginning of the video that you could design a brush to do something like that, no idea how that would work, but yea... Without the snapping it would require more skill from the player though =P.
Delete(No edit button >.>)
DeleteI just thought of another question: Will you also allow for rotations which arent around the vertical (Y?) axis with your brushes? If so, how will you do it?
Yes, working on that. This is how you could do a sloped roof for instance.
DeleteIn the Dark Mod (FPS project I worked on), there is a hotkey (Z for me), so when you're holding an object & it hovers in front of you, while you're holding down 'z', moving the mouse rotates the object (left-right on z-axis, front-back on x-axis; another approach is using WS+AD+QE to move all 3 axes, but using the mouse lets you still the move the player & rotate object at the same time, which is useful) and mousewheel (or pgup pgdn) moves the object towards & away from you to some limit. When you lift 'z', the object freezes in the new position as you walk around. (A 'reset to vertical' key might be good too.)
DeleteI find it very intuitive for precisely placing hovering objects at the orientation and place you'd like. So I recommend a system like that, or anyway just mention it as a data-point for you.
Sounds interesting. Do you have a video that shows that?
DeleteYep. You have to imagine the mouse controls and how it'd translate to brushes, but this is how it looks in-game.
Deletehttp://www.youtube.com/watch?v=eR_0oW1VNSY
Ahoy Miguel, awsome work as always. After your last blog entries I thought myself about simple interface solutions to place blocks/meshes off the grid. Placing them in relation to the point of view of the player, is so simple and still so brilliant, that I wasn't able to come up with it myself.
ReplyDeleteBeeing a little bit offtopic: I really appriciate your laid-back approach concerning the release and financing of your engine, wisely ignoring the many demands, to put it on kickstarter or make it open to alpha/beta tests. But the last video get me so excited that I have to ask: Is there any chance, that you release something in the near future - even if it's "only" the minecraft-like sandbox without any game mechanics? Thank you very much and I wish you all the best! :-)
I won't put out an engine demo for now. If there is an alpha or beta of something, I think it has to include gameplay.
DeleteDid not expect a different answer but it was worth the try ;-) But do you even still plan to make a game out of it or is your work soley adressed to game devs who can already license it and build their own games based on it? I'm sure there are plenty of reasons, why you keep quite calm about such things, but guess I am not the only one who would die to read something about your longterm goals.
DeleteI am making a game for sure. Everything you see in the tech as a general feature is a key part of this game.
DeleteIt could easily be a tech demo or a benchmark,no gameplay needed.
DeleteMinecraft was fun before it got traditional game mechanics, its the building that is fun XD. I bet people would already enjoy the hell out of this game in its current state, just building stuff, maybe (if it is finished enough) play with other people, either LAN, or (if its supported) through the internet. Really, usually when I play Minecraft, I play creative anyway XD. (And yes, I am trying to persuade you to release it earlier, since I have difficulty waiting =P.)
DeleteThis looks insane dude, just magical! Do you have any info on release date and price? Anyway, could you do like a 20-30 minute video of you just walking about in the world as when watching this update I just really wanted you to go off and explore the mountains in the foreground! Anyway thanks dude please reply! :)
ReplyDeleteThat's what I think aswell. Of course the primary purpose of the update videos is to demonstrate recently added features. But nearly in every video there are at least 2-3 seconds the camera is showing a mountain range in the distance or a panoramic view over a forested valley making me think "Please! Don't move around so fast!" :-D
DeleteI would love a showcase video demonstrating the pure beauty of the landscape by just wandering through it - specially after the addition of undergrowth, clouds and day/night cycle. I think something like that could massively boost the attention for voxel farm. But I guess for the moment it isn't really Miguel's goal to address the mainstream majority...
It reminds me of Cube Engine. They have http://sauerbraten.org/, fps, where you can edit level in similar manner in multiplayer...
ReplyDeleteDude your face is creepy no offence 8)
DeleteYes Sauerbraten is a constant reference. It is great teach, maybe too complex for average players. If you know 3D or game design, or have a good visual-spatial mind you have no problem picking it up. For everyone else it may be too daunting.
DeleteYou got little kids playing Minecraft. I wonder if an on-grid, cube-only approach is the only simple option.
I understand the importance of keeping the editor simple and intuitive. I would caution you, however, to not sacrifice the potential power of more sophisticated editing tools in favor of a purely simple solution. Minecraft's place-on-the-wall individual block based system is enough for most people, and maybe all that can be handled by others. But often it is not sophisticated enough for someone who is agile with computer software or spatially minded. In the case of Minecraft, a number of community tools and addons have been made to cope with this, but, being 3rd party, they are often not very well integrated. If you were to give your interface a range of tools from the simple and intuitive to the advanced and sophisticated, I think it would give your engine something unique – a simple while powerful sandbox with a learning curve only for those who wish to take advantage of it. Why not have a system in which little kids can build a structure out of blocks alongside an architect sculpting complex forms?
DeleteYes, maybe there is no other option than to provide a wider range of tools, and people will stick to what they can use. This is always an option, still to some degree it means we have failed at finding an universal simple interface.
DeleteWe can debate whether such interface is even possible. Odds are we are set to fail on this one. It does not mean we should not try to minimize the set of tools.
The problem I see with a range of tools is that the overall complexity of the system does not come from the tools you use, but from the all the tool options you have.
Let's say a game using this is out and you start looking at the top 10 user creations. In the back of your mind you will always have "I bet this guy is using one of the good tools I don't know how to use", even if what you see is built with the basic tools. When you don't know you just assume the worst.
This creates a barrier. In your mind you now need to learn and get used to some UI to be good at this game. If the tools are so simple nobody has to explain them to you, you intuitively know you will be limited only by imagination. This is a very inviting feeling.
Then maybe the more advanced tools should be hidden from the default game and manually enabled by the advanced user? I don't see this as ideal because it creates even more of a divide between advanced and basic users. However, it does seem to be successful in Minecraft, where some people are content with the original system while others use addons to achieve what they want. In my experience, people using the original and the more advanced modified editors are able to work side-by-side to create ultimately equally complex constructions. The difference is often the time it took them to get there.
DeleteBy all means, the 'simple' tools should be able to create anything that the more complex ones can as well, but certain constructions may call for functionalities that the complex tools are better suited to provide. Ultimately, it comes down to efficiency. A user can place every stone like in your demo, or pull out a wall tool and just throw it the path they want. Likewise, someone could simply spawn in a tree, or build it branch-by-branch, or open a grammar editor and put in their code. All three methods could provide the same result ultimately, but it is a matter of how much control the user wants over the result while keeping the time it takes for them to achieve it reasonable, even if it requires more knowledge on the user's part.
As usual you are doing amazing work! I wish I would have found your engine before we locked into Unity. Keep on inspiring i.e. kicking us mere mortals with voxel dreams in the pants!
ReplyDeleteI think you are better with Unity. The grass is always greener on that other engine you cannot use :)
DeleteJust check the RGB value XD.
DeleteComponents of Cepero's engine have been integrated with Unity already. Take the best of both.
DeleteLooks insanely easy to use. I would echo the previous reader's comment though, perhaps adding a wireframe preview of the brush before adding would speed up positioning. (even a toggleable one?) Particularly as the mesh brushes get bigger and the datum position is less obvious... Apart from that, awesome work, as usual.
ReplyDeleteWhile I wholeheartedly agree with the positive sentiments above, I really am left thinking one thing: Copy + Paste.
ReplyDeleteGotta' have it.
Any plans for it?
Yes, copy & paste is almost finished. It is mostly about finding a good UI for it now.
DeleteThere is purity to the simplicity of your current model for editing, yet I think more is warranted.
DeleteA sandbox, or any tool's, ability to draw people into content creation is really dependent upon WYSIWYG fidelity. More advanced settings like rotational chaos can be hidden away, but knowing what is going to happen when you click goes VERY far into getting people comfortable using it. Otherwise, you'll need to spend time and resources on the building the opposite function, unlimited undo, when it doesn’t do what is expected.
I’m sure you are already thinking about many of the below points, but wanted to mention some of my thoughts, as someone who gravitates toward content creation tools and building content within sandbox games:
__Alignment and Precision settings for Brushes__
The off grid ability, and the randomization when instancing the brush are awesome!!! When building ruins, it will create some amazing stuff, but sometimes you need to build the sparklingly perfect marble 'temple of the god's', and that requires alignment and precision. To that end here are a few settings for advanced brushes that I think would leverage what you’ve already done:
>> Ghost or Bounding Box Brush placeholders - I know you don't want to add too much UI for an overlay, but I do think that displaying a ghost or placeholder of the brush selected and where it will be placed will be well worth the effort and overhead, when it comes to getting people both old and young, novice or advanced to use this engine to create content.
>> Alignment & snap-to existing/recently placed brush strokes - Akin to your ‘cornerstone’ concept, or building Hadrian’ s Wall. Place a brush and easily place the next one right beside it or on ‘top’ of it, in an aligned way. Without that, you will limit what people without becoming inordinately frustrating, and ease of use should be paramount.
>> Settings for Algorithmic positional/rotational chaos - Alignment should still work, but a setting for how much chaos should be applied will introduce all those wonderful details and offset bricks so everything isn't too "perfect", much like your procedural content creation algorithms do. If we set this setting to 0 it's perfectly aligned, if it's 100 it's completely random each time. A setting of 3-5 might be nice for a new brick wall.
>> Settings for Algorithmic Age/Decay - Similar to what you showed with the new instances being slightly degraded upon placement, being able to set this would allow us to get much more use out of existing brushes, as we could build both the clean and the ruined version of things using the same brush, just with different settings. 0 = no decay, 100 = a crumbled mess barely recognizable (algorithmically weighted toward the 'down direction', ie. what remains from the base of a weathered roman pillar)
__Copy and Paste Ideas__
MCEdit's selection tools work nicely for copying instances of data for naming and pasting later, in game, it would be a floating drag-able bounding box.
If the world grid is kept to some broad value like 1 meter we could build things up into the air with space around them and then either use a bounding box approach, or you could use cursor's position when pressing a button to search the voxel data, starting at the cursor intersection and it goes until it is stopped by empty voxels on all sides, with a timeout/distance limiter. (Of course this is a gross simplification).
P.S. if you can nail the ability to share these brush/template items easily throughout the world or with downloadable sets of files, you will RULE the procedural/sandbox universe... and I'll release a medieval brush set soon after release. :)
------
Awesome work, as always! What an amazing update for May! and 'lo June approach'eth, I'm so excited!!! Loving all of this!!!
Jonathan
Because your goal is to create a game, you can give progressivly tools to the player by using experience/levels.
ReplyDeleteTools to be a better architect can even be build by finding materials.
A new character can pickaxe/dig/harvest/construct low quality objects and build structures without guides and helpers. Structures needs a certain amount of materials.
Time after time, player will gain experience and he will raise skill in construction. (with more tools).
Exemple:
- the player can build a set square. the game
show now a ligne to represent alignment.
From a certain level, you can give the possibility to create blue print.
-the player must build plots/paper/stylo. he place 4 plots arround the existing construction and click on one plot. The construction is copied on the paper and create a blue print. He can name the creation, and the game indicates materials needed on the paper too. Now he can share blueprint paper with others player.
-you can find rare chests in caves with specials blueprint on them...
I have 1000 ideas about that in fact :D
maybe something simlple, like spacebar or capslock togles between on and off the grid editing ?
ReplyDeleteHi, I have one question, will be subtraction with brush added?
ReplyDeleteThan about content creation, I think the best approach will be to allow player to create rough model, than offer tools for precise editing (like normal sculpting), than allow player to save selection and than use it like brushes you've presented.
That's just mine opinion ;) Good Luck Miguel :)
On the subject of more precise/advanced tools, I have tried the Sauerbraten program, and it really didnt feel like a game at all, the interface was so complex that you actually had to learn it. I personally am completely for it being simple, I believe that, because it is going to be a game, and not a tool, the extra time spent on it is perfectly acceptable, and as mentioned before, mods can potentially be made that have better tools.
ReplyDeleteSimplicity is exactly why I have spent so much time in Minecraft, and far less time in Sauerbraten, sure, in Sauerbraten you can do a LOT more, but minecraft is just: I have an idea, lets make it! And the only tools you really use, is your movement, sometimes crouch, generally left and right mousebuttons, and the scrolling wheel (And space to jump), there is no moving through menus to get what you want, no going through help-pages to see what what tool does, I personally would prefer less accuracy, slowness and simplicity over accuracy speed and complexity.
But that is just my opinion =P.
Good Point Kamica,
DeleteBoth myself and my 5 year old son build things in Minecraft. I build cathedrals, towns, and replica's of his school. He builds huts and 5 story brick "hotels" with a bed on each level, on my iPhone :)
We must keep in mind though, that in Minecraft the simplicity of the square voxel allows for a UI shorthand that won't be possible for here. In Minecraft, you hold the cursor over one of 6 sides of a block, which highlights itself as feedback, and the block of your choice is either created on that side, or the current block is destroyed.
When Miguel was building only with blocks, the same concept applied somewhat, but even then I noticed that it was slightly more difficult to "know" what was about to happen when he built or destroyed voxels, though the red highlight helped greatly.
As soon as the brush can be any shape, this becomes problematic. Perhaps it would help if the red highlight would actually display the intersection of the "bottom" of the selected brush and the current terrain. But even if that was the case, orientation is still an issue, and it matters in oddly shaped brushes.. like a house.
With the awesome power of brushes of any shape, size and orientation, the old Minecraft way of doing this is inadequate. Orientation now matters greatly, and even Minecraft began having problems getting orientation right, with only 6 sided cube voxels :)
Also, Minecraft has a fixed world grid as well, one block can only replace one full block. Where as a misplaced pillar segment in Voxel Farm might blow out the terrazzo floor, a wall and the carefully built planter on the far side.
Miguel has build some serious power into this engine with the ability to use brushes of these types... and don't get me started on the awesome dynamic noise 'decay' upon placement! It would be a shame to have its usability hampered because we have a limited ability to place things right where we need them to go.
I think additional effort to keep it simple, yet not impede the usable power inherent in these brushes will be well worth the effort.
For my money, I still think that a ghost overlay of the current brush with modifiable orientation will still be necessary, at some point... that and the basic snap vs. free alignment modes.
I agree with the ghost thingy. And I will trust Miguel to find a nice balance between tool-ness and game-ness =P.
DeleteBut anyway, on your points: I have nothing against precision modification, however if you add too many tools in there, it basically becomes 3D photoshop, all these things which are nice to have, but you really dont use the majority of it ever. The tools that get chosen for the final product should be often used, versatile and easy to use. The only tools I can currently think of which are necessary are:
Placement (of brush)
Removal (of brush)
Selection (of brush)
Scaling (of brush)
and rotation (of brush)
Now, these are already five different tools, which will already require hotkeys etc. Then you would also need a key to toggle the grid, and this would probably happen either based on what you are holding your cursor on, or where you are looking.
All of this is quite a lot already in my opinion =P, but these are just the things which I would see as important, are there any others you might need? (Pointed at anyone who reads this) I ask, so I can actually see what people do with their stuff, as I am not a very artistic person =P.
I agree with everything said here, even if these are apparently contradictory views. It is a difficult problem.
DeleteTo me it is about having many different brushes and only one very simple tool mechanic. Depending on the brush you pick the entire behavior of the tool will be locked down. I want the brush to feel intelligent, so things like snapping or rotation can be left to the brush definition.
Finding new brushes and experimenting what they do can be part of the gameplay. Let's say you go into some ruin city and do a quest there. The reward could be a few brushes that allow you to easily replicate the look of the ruins on your own.
These ruin brushes would not have any form of snapping to previous strokes and would be fully off-grid. If you wanted to build straight with them you will certainly get an aneurysm somewhere. But dilapidated ruins are not meant to be straight. So if you are building a new perfect temple for the Cube God, you better use the squeaky clean set of brushes, not the ruin brushes.
The community should be able to contribute new brush sets. This would be a collection of meshes for the brush profile and some rules about how the clicks should be interpreted.
Once you get a new brush, you should take some time to get used to it. This is to understand what look it produces, also how it reacts to your input. I think we humans are good at learning that kind of pattern. It is something you cannot explain in a manual, but you just get as soon as you try it a few times.
Still the input that is available to you remains the same. There is no psychological pressure because you are not learning a new tool mechanic. This is what I believe makes the system simple.
Note the system already features Undo. This is a must if you are meant to experiment. You actually see me trying things and quickly undoing them in the video.
(BTW, brush is not a good name for this, but it will do for now.)
Mould? =P
DeleteAnyway, I kind of like that idea, but I do suggest playtesting it first before fully going for it, it is so different from what most people do, that it would be smart to do some research into it =P.
Then a future question: In the final game, will these brushes cost resources? Like in Minecraft? Or are they free to use? (Some form of build energy would also count as resources in this case)
I agree with everything above too! Thanks for your further thoughts on this Miguel, I like the way you are defining it, and think you'll do great making it easy to use. keeping the tool simple and allowing the 'brush' to define those characteristics could be cool.
DeleteI still wonder if some of those chaos type things like random offsets or decay, that you can so easily apply when instancing the voxels would still be good to have as modifiable advanced settings.
If someone makes a bunch of great brushes for different types of rocks and stones, it would be nice to be able to "paint" them into a scene with some of that procedural randomness that the engine already excels at, almost like we're painting with Procedural Voxel creation with that brush.
I do think the pure manual placement methods will be fine as a start. But sometime it'd be fun to play god-mode laying huge swaths of stones to create an old road down the mountain... but I can understand your idea of putting that type of complexity into custom 'brushes' that can be designed to deal with the inherent issues with that idea :)
I wouldnt be surprised if the randomness can be *programmed* into the brushes.
DeleteShould take a look at Kerbal Space Program and how they position things to build a spaceship. You have constrained vs free placement, attachment nodes, rotation and it is all pretty simple to figure out. Not sure how much can be used but worth taking a look for inspiration.
ReplyDeleteThe problem with Kerbal Space Program, is that unless you use the symmetry functions, it is usually quite hard to place parts precise, which is why so many people want more tools.
DeleteJust keep in mind that to some extent, personal expression might be limited by too strict tools/brush rules. Take Minecraft for example, where a lot of magnificient architecture is the result of diregarding the building blocks original intent, i.e. using hatches as decoration.
ReplyDeleteI believe it should be possible to put down ruin brushes perfectly aligned, because someone might develop an architectural style based on that mix of ruined and rigid.
Yes I get it.
DeleteNow imagine you are trying to invent Minecraft and got to the point where you explain to people they can only do cubes. That's very limited and strict. Still people got on board and created amazing things. Even in the vanilla version.
If you instead look at Sauerbraten (which I think predates Minecraft) or the game Love by Eskil Steenberg, they are brilliant interfaces which give you a lot of freedom and options... but they did not have mass appeal. I think that means something.
Ooh, Love was an interesting game for the time I played it, I had no idea what was going on, didnt bother to look at any help files, but just screwed around, it felt like I was in a world left behind by some old civilization, and I was just trying to make sense of it all, and seeing what did what, sometimes I had no idea what I just did, for example, whether the water was actually rising because I changed the path of that beam? Or because of some random effect?
DeleteThe confusion in this game was fun surprisingly enough.
Roller coater Tycoon 3 had a great interface,
Deleteit blended voxel like terrain building with
a library pre-built polygon structures.
RTS games have a bit more leeway when it comes to menus though =P, I cant remember what the interface looks like though, so it might be good, but just saying just in case =).
DeleteHey, you don't want to make selection saving and using it like brush?... I think having this feature and having simple cube brush could be enough (for beginning)
ReplyDeleteI'm curious about your thoughts on voxel based player characters or props, or other sorts of things that would be more dynamic in terms of movement and physics. I know I have seen grass and leaves blowing in the wind of your worlds, but how about interactions between voxel based objects like tools and the environment. Would an implement like an ax or something only act as a brush in the gameplay setting or could it be made of voxels also? I think this would be exciting, especially in terms of crafting highly customizable tool and weapons. Is this sort of thing a possibility?
ReplyDeleteHi Jesse,
DeleteI'm no expert, but Miguel has touched on this in the past. The impression I got was having voxels as entities, and even the application of physics and moving voxels parts and stuff like that is a difficult set of challenges, and probably has many added factors that must be hurdled.
The voxel engine he has created generates a lot of data quickly, and to keep voxels lean and performance oriented there are storage and access mechanisms required to do it fast.
For me, I think about voxels as a 3d array of pixels. Think about a circle made of pixels in a paint program. To transform that pixel circle to a new position each pixel must be updated and transformed twice, for both the starting location and the end positions, when you do this you must do many separate calculations, per pixel. Now imagine scaling the circle to an elipse, the calculated approximation must be done to find the right location, and depending upon the resolution there are lots of calculations you'd have to do.
Many early demos from the demo scene used voxels, with a fixed grid and just using the music or other animations to make it seem like it was a tunnel or waveform you were looking at. That requires tons of calculation, compared to the way many "regular" games load the mesh scene and then let you move around within it, moving just entity values and then rendering the results.
I think the ideas you are talking about are before us in the future, but I would be they are quite a ways off.
Like Jonathan says, it is very hard to transform and animate voxels in their native form. There are some projects that show some success at deforming sparse voxel octrees.
DeleteI think I have cracked this. The key is not to use the voxel form, but to convert to polygons first. Assuming you manage to find a skeletal representation of the voxel content, you can have the resulting mesh deform following changes in the skeleton. This is how polygon-based game characters work in games.
Let's say you create a voxel dog. The system can identify this is a quadruped. It can find a matching skeleton for that structure and apply a set of premade or procedural animations to that skeleton.
If you create an axe or a cross, you will probably have the same skeleton for both, which is kind of alright I guess.
In general the idea is to have a set of skeletons on one side and a pattern matching algorithm that will match a set of voxels to a skeleton. If no skeleton is found, it means the system does not know how to deal with that object.
Once a skeleton is established you can refine its behavior a little more. For instance, you may have several animations for quadrupeds some may apply to cows, yaks and triceratops but will not do well with wolves and dogs. So you would need to filter that.
Miguel that sounds very exciting.
DeleteWould any of that facilitate a more realistic handling of trees in-game? I.e., chopping them down, chopping off limbs, etc.
Even though it sounds very exciting to use voxels for character/objects, wouldn't a conventional polygon model of a dog, cow, axe, or cross for example remain far easier to implement? And look better/more realistic?
Take care.
Applying physics to a large object like a tree or a wall is a pain in the ass. I am not going there for now. You always have the option to not have voxel trees at all. I am not sure voxels are a good fit for trees if you want a realistic behavior when you chop them.
DeleteLike you said, a conventional polygon model for characters and objects would be far easier to implement. The thing is most people are not able to create with polygons. Somehow you need to make this accessible.
Voxels help here. Let's say you want to build some sort of menacing quadruped to guard your ruins. You could start by picking a skeleton for it. Then you could use a brush that does muscles and hang some meat on the bones. The brush would be smart, so it would create a nice muscle definition depending on where you paint.
Then you could use a brush that adds fat, or maybe you will skip this one at all since you want this creature to be very lean.
And last you would use a brush that adds skin and hair. This brush would be only a few voxels thick.
Voxels are well suited for this kind of layered constructs. Once the creature is done it will be stored and rendered as polygons, but all the information that came from the voxel layers (the bulging muscles, the blobs of fat) will be there.
Do you think this kind of stuff will ever be in your game? Because that sounds AMAZING! XD.
DeleteAnd I wouldnt be surprised that if you set your mind to it, you could find a (relatively) easy solution to the whole physics problem =P.
this Looks great.
ReplyDeletelove that new Feature, you could really build nice neoithic looking temples or monuments with that, or ruins.
however if i was to build a luxorious temple or building, it would be good if everything is perfectly symetrical and smooth looking. will this be edited too ?
I suggest you read the rest of the comments here, but since I know how annoying that can be (to read a lot that is, the comments are actually quite interesting): Basically what Miguel seems to be planning, is for each brush to have its own behaviour, so not just its own look, but it might snap to things or look more pristine. This basically means that some brushes will be great for natural things, or things that have been exposed to nature, while other brushes would be great for human made stuff.
DeleteI might be wrong in the interpretation though.
Really impressive work, Miguel.
ReplyDeleteIn the long run, are you planning on hiding the voxel grid altogether?
I mean you'll want to retain snapping to the grid (or to the cardinal directions, gameplay-wise), but in the video you show that you can still manipulate the raw voxel grid that underlies the brushes. Is the final goal to do everything with brushes, with the grid just being the substrate that supports them?
I think you could get very powerful control over brush placement with only a few modifiers: free placement (like when you're building the circle), "cardinal snap" (like the slabs), or "snap to neighbour", where the edge of the current brush aligns with whatever's next to it.
I'm not sure how easy it will be to calculate the edge of an object once it's been "painted" into the scene as voxels, but it would be a powerful tool if it's practical.
I agree Kagato, and those three really cover a lot of functionality. I think modifier keys is a good option for keeping the tool inherently simple.
ReplyDeleteI'd also suggest a rotation modifier with either mouse or key's to adjust pitch/roll.
I just realized there is another editing paradigm used in other programs, rather than the single click edit Migue ha shown. The other is a two-click place/adjust/set function, which could be toggled on/off as a precision mode by something like the caps-lock, with the default behavior being simple 'snap to grid' no adjustment (easy-mode) behavior that he already has. In advanced mode it could work like this:
- Click ONE - Sets the anchor fo the brush placement.
(adhering to the snap/free/snapNearest modifiers)
- Precision adjustments pitch/roll/rotation are made,
- either by keyboard WASD/QE keys
-or by Mouse movement.
- Click TWO - Sets the brush and instances the voxels.
--------------------------------
Just a different advanced mode model that might be easier to work within without hampering novices with these features... yet still allowing precision. I'm sure some programs have implementations like this that could be modelled after.
Great comments and great stuff from Miguel as always!
I know this is slightly off-topic, but I'm really curious about something. In the future, will it be possible to have round worlds? Like Earth, a massive sphere, with all the top surface buildable on. There would be a center of gravity, so no matter where on the sphere you are on, you're always attracted to the center. Just think, someone could make a replica of earth, with jungles, forests, the pyramids, etc.
ReplyDeleteAlso, possible beta-test/release date?
Thanks for reading!
It is possible to have rounds worlds now. I am not very interested in that however. I still need to make a small patch of flat land interesting, this is the challenge. Then we can see about making huge spaces interesting.
DeleteWhat makes Earth appealing is not that is round. It is the many cultures, cities, biomes, etc. Even then it is a very big and boring place for the most part.
So the topology does not matter much. It could be a sphere or a doughnut, what matters to me is what is going on these places.
Actually, a doughnut WOULD be more interesting, since, if you are on the inside, you can see another piece of land on the other side, and go "Ooh, that looks interesting, lets go there!" =P But I understand your point. Also, something I thought I posted, but apparently didn't make it to the site: You can also make the illusion of it being a round planet (As long as you don't add space travel), by simply making the world wrap around at the edges =P.
DeleteYes, a world that wraps around the edges is a doughnut.
DeleteThis topology provides a finite, limitless space, pretty much like a sphere. Without a space view, you don't really have to render the whole doughnut. People experiencing this would would have to be very smart to figure out what kind of topology it is.
Erm, I didn't mean to create the illusion of a doughnut planet, as you would still have to be able to see the planet in the distance if you are on the inside =P, what I meant was to create the illusion of it being a spherical planet.
DeleteThe only way people could figure out the world was flat, was by checking shadows, and comparing sun-sets and sun-rises =P.
Reading the doughnut pieces reminded me of halo. I'm not sure if you are a fan of the halo series (the books primarily), but it would be awesome to build a halo and be a forerunner. Wow, my mind is swimming with the possibilities now. Miguel, I admire your work extremely, and I am glad you started ProcWorld in the first place. Thanks for being awesome!
DeleteWhat about a massive Stanford Torus with terrain inside of it? Following a space-themed gamemode. Or not. I could imagine a game entirely about being inside of one such space station.
DeleteIf the goal were truly to create an interplanetary sandbox, it might make sense to have contiguous 3d voxel (low detail) representations of planets for space views and then switch to flat mapped terrain when editing a planet's surface.
Yes.
DeleteOne nice, simple way to do it would be to use hex tiles.
You can do a sphere with hex tiles, but you can also handle them as flat if the camera is close enough to the ground.
So you get a flat world most of the time, but if you travel high enough, you start seeing the planet. And both views can be consistent.
With hex tiles, not all of them could be hexagonal. Assuming an icosahedral structure, there would have to be 12 pentagonal tiles among the hexagons for a complete sphere. With triangles, on the other hand, there would be corners (again, the number being 12) where five as opposed to six join.
DeleteThe question is, is it better to have all of the tiles have the same number of sides, but have corners where varying numbers of panels join, or the other way around?
The concern is that someone happens to build a house centered on one of these corners, and because all of the angles are slightly less than 60* (or 120*, whichever scheme is used), the walls don't quite align after the player goes all the way around with 90* corners. I should think that having a voxel grid that isn't 100% rectilinear is highly undesirable, so maybe the only way to solve this is to have so many tiles that the distortion amounts to less than a voxel. Of course, in the real world on a fully 3d sphere this is just as much of an issue, but only noticeable for large constructions, and as the Earth is (practically) a perfect sphere, the geometric phenomenon is global. The goal in a game is to make this just the same, with it happening equally whether on the corner of tiles or inside of one. If the world were represented by tiles of an icosahedron, really weird things would happen near the vertices. What it comes down to is that Euclidean geometry does not play well with spheres. It is a dilemma as old as the basic understanding of the Earth being round.
Yes you are right about this. For a sphere tiling you would need to sprinkle some pentagons too. http://upload.wikimedia.org/wikipedia/commons/thumb/3/39/Truncated_rhombic_triacontahedron.png/600px-Truncated_rhombic_triacontahedron.png
DeleteLike you said, I would tile at a frequency that is enough so the angle difference at a corner is not noticeable at plain sight. The voxel space itself would be warped, either by making upper voxels larger, or by distorting voxels along the edges. Either way you need massive planets. I don't think you could do a body like our Moon, it would be too noticeable.
I still need to think more about this.
Why not make the voxels count as the most basic shape in computer graphics, Triangles and/or prisms
DeleteThey can represent any of those shapes, just how you set up the corners and angles of the triangle would change the fields perspective.
Because that is completely different technology and graphics cards aren't designed to do that. It has been done (http://code.google.com/p/efficient-sparse-voxel-octrees/) using CUDA/OpenCL, but it is still limited and the GFx card doesn't have the optimizations it needs. With that demo, on my relatively average Nvidia card, a reasonable resolution runs at 12 FPS and that is for a very small scene. It could improve, but far better performance and comparable detail can be achieved with polygons.
DeleteAnyway, for something like the Moon or even smaller (an asteroid?) What if the planet were represented by a single, solid voxel grid. Now, this is not ideal for building, where someone wants Down in the editor to be Down towards the surface of a planet. When someone starts to edit, it creates a new grid where all of there changes exist. It is rectilinear and has a fixed orientation. When extracting polygons, the planetary voxels are mapped to the new grid and mixed with the player's changes before the final polygon mesh. My description is a bit convoluted but that's one way I could see it working.
Sphere is interesting, but it wouldn't be one massive voxel grid with changing gravity. It doesn't really make sense. A more sensible solution would be to have triangular sections of flat voxel space. The polygon extraction algorithm could be fixed so that it can seamlessly render the edges between voxel grids at different angles, and as for the curvature, it could be done simply by distorting the resulting polygons to a spherical form when rendering.
ReplyDeleteAlso, leave the making of an entire Earth replica to polygon or point-cloud technologies. Google Earth has practically done it already, although with not as much detail. Sure, if you wanted to go to a specific place and edit there, the data could be translated to voxelfarm.
And last I checked, Miguel was already aware that fans want to see a release. You don't need to keep asking this. He is going at his own pace, and the last thing I would want, personally, is an inferior product that is rushed.
Your thoughts on the sphere are interesting, definitely changing how I see things.
DeleteAlso, I never asked him to hurry, I'm just severely anticipating playing with the engine. It looks absolutely incredible.
Miguel, I have a question for you, regarding rotation of objects in the voxel space. In raster systems, things often cannot be rotated too many times without becoming distorted, with what once was a smooth edge becoming more like the teeth of a saw blade.
ReplyDeleteHowever, the system you use stores additional information about angle and position of the faces of the voxels, giving sharp edges and flat surfaces when needed. Assuming no details or gaps thinner than 2 or 3 voxels, would this be enough information to take a region, rotate it, and map it back to the same grid, without losing or 'corrupting' any detail?
I myself being a wee bit of a programmer, am just astonished at what you have accomplished on your own, Miguel. I hope you go far with this project, and make it the next big sandbox engine out there!
ReplyDeleteAny plans of incorperating your L-System objects into the brushes ?
ReplyDeleteOr perhaps as a large macro brush or sorts (it might need some dialog boxes for parimeters).
Yes, this is how I see brush scripting to happen. I don't think I want dialog boxes, the brush code has to be smart enough to figure out the expected behavior from the context.
DeleteHere's how I see more powerful editing tools working in a game. In a complicated, professional program like Blender, just clicking around often gets the user nowhere, or causes unexpected things to happen. It is when they go to the manual that they learn all of the commands, modifier keys, and dialog boxes they need to do what they want. In a game, the basic controls should be very simple and intuitive. However, the menus and key actions should all be there. The player should feel encouraged to chance upon these options, but not forced to use them. And if they are truly not comfortable with using these, they should simply be able to ignore the buttons that trigger them and use the basic controls, without having to turn any sort of 'advanced' mode on or off.
ReplyDeletewill the controls be changeable, i can only Play with using the arrow keys xD
ReplyDeleteThi Project Looks really good, do you have any estimiation on when Alpha Version could get released?
I am totally for changeable controls, but just a suggestion: Try to learn to use the WASD system, it allows you to play far more games, and also gives you way more buttons to play with =P.
DeleteSo, basically first you put your middle finger on the W, your ring finger on the A, and your index finger on the D. This will take care of your left(A), Forward(W) and Right(D) movement, now, if you need to move backwards, you will just move the middlefinger over to the S for as long as you need, and then move it back to the W.
Using the WASD keys often leads to a more comfortable experience when playing games, it is ofcourse no requirement, and using the arrow keys is equally viable. But I put this up just in case you do want to use the WASD keys =P.