Orbis is a terrain rendering engine built on Unity DOTS, with a focus on extensibility and performance. It can be used for spherical and flat terrains.
IMPORTANT
This asset will only works with DOTS projects built with the Entities 1.0.0-exp package (currently using 1.0.0-44exp. It cannot work with regular Unity projects built without DOTS and ECS.
You must use Unity 2022.x for DOTS development (not older or newer versions).
DOTS is heavily under construction, and many of the tools & features that one might expect in a game engine are not there yet.
This asset will be in preview for as long as DOTS itself is in preview. Until Orbis reaches v1.0, its APIs could change in order to keep up with DOTS advancements. This includes possible breaking changes between updates.
Support does not cover how to work with DOTS in general, or how to create online games in general.
Features:
Render Flat and Spherical Terrains
Can be Heightmap-based or procedurally generated
Physics collider generation on demand
Blazing fast, all computationally demanding tasks are executed in burst-compiled jobs.
Jobs are run in the background, and will never block the main thread
Runtime scattering of vegetation across terrains, will be streamed in and out based on the camera position
Includes a floating origin system to allow the creation of huge worlds
Seeing your spherical worlds loading so quick makes me really wanted to use this for my sci/fi survival game, but I want to support tunnels and holes, so I assume I need to make my terrains voxels to do that still, is that correct?
Hi, yes your are correct. Orbis terrain modifications are only height-based, so creating holes and tunnels is not possible, and would require a voxel terrain.
I remember looking into Amandine’s Digger PRO solution many months ago, but I ended up picking a voxel solution and was overwhelmed with the complexity of implementing that voxel solution into my own game, so I fell back to static terrains at the time.
Would you say that Orbis is “easy” to implement if I already understand the basics of the unity terrain system?
That depends on how experienced you are with the new DOTS, and what you want to do with it. To get started you can just drag in some prefabs, select your terrain heightmap or a procedural generator, and that’s it.
Getting foliage on the terrain just requires you add a few prefabs to it. But if you want to do some heavy customizations things can get more complicated.
Hi I’m interested in Orbis - DOTS Terrains and would like to know a few things about it like how other assets would integrate with it. Would Microsplate, The Vegetation Studio Pro work out of the box with this and if Gaia Stamps/Stamped Terrain can be transferred to Orbis Spherical terrains at all.
Thanks.
I bought Orbis and set it up a few times to try to resolve the materials not showing up. No matter which version of Unity I use as listed in the docs I get ‘Hidden/Internal/ErrorShader’ and magenta textures for everything. I’m running on Mac OS Big Sur (latest version), Unity 2020.3.15f2, crazy amounts of Ram (48gb) and HD Space (2tb).
I’m just using the Built-in renderer and it does not mention having to set up any rendering pipelines for that. I’ve installed all the packages in the installation doc and everything compiles fine and runs okay you just have no textures except for the skybox working.
How can I get all of these materials fixed (every single one has the same error and shows magenta)? Replacing them with the Standard Shader didn’t help much.
Hi, thanks for reaching out. Orbis itself should be compatible with the built-in renderer. If i understood you correctly, the terrain itself does render and show up.
The sample materials for the terrain and the atmosphere that are included in the “Demos” folder are shader-graph based and will therefore only work in URP and HDRP (as stated in the “Render pipeline compatibility” section in the asset store). The terrain renderer is capable of using any valid material supplied, so you can use any of the default shaders and it should work fine. You mentioned that replacing the materials with the standard shader didn’t help much, can you verify this by creating a new material with the standard shader and referencing this new material in the “Orbis Interface” component?
Hi, Orbis renders terrains using Graphics.DrawMesh() calls, which means that MicroSplat should work just fine using the Mesh Workflow of it. Basically, any 3rd party shader that does not have any GameObject dependencies should work just fine with it, so that includes most terrain shading assets.
Vegetation Studio (Pro) does only work with Unity Terrains, so i don’t think it’ll work with Orbis. However, Orbis includes methods to procedurally spawn foliage based on biome, slope, height, etc (although probably not as sophisticated as vegetation studio). The “Mesh Terrain” feature of Vegetation Studio pro also depends on a mesh renderer component, which does not work with Orbis since Orbis is using the new DOTS approach and does not have mesh renderers.
If Gaia allows heightmaps of stamped terrain to be exported then it could be used together with orbis, but that might not be the best approach.
Awesome. Once I started in URP it all worked great! I didn’t realize Built-in wasn’t functional out of the box and you had to start with a working URP / HDRP setup.
Okay, toyed with it more. The atmosphere seems to jump around so when you go towards the moon or big brown planet the atmosphere will jump back onto you when it should still be on the Earth like planet. Perhaps it’s not using the floating origin system correctly?
The spawned cubes are pretty cool to see but they generate no shadows. They also render in a strange order (no z buffer clipping?) as the ones further away (the ones colliding on a planet) show through any newly spawned or closer objects. Fix?
Also, I tried setting this up in HDRP (upgrading from URP and also by starting as an HRDP project). I’ve have had poor results. The terrains are all grey and the trees and atmosphere is magenta. Seems that converting the materials to HDRP is not doing all that it needs to. Suggestions for getting this working in HDRP? (Using 2020.3.16f1, macOS Big Sur). URP works but not HDRP.
Hm i’ll take a look at the atmosphere jumping around, that sure sounds like a bug.
The spawned cubes are just samples and are only intended to demonstrate that the physics are working correctly.
The shaders should be HDRP compatible, if you’re seeing magenta something might be wrong there. What has helped in the past is to open up the shader graph and press recompile, that might fix the issue. If not, please message me again.
Hi!
I’ve bought your asset last week, and i have about 2 weeks now for testing with a friend on a jam.
I’ve personally made a custom planet generator in unity few years ago (I know the difficulty of each parts) and that’s cool to have one in ECS. Thanks for your work!
So, for my first feedback
I’ve the same problem with the Skydome jumping (when outside of the floating range ?)
I’ve observed in the prefab that the Skydome object don’t have floating origin and the convert to entity scripts. And when added, the object isn’t drawn anymore.
Also in contrast, the atmosphere have these two script, but isn’t showed with them, and are correctly drawn (but jumping) when the two components are removed.
When both atmosphere and Skydome objects have Convert and floating scripts, two errors are logged in the console (with or without gpu instancing activated on respecting materials):
A Hybrid Renderer V2 batch is using the shader “Shader Graphs/SkydomeShader”, but the shader is either not compatible with Hybrid Renderer V2, is missing the DOTS_INSTANCING_ON variant, or there is a problem with the DOTS_INSTANCING_ON variant.
A Hybrid Renderer V2 batch is using the shader “Shader Graphs/AtmosphereShader”, but the shader is either not compatible with Hybrid Renderer V2, is missing the DOTS_INSTANCING_ON variant, or there is a problem with the DOTS_INSTANCING_ON variant.
Also, there are many warnings :
Internal: JobTempAlloc has allocations that are more than 4 frames old - this is not allowed and likely a leak
Internal: deleting an allocation that is older than its permitted lifetime of 4 frames (age = x)
Do you think that I’ve made a mistake on the use of the tool ? Or is it something that you’re working on ?
Is there a more precise setup (unity version and package) that would work better and you could recommend currently?
Why also use particular “preview” version of burst ?
Edit: I’m on Unity 2020.3.15/URP/HybridrendererV2 and all packages recommended in the Orbis docs
Hi there, glad to hear you’re using the Asset. The Skydome jumping will be fixed in the next version, together with the shader warnings.
The “JobTempAlloc has allocations that are more than 4 frames old” warning means that some of the jobs (probably the ones generating the meshes) are taking more than 4 frames to finish. This is only a warning in the editor, and should not be a problem in standalone builds, as the jobs there will be running much faster without safety checks. If you get too many warning in the editor, you can do the following steps to speed up the mesh generation speed:
Ensure burst compilation is enabled
Try disabling safety checks in the burst menu
Increase the LOD distances in the Orbis configurator or change the LOD bias in the terrain entity. This will result in less jobs being run in total, the they can finish faster.
Lower the resolution of the terrain patches. This will result in each terrain chunk being lower-res, so they can be generated faster. Note that the resulution should be a multiple of 2 1 (2x + 1), and the distances have to be adjusted accordingly.
Lower the application’s frame rate, as @kenlem suggested.
I’ll take a look at the burst compiler version, i believe it should also work fine with the latest non-preview version.
Thanks for your answers.
I’ll give it a try, it would be great if we could use the latest verified version of burst. (The one default used by Entities / Physics (1.4.11)… As there are only few verified dots packages… ). Or, having to choose between them, and use the latest preview, maybe just for performance reason ?
For issues, I’ve finally fixed them. (Re-edit and save the 2 shaders who trig the error. And as I said, add the two missing component on the Atmosphere object)
All is working now. It look awesome , at about 200 FPS with the demo planet scene in the editor,… I’ll check a build.
My current working setup is:
-Unity 2020.3.15
-URP 10.5.1
-Hybrid renderer 0.11.0-preview.42
-Entities 0.17.0-preview.41
-Burst 1.6.0-pre-2
-Physics 0.6.0-preview.3
Hey so I was looking at the demo and I found quite a bit of “seams” when moving the camera around - assuming this is where the LODS intersect - is this a know issue, any plans on how to address that?
Hi, there are multiple ways to prevent visible seams. The terrain entities have a ‘NodeSettings’ component, where you can enable the parameter “Generate Skirts”. This should completely eliminate visible seams at minimal performance cost. Another option would be to increase the lod distances, making the seams less visible
I’ve made a build on Oculus Quest and it works.
The framerate is only 20FPS, but it’s due mostly to the shader.
With the shader in unlit and only diffuse, FPS increase to 72 and stay there, as the system have some reserve (app T is about 11ms). Does the meshes have UVs?
Hi, yes the meshes are fully UV mapped, and should work with any shader. In the “Flat Terrain” Demo i’m using a material/shader that uses a flowmap for extra detail without any triplanar texturing. You can check it out for an example,
Also, the Demo/Textures folder includes a UV checker texture, apply that to the terrain so you can directly see the UVs