WorldKit - A new way to make large scale worlds for Unity

Hello fellow Unity creators! Today I would like to introduce you to a tool that I've been working on that provides a completely new and unique way to build large scale worlds for Unity. For a full detailed description, and video see the Kickstarter that just launched today here: https://www.kickstarter.com/projects/abrown/worldkit-streamlined-world-building/

For a detailed video see YouTube here:

Here are some of the highlights:

• Generate large detailed worlds in seconds with a couple clicks
• Modify the shape and layout of your world easily with paint-like tools
• Place your rivers mountains and features exactly where you want them quickly and easily just by drawing splines
• Get a set of distinct and interesting looking terrain types built in that flow together seamlessly
• Adjust the detail scale of your world quickly with a slider which lets you adjust the size of the terrain features without disrupting your overall layout
• Export a static mesh or full terrain textures for use with Unity's terrain system

The alpha is going to be available to Kickstarter backers in March.

I worked with GrimFox Games to use the alpha build of WorldKit to produce the world used in RoboGenesis. Below are some screenshots of the WorldKit project for RoboGenesis, along with some in-engine screenshots of the world.

Here are some screenshots showing the WorldKit project for RoboGenesis:



Here are some screenshots showing the world in-engine:




For a video showing more of the world in RoboGenesis, see YouTube here:

In the interest of full transparency, here is a list of other content used in the RoboGenesis screenshots to show off the terrain.

• In-house terrain shader
• In-house atmospherics
• In-house fog shader
• In-house water shader
• Textures from Quixel Mixer
• Foliage from SpeedTree
• Rendered in Unreal Engine 4

The entire world for RoboGenesis took about two hours of work to design in WorldKit. All of the basic landforms and terrain were there on export from WorldKit. About 10 hours were spent in engine tweaking and modifying the terrain to be suitable for gameplay. Modifications included better definition and refining of rivers, smoothing of shorelines, adding ramps to get between some terrain levels, addition of lakes in some areas and smoothing minor anomalies in the terrain.

Let me know if you have any questions, comments or suggestions. I hope WorldKit becomes an extremely useful tool in the environment creation pipeline!

 

Is this still using Unity's terrain system, or is it its own thing?

In the latter case, any idea how it performs on mobile?

 

From the pictures it looks like an external tool

Would be great to get a version of the pictures rendered in Unity as opposed to unreal! Currently the foliage you have used is speed tree, of which unreal supports a different version, and the textures are from quixel. Its hard to guage the actual look of this terrain when you combine all that with unreal 4 rendering, coupled with all shaders not being unity based

I also think the amount you are trying to raise is far too much to get funded for a tool like this, it should be like 1/10th that but I do wish you good luck in getting successfully funded!


EDIT: personally I would end the campaign early and relaunch with a much much lower target value so you have a higher chance of getting funded, then continue raising funding through a website/landing page funding initiative. That way you can still aim for the sky without hurting chances of actually getting the funds at the end.

 

WorldKit is a standalone application. It supports heightmap exports in 16 bit which should be usable by Unity's terrain system. Alternatively, WorldKit can also export an OBJ mesh which could be used however you like. The downside to using a mesh in Unity, as I understand, is that Unity has a limited polygon count per static mesh object so a roughly two million polygon mesh would have to be broken into smaller chunks to work in unity. You'd need to do this anyway because if you went with static meshes you'd have to implement an LOD system on the chunks, depending on your world scale. I suspect that using Unity's built in terrain system with the 16 bit heightmap exports will be the best method. This is also the area that Unity is currently working to develop so it will likely be better supported going forward.

We have not run tests on mobile specifically. However, in UE4 the method for producing terrain is the same regardless of whether it's mobile or not. The scale of world you can run on mobile and the resolution you can support on the terrain may be more limited on mobile of course.

 

I agree! I would love to have a version rendered in Unity. GrimFox, however, is writing RoboGenesis in UE4. Also, as you pointed out, the SpeedTree assets are different. Unity doesn't have a similar procedural foliage system to UE4, so actually setting up the grass and foliage would be more time consuming. All of the in-house components and shaders would need to be redone for Unity as it does not have a similar or compatible shader system with UE4. Essentially the only transferable assets would be the terrain itself and the Quixel textures. The textures would be useless without a 16 layer height and alpha blending terrain shader with similar capabilities to the one I wrote for UE4.

In the future I would love to use WorldKit resources to set up a specific demo scene in Unity that's not tied to a production game, but it will have to wait until we raise funds and have time after the Kickstarter campaign.

Thank you for your interest!

 

Well it's a standoff then. I won't pay up until I see some examples in my current choice of engine (Unity), you won't make examples until I pay up.

 

I just wanted to send an update out to Unity developers interested in WorldKit. I've put a tutorial together on how to import WorldKit worlds into Unity. Watch it on YouTube here:

I've been receiving some questions from Unity users on how exactly WorldKit is built for Unity, and where it fits into the Unity creation pipeline. I also wanted to clear up any confusion about shaders or foliage or assets that may ship with WorldKit.

In short, WorldKit does not ship with any Unity specific assets. There are no shaders, skyboxes, water systems, atmospherics, post effects, terrain shaders or textures shipped with WorldKit for Unity or any other engine. WorldKit is a standalone application for quickly building terrain with a high degree of control.

Any images or representations of completed game worlds are merely examples of what can be achieved in a game engine by a skilled team of professionals using WorldKit and your engine of choice.

WorldKit is only one part of the world creation pipeline and in order to make a game ready, production quality world, you will need more assets, or developers and artists capable of producing assets, such as shaders, atmospherics, water, foliage and other static meshes. A lot of in-engine assembly will be required to produce a game-ready finished product.

 

The procedural part looks pretty nice.

Mesh generation I'd have to see more. I would expect chunking, chunk LOD's, and good simplification. That's if I wanted to use the mesh to begin with. But the main point is you need to solve those hard problems to make the mesh stuff really interesting. Personally I don't think meshes make any sense in products like yours. I mean you have to at least match how well the engine terrain system can handle triangulation and LOD. Just basic delauney triangulation doesn't even get you close.

Trying to explain away why you don't need to have native engine support. That's just the norm for products sold to the Unity ecosystem. Your competitors are doing it, it makes your solution look less competitive.

All that said I'd likely try this for the procedural generation stuff. If it was not in C++ but some higher level language with full source access.

 

You are correct. You would not want to use a static mesh for your near terrain in a game engine. For terrain that can be walked on, you would want to use the 16-bit heightmap that WorldKit exports, as demonstrated in the Unity import video, along with the built-in terrain engine.

That being said, it's fairly standard practice, in large game worlds, to use static meshes for far away landscape features that you can't get close to. Think of mountains in the distance beyond your "invisible wall". While built-in terrain systems provide some LOD by essentially uniformly reducing the tessellation of terrain components on tiles as they get further from the camera, the polygon efficiency is generally quite a bit inferior to what you can get with algorithms that take into account the contour and frequency of features. What you would generally do for distant terrain features, that can't be reached, is start with a high resolution mesh that is the right shape and then decimate it and bake down normals to give it more detail. There are some tools like Simplygon and Instalod that do this automatically. It can also be done manually using other tools like ZBrush and Xnormal.

WorldKit provides a mesh export as a high resolution base for people that need to use these techniques for distant terrain, and also for people using other renderers where a mesh is the preferred format. It can be pretty quick and effective to pop the terrain mesh over to your 3D modeling package of choice and cut out a few mountains or canyon walls. Decimate and bake them. Then rotate translate and scale them around to make less seem like more in the distance.

I hope that provides some clarity on the purpose of having mesh export in a terrain generator. I'd hate to see someone trying to use a full two million poly non-reduced mesh as their near terrain. Importing the terrain via heightmap as shown in the unity import video above will be a much better way to go for that.

 

It sounds nice, but I do still think you will struggle to get close to £150,000 for a tool that provides no direct integration / plugin for any editors, doesnt provide any assets, and has had 0 exposure leading up to the campaign other than here from what I can see.

Im not trying to shoot you down as it looks like a lovely tool, but the amount you have asked for and the amount you have raised since the campaign launched hasnt made me change my position: you should end early, and relaunch with a more sensible funding goal so you actually get the money.

You can then try and aim for the moon in funding afterwards using your own webpage for continious funding. But the way you are going, you will in all likeliness not meet funding goal, and because this is kickstarter, you will get no money.

 

Thank you for your opinion. I hear you. I didn't respond the first time because there's not much I can say besides the obvious really. I'll try to explain my thought process. It's quite clear, to anyone with eyes and basic math, that WorldKit will not meet it's funding goal on time. However, I won't, in good conscience, release a piece of software, and take money for it, if I can't afford to build a team to support, maintain, and continue development on that product.

By reducing the funding goals and taking money from people, I would commit myself to delivering a product that I would not have the funds to build a proper support team around. I feel that such an action would be operating in bad faith. WorldKit has more than 5,000 hours of dev time sunk into R&D over 3 years, with over 45,000 lines of code written and over 15,000 lines of code still in the current active product. It is written in Kotlin in quite a compact codestyle, so the equivalent logic would probably have been closer to 90,000 lines of C++ total and 30,0000 active to give some reference. We're talking about a piece of software with just a development salary cost alone worth over $377,000 USD. Taking a few thousand dollars from my strongest supporters and leaving them out of luck when there is no support or maintenance would be, unethical, irresponsible, should be criminal, and it would be a drop in the bucket compared to dev costs.

The Kickstarter campaign for WorldKit is not about getting paid. It's about creating a company that can continue to support and develop the product, banking on future revenue to eventually offset development costs and turn a profit. However, the Kickstarter campaign isn't a waste because it allows me to gauge the size of the environment creation community and the general interest for such a product. I initially started WorldKit because I wanted a tool to do exactly what it does. It fills a niche in the world creation process that is currently not filled by any other tool. I thought, through some calculations based on the size of Unity and UE4 development communities and the number of jobs in game development worldwide, that there would be about 350,000 potential users who would have use for a product like WorldKit. The Kickstarter campaign has, so far, shown that I was off by a lot, and the market likely won't currently bear a product like WorldKit.

I am exploring other options for WorldKit, and hopefully there will still be a way to get it into the hands of creators, or alternatively provide a service for per-export, on-demand world generation, since the real asset is the intelligence behind the application. Regardless, taking a small amount of money from a few people with no assured way of supporting them in the long run is certainly not the way I will move forward with WorldKit.

 

Well I wish you all the best and I really hope you get funded as it really does look like it could develop into a decent tool. Best of luck to you!

 

I've received the following question from a few people asking me if I'm trying to compete with certain existing software packages and I've posted it to the FAQ on the Kickstarter page, but I figured I'd add it here as well for people who find this thread first.

Q: Is WorldKit a cheaper alternative to World Machine, World Creator or Houdini for terrain generation, and why would I want it if I already have one of these software packages?

A: No. WorldKit does not fill the same role as these software packages. Depending on the project you are working on, you might need one of these pieces of software in addition to WorldKit to create a finished product. WorldKit is meant to come before these other software packages in the world creation pipeline.

World Machine and Houdini both use a node-graph based approach to assemble noise, generators, filters, and masks into a procedural network that can be used to produce high quality details on terrain. In the case of Houdini that's a tiny piece of what the software package does. World Creator does similar things using a stack based approach to layering noise, generators, filters and masks with essentially the same end goal.

These software packages can produce very convincing results at final resolution. However, it can take a very long time to create a world, to a predefined specification, if starting from scratch, using these tools. WorldKit fills in this gap by providing fast and artist friendly tools to get a world prototyped in a fraction of the time while sticking to realistic rules for terrain formation that results in believable environments with minimal manual sculpting or artistic talent required.

One workflow that is pretty common when working with World Machine is to start in your game engine of choice and use the built in landscape tools to roughly sculpt your mountains, plateaus, rivers, water bodies and large terrain features where you want them. Sometimes you might stamp in some features from DEM data or other sources. After you've got the rough shape sculpted you can export the terrain from your engine and import into World Machine. You can apply noise, erosion, sedimentation, distortion and other filters in World Machine to get the terrain features to start looking more natural, and then export back to your engine. Sculpt and refine a bit more using the tools in engine. Repeat this round-trip process as needed until the terrain is roughly finished. As a final step you can use World Machine to generate higher quality output and the masks you will use to composite your final terrain layers. You can replace World Machine, in this method, with either of the other software packages above.

WorldKit replaces the first part of this process, removing the need to manually sculpt, and to jump between terrain editor and engine. WorldKit does not attempt to replace these other software packages for the last step of the process where you generate your final high resolution detail and mask layers. We feel these other software packages do a great job at that part already. The cost to try and add that functionality to WorldKit would be an exorbitant waste when there are three tools that do it well, and chances are, most of our end users will already own one of them anyway.

 

hello. this is an application tool for terrain building. i have download your project in github. I imported in J idea IDE 2020.3 and gaalvm，however it always built error when refresh the grandle. i was wondering if you have time to make a video about how to setup up the worldkit project in jidea with gaalvm. thnx