Wednesday, April 15, 2015

Unity 5 Update

Earlier this week we rolled out a rather large update to the Unity plugin. The update went mostly into improving the workflow between Voxel Farm and Unity. You can get an idea of how it feels from the following video:


My favorite feature so far is now we get to see all the voxel geometry while in Unity's Scene mode. This makes possible to place your traditional Unity objects (lights, geometry, characters, etc.) in precise reference with the voxel content.



Another key feature was we now have working physics inside Unity. You can tell this is new because the video spends a good deal of time just cutting chunks out of buildings to watch them fall.

The shading has improved as well. Although this is an area I hope adopters of the engine and SDK will expand by producing all sorts of cool new looks. The realistic rendering included by default in the plugin is an example of what can be done and how to approach rendering in general.

The plugin is still Windows only. That is probably the second most frequent request/question we get. This is because our code is unmanaged C++. I wish there was a simple way around this. At this point we are contemplating re-writing parts of the engine in C#, which will take precious time we could be spending on new features.

40 comments:

  1. Nice work as usual Miguel.

    However I wonder still why you seem to think unmanaged C++ plugins are so hard to make cross-platform? As long as you have no Windows-only dependencies it should be trivial to compile the VoxelEngine plugin for OSX, Linux and Windows for Unity. I must be missing some hidden complexity?

    ReplyDelete
    Replies
    1. No, you are not missing anything. Linux/OSX could run unmanaged plugins, but these are not the platforms we are asked about. It is really about Android, Web and iOS. Last time I checked Unity would require you to have only managed code to have your project working on these. Do you know different?

      Delete
    2. Ah, yes you are of course right on that count as far as I am aware. However it would appear to me that the better course of action might be to rely on the client/server model for those platforms - It would seem like a pretty unreasonable amount of power to expect from such platforms?

      Delete
    3. Yes client/server is the low hanging fruit. Still most tablets and phones would be able to run Voxel Farm locally. You would not run full blown procedural generation, which is what takes a lot of processing power, but there are simpler worlds and concepts that would work nicely. For instance a top down dungeon crawler like Diablo would be attainable without any server side help. Also since screen sizes are much smaller, you can get away with lower voxel densities. It is really about our codebase being C++ and Unity being unable to use it like that.

      Delete
    4. We're asking about Mac & Linux! We're hoping to purchase a Voxel Farm license, possibly the AAA version, but no Mac/Linux would be a dealbreaker.

      Delete
    5. Like Scott was saying above, Mac/Linux support is kind of trivial if you are getting the source code, which is included in Pro and AAA. We could include it in the Indie SDK, but I wonder if it is worth the effort at all.

      If you check the hardware/software stats at Steam, Mac and Linux combined are below 4.5%. In engineering that would be considered close to a measurement error, let alone a dealbreaker :)

      I am very curious about the rationale behind this, why someone would think this particular 4.5% is important. A single platform with 95.5% penetration is a developer's dream. If you game is a runaway hit, then you can worry about the niche platforms you may be missing. But you need a hit before that becomes a good idea.

      Am I making any sense?

      Delete
    6. Thanks for the reply. If it's not too difficult to add then great, it looks like we'll be getting the source code.

      That is a good point about the 4.5% of Mac/Linux users on Steam. The rationale for wanting to support Mac/Linux is that 'back in the day' I often read that indie devs were making up to 50% of their revenue from Mac/Linux. Off the top of my head I know Wolfire has a couple posts talking about that: http://blog.wolfire.com/2010/05/The-state-of-Mac-and-Linux-gaming
      http://blog.wolfire.com/2010/05/The-state-of-Mac-and-Linux-gaming

      We also really want to support Steam Machines/SteamOS. We love Valve and have a deep hatred for Microsoft.

      And we've actually already made somewhat of a hit which is how we have the funds for the AAA license. And every time one of our players asks if the game is coming to Mac or Linux we've always told them to wait for the sequel. I guess we're not absolutely deadset on having Mac/Linux builds, we just really want to even if it meant no Voxel Farm.

      In any case all that doesn't really matter since I now finally realize that we can just add Mac/Linux support ourselves if we have the source code, so my only wish then would be to have Mac/Linux support "out of the box" when buying Pro or AAA with minimal effort on our end, but I understand if adding that isn't worth the effort for your business (I'm not suggesting to include the source code for the Indie SDK).

      Delete
    7. Haha, love and hate :)

      I understand game development is not rational for the most part. If we were so rational we would be likely doing banking software instead.

      We'll have a look, you are right that it may be worth the effort.

      Delete
    8. I'd just like to point out that there may be a large Mac/Linux user base who don't use Steam, so that 4.5% is not necessarily a good indicator of actual market size.

      Delete
    9. Sure, but there is also a large Windows user base who does not use Steam.

      Delete
    10. Of gamers, I imagine the proportion of Windows users who don't use Steam compared to Mac/Linux users who don't use Steam would be lower...blah blah pointless argument. :)

      Delete
    11. Yes, how many Linux/MacOS users can sit on the head of a pin.

      Delete
  2. This video was such a tease. Was anyone else waiting to see how the physics breaks when all the columns are cut at the bottom, so the shape is really complex?

    ReplyDelete
    Replies
    1. Looks great!

      BTW, in the past you've presented videos with a max voxel resolution of 0.30m with 64x64x64 voxels per clip map cell.

      This would suggest that at roughly 10m away (0.30m * 64 * 0.5) resolution would halve to 0.60m, and then halve again at every 10m increment.

      Yet in this video we appear to see fairly fine grain detail even 50m aways. The only clear LOD degradation happens around 13:12 with some distant pillars.

      Are the numerical parameters different for this plugin/video, or are you doing some fancy tricks like morphological sampling for distant geo? Or maybe the pillars just all happen to live on low resolution grid lines? :D Maybe some combination?

      Thanks!

      Delete
    2. Grr. Reply fail.

      Delete
    3. You are missing one key factor: the clipmap does not change resolution on every consecutive cell. Looking into the horizon you may have 6 LOD0, then 3 LOD1, then another 3 LOD2, etc.

      The resolution here is 40x40x40 voxels per cell. It is 0.3 meters at the first LOD we display (which is LOD2). LOD boundaries are configurable at runtime.

      Delete
    4. Outstanding!
      That one little detail has bothered me for longer than I care to admit, be it while watching your own videos or playing Landmark.

      As far as your second point about LOD 2 being first, you're just saying this particular session was configured to run at 0.30m top resolution, but could have been run as fine grain as 0.075m right?

      Delete
    5. Btw, it was great meeting you at GDC! (I was the engineer from EA Maxis who did graphics for The Sims 3 & 4.)

      Delete
    6. Yes I remember you!

      LOD2 beging the closest LOD is something you set at compile time. It is just a way to make your project future proof. If your application is widely successful and has a very long life, you could decide to make the higher resolution LODs available at some point. By reserving high-res LODs you get to do that without breaking any of the existing content or logic. The key design remains the same.

      Delete
  3. I'm curious how far away do you think we are from when the texture of the brick is the voxel itself rather than being painted on.

    ReplyDelete
    Replies
    1. There are some voxel engines that already do that: Atomontage and Euclideon. They look kind of pixelated unless you store massive amounts of data, which is kind of a dealbreaker for entertainment applications. I guess the real question is when can we have a 1:1 voxel to pixel ratio.

      If screen resolutions had stayed at 1080p I'd say we would be at two or three years from it. WIth 4K and now 8K resolutions this is becoming more difficult.

      Delete
    2. What about micro procedural generation i.e. procedural geometry generation for physical surface bump maps? This is going to become far more powerful with vr applications allowing you to get really up close and personal with geometry.

      Delete
    3. Yes that would work, assuming you can generate fast enough.

      As I see it, a texture that tiles is the most basic form of procedural generation.

      It is the opposite of having uniquely colored voxels.

      Delete
    4. Assuming all data is equal if a person were to look at a close up texture you could get a tremendous amount of generated detail even at a 10:1 pixel:voxel ratio. The positive side effect of looking at a 3d generated texture would be that you would be cutting out how much processing you have to do on far away lods.

      Delete
    5. Agreed, however the challenge is coming up with a 3D generated texture that looks right.

      Delete
    6. I think that many 3d textures for biological / natural shapes could be generated by (mis)using potential flow theory ( http://soliton.ae.gatech.edu/labs/windtunl/classes/lowspdaero/lospd4/lospd4.html )
      sets of simple sink/source and vortex equations can be used to create flow-lines which follow the inside of, for example, a tree, these can then be used to define the year-rings that become visible when the tree is cut.
      Alternatively, if the object is procedurally generated, the basic parameters of the object (for example the skeleton of the tree) can be used to accurately define the internal patterns of the object.

      On a sidenote; I am still hoping for realistic procedurally generated agricultural landscapes (although I understand that the main push is in other directions at the moment).

      ScrapHeap

      Delete
  4. Hi, how are you coping with the collision mesh updates in Unity? In Unity 4 they were really slow to update, and had a large memory consumption. I don't know about 5 yet.
    When people start developing large complex towns with really fine details, I fear you'll run out of all the user's resources quite quickly.

    ReplyDelete
    Replies
    1. We only need to keep the current scene, which benefits from the LOD aspect same as with rendering. Creation and removal of meshes is fairly quick so the whole approach appears to hold for extended periods of time. We have not encountered any issues in this regard, however we are focused on 64bits. Sometimes it takes a bit of time for the garbage collection to reclaim memory.

      Delete
    2. Thanks. So the collision is usable for right to the horizon? (For AI)

      Delete
    3. No, we only bake a few LODs. It is probably five of them. Horizon is at LOD 10 or so.

      Delete
    4. Could collision be done against the voxel data directly? Is that part of the LOD system also?

      Delete
    5. You could test collisions against the voxel data directly, which is available for all LODs. In most cases however people just use legacy systems which are triangle based.

      Delete
    6. I guess it'll have to be a triangle mesh for Unity.
      One problem I had with using LODs for collision poly mesh is that the sudden pop could make the physics get a massive vertical impulse force at is base, but I guess things be glued down if necessary at a certain distance.

      Delete
  5. Um I bought the creator version but can't seem to find the folders that we have to move about to make it work? The first few minutes of the video are a bit blurry and that makes reading the paths and filenames hard. I don't see the sdk or folders displayed. What have I missed?

    ReplyDelete
    Replies
    1. There is no Unity 5 plugin in the creator version. You will need Indie or Pro to be able to use Voxel Farm to create games in Unity or any other engine.

      Delete
    2. Yes but I can't see the other assets either. Nothing. I can't find any of the textures. I gather for basic operation of the creative version you should see what I see when you demo the program itself. I.e. before touching unity. I'm not even seeing the demo file. Has it mis installed?

      Delete
    3. Please write to support at voxelfarm.com. They will help you out. I do not think you are missing anything. There are no demos pre-installed. You can download some from the documentation site: http://docs.voxelfarm.com

      Delete
  6. I am still waiting for a video that shows the user how to start with a new project and build his own. So far, all I've been able to do is open the sample projects.

    ReplyDelete
    Replies
    1. Not a video, but this could help: http://docs.voxelfarm.com/starting-a-new-terrain

      Delete
  7. Is there's an official Voxelfarm support forum coming soon? Otherwise, we should probably create a reddit support thread for all the early adopters (I just purchased Pro today!) or somesuch to augment VF's support channels and openly aggregate all the little lessons learned like this http://gamasutra.com/blogs/TrentPolack/20150514/243421/The_Tools_and_Tech_of_All_Things_Die.php

    ReplyDelete