Wednesday, February 12, 2014

Vacansopapurosophobia

The terror of staring at a blank page. We all have felt it one time or another. Even seasoned artists can feel anxiety when starting a project from scratch. If someone is watching over your shoulder it can become unbearable. At that point you may just give up and save yourself all the stress.

Sandbox games put the player in a similar situation. You now have the ability to shape the world and create beautiful things, but again there is the game world as a blank canvas looking back at you, wondering if you are going to suck as a creator again.

If you share this sandbox world with others, you may have already been exposed to all sort of wonderful creations. Maybe you have seen them on YouTube or Twitch. These people know how to build perfect columns, archways and vaults for their creations.

So you start placing a few blocks, but it gets you nowhere close to that grandiose design you had in mind. It is not that you lack the imagination. What you don't have is the technique to produce the elements you want.

We have designed a tool that can level the playing feel.

For a long time now we had architecture grammars. These grammars take a block of space and create something inside. I have shown many examples so far. Very often they were used to generate entire buildings. The trick is, you do not have to target full buildings for these grammars to be very useful.

You can realize your vision by combining simpler elements like roofs, barandas, columns, arches, vaults, etc. And these elements, instead of being labor intense, could be just the output of smart architecture grammars.

The fact that these are full fledged programs means they get to adapt to different configurations. For instance look at the output of this architecture program:



The program was clever enough to reinforce the corners. Yes, you could do this by hand, but imagine how many corners like this one you will get in your massive castle. Also note how the program has introduced a random element to the stone placement, making the walls more interesting.

Here is a video showing a different example:


As you can see the program adds more columns as they are needed. No distortion in the columns occurs as you make the box wider or taller.

At this point your are no longer dealing with the masonry. It is like you had hired one of the talented builders from YouTube to do the low level work for you. Knowing you have a repertoire of interesting prefabs you can combine in imaginative ways will surely help you get over your vacansopapurosophobia.


73 comments:

  1. How many lines of code does it take to create brushes like that? Also, do you think you will ever be in a position to releasr a portion of your voxel farm so other people can code their own brushes? I can see a forum community getting quite involved in creating super innovative brushes, and helping debug each others tools.

    ReplyDelete
    Replies
    1. Here is the full code for the colonnade, which includes code for a column:

      shaft {
      instance "modshaft"
      }

      necking
      {
      center xz
      rotate y 9
      scale [80%, 100%, 100%]
      loft ngon 20
      [100%, 100%]
      select sides
      {
      scale [100%, 100%, 1%]
      instance "wall_1m"
      }
      }

      capital
      {
      center yz
      instance "smoothequinus"
      }

      abacus
      {
      instance "wall_1m"
      }

      column
      {
      divide y
      [99%] shaft
      [1%] necking
      [depth / 4] capital
      [depth / 4] abacus
      }

      cornercolumnleft {
      divide x
      [depth] column
      [depth] {}
      }

      cornercolumnright {
      divide x
      [depth] {}
      [depth] column
      }

      intercolumn {
      divide x
      [50%] {}
      [depth] column
      [50%] {}
      }

      intercolumniation {
      repeat x [depth*3] intercolumn
      }

      intercolumniation : width < (depth*7) {}

      colonnade : width <= (depth*6) {
      center x
      divide x
      [width/2 - 1] {}
      [depth] column
      [width/2 - 1] {}
      }

      colonnade : width <= (depth*8) {
      divide x
      [depth] column
      [100%] {}
      [depth] column
      }

      colonnade : width >= (depth*9) {
      divide x
      [depth * 2] cornercolumnleft
      [100%] intercolumniation
      [depth * 2] cornercolumnright
      }

      main {
      module colonnade
      }

      This was written not by a programmer. We have an architect working full time with us now at Voxel Farm. This guy has never programmed in languages like C or Java. He was able to pick up the ideas in no time.

      I have big plans for all this, it is just too early to comment on anything.

      Delete
    2. That is super exciting. I shall try to patiently wait.

      Delete
  2. Hey Miguel,
    Great work as usual. Though I have to question just how useful this kind of tool is in its current state in practice. If I use a floor, wall, and roof grammars to build a basic house but then decide I'd like to extend the front floor and roof into a open porch and then place some columns at the end. How would this work? Does the grammar currently take into account that the voxels around it were produced by wall and floor grammars and perform some intelligence? Does it understand the difference between a cave roof and a constructed roof?

    The tool seems good as an isolated tool, but I feel that it won't have a truly great use until it is able to be the grammar module in a larger grammar for a whole house/castle. I know you've built exactly this to generate entire buildings in the past. But will these tools have the ability to generate these larger grammars by allowing players to piece them together in real-time as I described above?

    ReplyDelete
    Replies
    1. "Cave roof" and "constructed roof" would be different grammars

      You could keep track of many previous scopes and mix them with the current scope. But I would not overcomplicate it.

      Delete
  3. Miguel, what lies *behind* this video is even more fascinating than the video itself.

    What made Voxelfarm a reality and a real mastrepiece is not only your mastery and awesome skill...it's your VISION.

    I can't comment having a full time architect in a company like (what I imagine to be) VoxelFarm...brilliant.

    Please keep up the good work and NEVER EVER stop trying to put said vision into reality.

    Cheers
    Andy

    ReplyDelete
  4. You sneaky tease, Miguel. We can all see what's behind the columns... :)

    ReplyDelete
    Replies
    1. Holy shiz! Didn't notice that. Very very pretty.

      Delete
    2. Guess the water's sneak skill improved =P. Yea, the tool seems really cool (though I get a hunch the video doesn't tell us the whole story and use of the tool), but WATER! Could you possibly make a few scenic videos where you walk around in different places with water (Forested regions, snowy regions (I don't expect ice, don't worry =P) and such)? That'd be awesome!

      Delete
    3. Hehe, was wondering if you guys would notice.

      Delete
    4. Ha ha, sneaky, I missed that too. :)

      Delete
    5. It wasn't a matter of if, but when XD.
      It IS interesting to see how people often only look at the things you call attention upon =P. I guess that's how magicians fool us.

      Delete
    6. LOL! Missed that completely.....how sneaky...

      Delete
  5. can a floor code include markers around the edge so after i create the floor i can arto fill a wall on it at a later point?

    also can a floor code selectively delete terrain on top but not other constructions?

    ReplyDelete
  6. Can I ask you what is that music in this video?

    ReplyDelete
  7. What if my talented builders have already done the work for me...in Minecraft? Do you ever plan on enabling the importation of Minecraft .schematic, level.dat, and/or .mca files?

    Because that would be pure awesomeness.

    Excellent blog as usual, Mr. Cepero. Take care.

    p.s. When you took a chunk out of the side of that pillar right before the end of the vid, I soooo thought you were going to take another chunk out and topple it over. I wonder if it could have knocked into another pillar and toppled it over too? You should do a short video dedicated to more complicated physics some day.

    ReplyDelete
    Replies
    1. The second pillar wouldn't topple over... unless they added stress calculations etc. to the program while we weren't looking...

      Delete
    2. I do not know much about Minecraft formats. I never looked into importing, my plan is to let modders write the adapters.

      Delete
    3. Fair enough.

      How about heightmap importation? I want very badly to model Middle-Earth with your tech. EQN:Landmark, will there be something I can use to import an 40,000 x 40,000 greyscale heightmap?

      Delete
    4. Yes, it is quite easy to get heightmaps. You can actually feed more than just the elevation data. For your middle earth project you could also use maps describing what type of biome you have, location and shape of caves, etc.

      Delete
  8. Fantastic. Is EQN:Landmark the only viable "game" using your tech right now that I could do this with? Or are there others? Not asking for their names or anything.

    ReplyDelete
    Replies
    1. http://procworld.blogspot.ca/2013/06/tug-too.html?m=1

      http://procworld.blogspot.ca/2013/06/starforge-avec-voxel-farm.html?m=1

      Delete
    2. Yeah. Thank you for the links. I remember reading about them in the past here on Miguel's blog.

      I was wondering more along the lines of are there other sandbox games like EQN:Landmark using Voxel Farm. And again, not asking for specific games just whether or not there ARE any being developed.

      EQN:Landmark looks fantastic. Like an order of magnitude better than Minecraft. It's just that...I hope that's not the ONLY game being made that's like that (i.e., Minecraft-ish/sandbox). I'm also not keen on the microtransaction thing and prefer the way Mojang did it.

      So yeah, here's to hoping there's more than one being worked on.

      Delete
  9. Are there any plans for a cartography grammer?

    ReplyDelete
    Replies
    1. Yes, eventually I would like everything to run grammars, including terrain. The problem is these grammars can be expensive to run, depending on how much detail you want. They will have to be simpler so we can run them on very distant patches.

      Delete
  10. I have the opposite problem. A game idea on lots of paper but no skills to fill in the blanks. It doesn't help that I busted my main computer and can't yet play the Everquest Landmark Alpha I paid for. D'oh.

    ReplyDelete
    Replies
    1. What's your account details, i'll play it for you :)

      Delete
  11. Hey Miguel, where's my unity plugin !!!! I want a indie version of all this :(

    ReplyDelete
    Replies
    1. Don't waste your time. Recently, we've learned that VoxelFarm costs $100,000 and that Miguel very much hates small independent companies.

      Delete
    2. I agree Albert. I have lost so much respect for Miguel recently. Sadly, I'm still curious about Voxel Technology. I continue to follow this blog for now.

      Delete
    3. Paul we are not working on a Unity port/plugin ourselves, at the time it is up to whoever licenses to integrate with Unity. This is not difficult and we assist along the process with examples and source code showing how to do it.

      The only reason is we lack the time and resources to do it. We are still a very small team.

      Once we get some time to start looking into mainstream engine plugins, Unity is likely to come first. It won't be long I hope.

      Delete
    4. Yeah but at what cost? $100,000 is not really a price for Unity Developers.

      Delete
    5. $100,000 for a Unity plugin would not make much sense. When we get there I hope we will be wise enough to set the right price.

      Not sure if you noticed but there are a couple of guys trolling this blog under different accounts. By principle I do not remove any comments, but that may lead to some confusion.

      If you are a SERIOUS indie developer you can contact us any time to inquire about pricing and partnerships. We love working with indie studios, we are indie ourselves.

      Delete
    6. I'm sorry but I just don't believe you. I've been watching. You attacked another Indie company that did you no true harm. They were trying to raise money to license your product. Sure, they may have used an image without explicit permission but they gave you full credit for creating voxelfarm. They even went so far as to directly link to your website. You should have contacted them and handled it properly. You made it public. So now you have to deal with the fact we have seen your true colors. I don't know what your intent was with that blog post. I'd say it backfired. You shit where you sleep.

      Delete
    7. They made a mistake. So did you. Yours however, is the graver of the two.

      Delete
    8. Oops, did not see that one for what it was and took the bait. Can we move the insults to the right post (the one about kickstarter vaporware)?

      Delete
  12. It seems that EQ:landmark is having some issues with voxels. Are they working on their own now or do they still receive any updates that you do on your project? It just seems from your videos that blending of voxels is better in your demos than currently it is in landmark, where it's quite easy to mess it up whereas your voxels seem to blend in any way you order them to with no issues creating a nice polygon surface. (when you paste in various detailed brushes and templates)

    ReplyDelete
    Replies
    1. Yes both projects are in-sync so far, although EQNL is maybe a little bit behind because even in alpha they are very careful about what new features they expose to players. There are some other issues, like with the line tool, pasting, material blending, missing seams, that are still present in Voxel Farm. You do not see them often in our videos but they are there. We are working on that.

      And then EQNL has a set of custom tools SOE has created on their own, like using the selection tool to add/remove, the sphere tool and several other, which are still on alpha like the rest of the game. It is just a matter of time before they get very polished.

      Even in this state, with some work, it is possible to create very clean models in EQNL. To me that was the main concern, whether we could represent the player creations at both close and very far ranges with the voxel sizes we chose. We need a few rounds of polish for the tools so this level of quality becomes accessible and effortless for the average builder.

      Delete
    2. Well all I can say now is thank you and SOE for making my dreams come true.

      Delete
  13. this looks cool, i have a question though, does this engine also do non procedural worlds?, as in, generating procedurally, fine tuning the result and using it as a static environment like most games tend to have?.

    and you mentioned a Unity plugin on the main website, how many Unity supported platforms does this work with?, and which ones?.

    ReplyDelete
    Replies
    1. Yes, the engine can do static worlds as well. This was the goal eight years ago when I started the project. The real-time aspect is something that came later. So yes, you could design a massive game world, refine it as you see fit and then decide what needs to be packed in the game's final version.

      The Unity plugin we did was for Windows only. This is because at the time the engine was only C++. We are currently porting some key aspects to Java (so we get it running on Android devices) and a similar C# port is on the horizon for us.

      Delete
    2. groovy, i have a few more questions (i ask a lot of stuff).

      the creation of a world and refining it, would you say this is possible with unity?, the scene view has some limits last i heard as to what it can show visibly for editing, and what platforms would the C# port do?.

      can different voxel materials be more resistant to damage than others?, perhaps a large monster leaves footprints in sand easily, but fails to break stone.

      how customizable is the generator?, can it be set to generate different kinds of environments and lands?, can there be differently structured buildings?.

      and the last point i want to make is more of a tip, you show very non-varied environments usually, like small, slightly forested areas, mountains, snowy places and deserts, perhaps you could show some other possible biome variations?, like a lush jungle, or a beach.

      Delete
    3. Voxel Farm includes its own scene manager for all the voxel-based content. That worked in Unity's edit mode as well. You could position the camera anywhere and the meshes would recompute around you. We did not drive user input into the voxel based edition tools we have, but I assume that would work as well.

      Yes materials can have different properties. You can already see this in everquest. Digging takes longer depending on the material.

      You can have the grammars generate different environments and structures, as long as the grammar program accounts for it.

      Thanks for the tip, we show only two biomes (in one you get snow if you are high enough). It takes time to come up with a new biome so we rather work on new features.

      Delete
    4. neat, though i have another few questions (i'm the type to edit posts constantly to add new questions and refine ones i've already asked).

      what are grammars?, i searched on google and didn't find anything to say what it actually is.

      you say it takes time to come up with new biomes, is there any particular reason other than the time it takes to code it in?.

      how big can a world technically get? (minecraft works for about 30,000,000 blocks before everything breaks apart and stops working properly), similarly, can you have a system to input generation "seeds"?.

      how big are file sizes for a world?, how good is the engine performance-wise?, what would you call the minimum requirements?.

      and finally, how easily is the world saved with unity?, if you haven't had a chance to actually try it out, then how well do you -think- it would work?, like with this for instance:

      http://whydoidoit.com/unityserializer/

      Delete
    5. Grammars, in this context, refers to the code system that procedural structures (like trees and buildings) use to determine their shape. One grammar can create a type of building, but can create many many many unique buildings. You can for example make a grammar for a church, and then have the program make a unique church for every village. Same applies to trees.

      Also, it's a good thing to ask questions, though it is also often a good idea to do some research, I suggest that you look through all the previous posts (It's really interesting) and if you're really into it, read the comments as well. (Especially the ones that Miguel responds to) You'll learn a lot =P.

      Delete
    6. hm, i've read all the posts and a lot of the comments, i haven't found anything regarding how much file space this takes other than that this is 4 MB when compressed:

      http://procworld.blogspot.ca/2013/12/more-statues.html

      how big would a compressed world, say, the size of earth be?.

      Delete
    7. The size of the world does not add to the world data size. This world where the statues are found, it is already much larger than Earth. You could explore it entirely and it would not require an additional bit of data. Data is what you change in the world. I have not tried an Earth-sized surface full of unique data, I do not have an answer to that questions now.

      Delete
    8. Small, the only thing that gets saved are entities that get modified. Otherwise, the same world is procedurally generated when you need it.

      Delete
    9. That is correct, Gator. The file size increases as there are more things in the world that are different to the originally generated state.

      Delete
    10. hm, based on what i could see in the video for voxel physics, and the 4 MB file size, it seems that world files can get uncontrollably big easily, though this may just be bad understanding of how much of that data is actually the changes (i suppose the pre-generated data must be stored somehow, right?, unless of course it gets destroyed and recreated as you go there and go back).

      Delete
    11. In minecraft, file sizes get large because the procedurally generated environment is saved as you explore it. Voxel farm freshly generates the environment based on what is needed at that moment, the only data being saved is point data for each voxel that is changed by the user. If you hand crafted an entire earth, the file size would be tremendous simply because everything is bespoke.

      Delete
    12. Any good simulation (like solid physics, water and gases) can produce a LOT of data and/or will take long to compute. This is why we still hack it.

      Delete
    13. hm, right, see, i was thinking about what sort of massive download size it could end up taking for people to download a game using this engine, for instance, an RPG like Xenoblade would most certainly need bits and pieces changed if it used this, lots of changes and added touches, imagine actually having to download a game like that (if you haven't heard of the game, youtube has plenty of videos, and there is a wiki with pictures of maps, it should be easy to get a sense of the size).

      i just considered something, in unity, when putting in an enemy into the scene, would that enemy be remembered to be there like changed voxel are, or would going too far away delete it and be found gone when you return?.

      also, unity scenes have a limit on their size, they eventually stop working properly at a certain distance from origin because float precision gets dodgy, would this need to be split into multiple scenes for loading and unloading?, or does it somehow do this automatically or something?, to illustrate my question better, how well would a game the size of skyrim made in unity with this be done? (i can see that i sound very overambitious).

      Delete
    14. Imagine this, a central server hosts a world with 30 terabytes (or something else ludicrously large). Then, it streams voxel data to users similar to what euclideon does for their 3d scan data. The game developer would be free to manipulate their world in real time with patches or downloads. I think miguel was looking at cliud based systems a while back.

      But back to a voxel driven game. Any skyrim sized world filled with skyrim levels of custom detailing will be massive. The voxel farm should be able to cut back on file size simply by having the ability to spawn unique buildings/props which are procedurally generated. Speeding up both the development time for the game as well as adding detail/intricity that normally would rely on duplicating identical models to reduce file size.

      Delete
    15. yeah, but it's not as if you can make changes to the generation seed to accommodate your vision, perhaps that castle is in the wrong place, but everything else is perfect, what do you do?, the chances of getting the castle to be right on top of that mountain with the huge waterfall are very slim.

      this, along with the possible (don't have an answer quite yet) issue of custom made, non voxel things (like cups, or chairs and other things you would find in a house, or people to live in it) not being possible to persist and the unity scene issues are my only real concerns i have left, since i assume pathfinding works just fine, and setpiece objects like the pre-mentioned tables would work fine for moving platforms (like giant gears you can walk on) and i'm guessing it would be possible to do giant floating islands (if it isn't possible, take note Miguel, giant, floating islands in the sky, i'm sure there is a very easy workaround to the voxel physics that can make exceptions for the islands).

      Delete
    16. That should say without patches

      Delete
    17. I actually wouldn't be surprised if a skyrim sized world in this engine would be about the same size as Skyrim, the extra data used by voxels would probably be soaked up by all the assets and stuff that aren't actually in the world (inside of books, menus, huds, dialogue, scripts, sound etc. etc.)

      But I don't know enough about the specifics of Voxels to say anything about how much space it would take =P.

      Delete
    18. For a game that is fully static, like Skyrim's, you can still use voxels as the source for polygons and then keep it as polygons all the time for the players. In this case the game world data would be pretty much the same I would say.

      What it is interesting to me is now we can change the world after the game is released. I was looking at a TESO stream the other day. There were around 20 characters engaged in a fight. There were a lot of effects flying around still the world remained indestructible all the time. The game looks great, but I think pretty soon static worlds won't do it anymore.

      Delete
    19. to be honest, i wasn't extremely concerned about the size increasing as players break stuff, my main worry was that they would end up having to download an enormous world file after all the needed tweaks.

      i honestly think this engine, or at least this kind of engine is going to become popular, while we aren't quite there yet, there IS an upper limit to graphical detail where making graphics better would be pointless, because the human eye wouldn't see any difference, after that, game developers will need to totally abandon "it has better graphics!" as a reason to buy.

      the empty gap will be filled with awesome stuff like destructible and remoldable terrain, more advanced physics simulation, more advanced water, better and more deep AI, more power to handle more stuff going on all at once and less lag for online multiplayer, better performance in general as computers get better, generally better gameplay and more effort put into tutorials.

      the EQN people are doing it smart, they know what will really matter in the future, and chose an art style that isn't going to be tossed aside by more powerful graphics engines with more polygons and pixels.

      also, now that i think about it, you technically could make the castle thing work, similarly to how you made water generate, you could have a texture map that generates specific things on colored patches, you could have a forest in a specific place and a plain, flat road in another, and then have it regenerate the same way when you return based on the color map, am i right?.

      this means the only concerns i have left are the asset remembrance (no deleting when getting too far away, and no recreating either when you come back) and the unity scene thing.

      also, the floating islands thing, i realize it would actually be real easy, i'm guessing even one voxel identified as "floaty" (like the foundational ones that count for physics) will force all the others to float with it, the hardest part would be the actual generation of these islands.

      Delete
    20. I personally don't think the size for a normal, playable world of most current open worlds would be that bad, besides, people already seem okay with downloading 30 GBs of game (TESO...).

      I don't think Graphics will really stop evolving, they'll continue finding new techniques and stuff, the only way to actually stop this trend of "Gotta have better graphics!", is if the majority of people who play games were to just not care about graphics, unfortunately this isn't the case.

      And for procedurally generated stuff, you don't need to have a texture map, it should actually be more efficient not to have a texture map, as then it's just data with no junk data attached. The only thing that Texture maps are good for as far as I know, is for editing large scale things, not individual buildings etc, showing people stuff (Like the concept of the water), and if you want easily editable stuff on a large scale.

      As for regenerating the same thing, in a procedurally generation program, the only variation is generally caused by the use of (pseudo) random number generators, which take in a seed number, often this seed is something that's always different, but if you fill in the same seed multiple times, you'll get the same world generated multiple times, so you don't even need to store anything other than the seed really =P (And the modifications).
      Note: I'm just answering most of this based on my knowledge acquired through this blog and from my course, so I'm not 100% sure they're true =P.

      Delete
    21. i know, but my point was that you could use a map to tell the seed where to place things, like the water, i may be totally wrong, but to me, that sounds like it would allow placing large things like castles and forests as part of the seed, meaning you don't need to store large amounts of voxel data to be stored when you move the castle or decide where the forest will be generated on your island, maybe you are running out of development time, and you need to dump that volcano level to finish the game on time, just move the volcano somewhere a lot further away and move the path away from it, and voila.

      my point with the texture map is, seeds are different each time, putting teh same seed will give the same world, the only way to make adjustments to the seed is to edit the voxel data and therefore increase storage space a lot, but if my theory is correct, the texture map just supplements the seed, so the texture is just a texture file, the code to interpret the texture, instead of the data remembering that you copied and pasted the castle onto the mountain.

      graphics can and will stop getting better, at about the time when we have truly photorealistic graphics (things like the Avatar movie CGI demonstrates my point), at about that point, no more detail will make any difference at all to the human eye.

      Delete
    22. Generally speaking... The processing power used to run a video game lags behind that used to make cgi movies by about a decade. Further, our definition of "perfection" is always changing, for example, when Beowulf first came out to theaters people were marvelling at how great it looked for a 100% cgi movie. Now however, watching it almost hurts because our standards keep rising.

      Delete
    23. Well, for that, you could make a system in the code, that if you copy paste an entire procedurally generated structure, it just changes the starting point where it usually goes, I understand what you mean, but I do bet there are more efficient ways of doing it.

      Delete
    24. Robin,

      i don't think our definition of visual perfection is going to get higher than what we see in the real world, eventually we simply won't notice higher quality visuals because at that point they will be too small.

      Karmica,

      possibly, there may be a better way to do it, but i'm usually happy with "good enough".

      Delete
    25. I partially disagree, it is far easier to approximate far away details, but when it comes to world items that get within arms reach the quality has immense gaps to fill. Repeating /low detail textures, a complete lack of fluid dynamics on the small scale (i.e. swishing a glass of water or being able to kick/push sand around) it will be decades before we see any reasonable advances, especially when we are so concerned with approximating the further lods.

      Delete
    26. i can't really follow your train of thought here i'm afraid, isn't all that you said part of "real world visual perfection"?.

      also, i would like to say to Miguel, even if you can't find the time to reply to me, while working on the unity plugin, please at least consider the unity scene sizes and the non-voxel objects needing to persist, and preferably to not do this by falling into an abyss when the terrain is destroyed.

      Delete
    27. About Unity scene sizes, whatever resources you have handled by VoxelFarm like terrain, custom interest points, etc. is guaranteed to be manageable. This is because the point of view is always taken into account and we are able to use lower detail copies for data that is farther away.

      For those systems that are not managed by Voxel Farm, let's say you want to place props using Unity's vanilla scene management, you will have to deal with the limitations of each particular engine or write custom managers yourself.

      About visual quality in realtime engines, I think we are eons away from having something acceptable. I believe we are still in the pre-historic stage of the tech. If you have any doubts look at the huge gap there still is between concept art for games and what you finally see on screen. We need to get to a point where we are experiencing the world as it was devised by the concept artists. On top of that these worlds need to be alive and destructible. We are even farther from that.

      Delete
    28. Vortex: Good enough usually isn't good enough in software engineering (which Game Programming is part of), because if you want to advance your technology, or want to fit more into the game etc. etc. you want to be more efficient than "Good Enough" =P.

      Delete
    29. Miguel,

      right, so if my understanding is correct, the terrain and all system related to it and voxelfarm will function infinitely in distance within unity, and anything unity handles will be limited by the floating point imprecision?.

      i realize now that unity assets and other non-voxel things would persist in destroyed chunks, those could simply be frozen in place until someone comes back and the terrain is re-loaded, so that part works just fine, the only issue is floating point precision, which i'm certain affects every engine, is this not a problem with voxel farm?.

      basically, i think this could be solved by either using the futurama method of moving the world around the player or creating a custom co-ordinate system, would either of these solutions work with this engine?, i suspect so.

      so i'm sure the issues i saw are fixable within unity, so that's cool.

      Kamica,

      i can't imagine a texture and code to interpret that texture would be that inefficient, it's like the thing Miguel used for water generation, having something like this for things like locations of biomes and large terrain features like castles and cities shouldn't be that bad.

      Delete
    30. Probably not too inefficient, but to me it seems unnecessary =P.
      I'm not sure if Miguel actually uses those images as texture information thingies, or just as a debug feature.

      Delete
  14. On the subject of Vacansopapurosophobia what was the first thing/feature you created/programmed that has turned into this amazing engine?

    ReplyDelete