[Released] Orbis - DOTS Terrains

Hi, i haven't actually had the chance to check out entities 0.51, as i'm on leave for a couple of weeks. Will do as soon as i get back (sometime in august). But from what i've seen, 0.51 doesnt break as much as 0.50, so it might already work.

 

Awesome work, is it possible to work with digger? https://assetstore.unity.com/packages/tools/terrain/digger-terrain-caves-overhangs-135178

 

Hi, I think digger only works with unity terrains, so i don't think it'll work with Orbis.

 

I feared so. If the orbis terrain is custom mesh it wont work :/

 

chanced upon your asset, very impressive work. Is it possible to load a full city into orbis terrain? thanks.

 

Hi, what do you mean by "loading a full city into orbis terrain"? You could of course load any building/city assets you'd want, and surround it with orbis for the landscape. For buildings and similar things you can't use Orbis directly.

 

I also just published an Update of Orbis to the asset store:

• Update to entities 0.51
• Added burst compilation options to main mesh generation job, giving a slight performance boost
• Use pre-computed inverse transforms in mesh generation jobs for an additional performance boost

 

I got an error when I was using E to dig the ground. After that, I can't use the E button function

 

Hm, can you provide me with some further details on that? Is it happening when you are close to the ground? Did the ground move/deform when first used or did no visual change occur? Is it on a flat or spherical terrain?

 

Hi David .. I just bought your asset a few days back and as others say it's a good insight into using DOTS. I had decided I wanted a DOTS terrain engine for my project and was just about to start on quad tree etc but found this so it's a great place for me to start! Have just started trying it on mobile and it performs really well. I know you only just upgraded it to 0.51 but what do you think about 1.0? Was thinking of having a go myself but it's a little bit daunting as I'm still getting used to DOTS!

 

Hi David, I am getting a missing script error on the FlyCamera prefab using Orbis version 0.5.0. Do you know which script I should point it to?

 

Hey maybe I can help .. should be "UniversalAdditionalCameraData" .. guessing you need to use URP for this to work.

 

Hi, thanks for reaching out. The sample scenes were setup using URP, so it's expecting the "UniversalAdditionalCameraData" component to be present. Orbis itself should be compatible with all rendering pipelines when given compatible materials.

 

Regarding the version compatibility: I am planning on upgrading Orbis to the 1.0-exp version, but did not get to finish that upgrade yet.

 

Hello, My name is Snake Plissken, I have purchased this asset many moons ago and now its about high time i did something with it, i have message here before years ago and have had it working in the pass, but now for some reason i cant seem to get it up and runing. i have tryed with multiple versions of 2020.1.x , 2020.2.x and 2021.x . i generally want to ask here at the moment : " What are the/ or all of the confirmed working versions of Unity that Orbis Dots works in? " side note but off topic: i am trying to get this working with Rival Character Controller. any information would help and thanks so much for your work in a great project if the author reads this. if anyone reply's thank you so much but no worry's if not. thnx.

 

hey i just noticed that if things get updated to those 1.0.0 packages everything should work with the latest version of Rival. this i can not wait for my friend. keep up the great work. ( atm i use rival as a base in another project and primarly as a learning exsample on what i have done thus far in trying to dev my own character controller for my use in orbis. ) so yeah. i cant wait. keep it up

 

Any updates on when the upgrade to 1.0-exp might be released?

 

Hi, sorry for the late reply, I was busy with some personal Issues. But I hopefully will be able to publish the 1.0.0-pre.44 compatible version by the end of this week. I also have some other more news regarding Orbis and a roadmap available soon.

 

Hi everyone, so I just submitted a new version for Orbis. This will make it compatible with the latest 1.0.0-pre.44 Unity Entities version. Here is a list of the changes:

• Update to entities 1.0.0-exp44
• Update all systems/components/authoring workflows to work with the current latest entities versions
• Remove editor preview, this will be replaced later with an in-editor version of the Orbis systems that will also run at edit-time
• Orbis now uses sub-scenes for conversion
• Added a new authoring component for baking, which will setup all terrain types. No more manually addind/removing components
• Materials are now referenced using managed components
• Vegetation settings are now stored on the root-entity of each terrain quadtree using a dynamic buffer
• Added selection helpers for planets
• Added a baking system to unparent orbis terrain elements during conversion
• Heightmaps/Stacks now get added to the OrbisConfigurator from the new baking component
• Simplified/combined some settings
• Added Custom Baking Editor
• Spherical planets now calculate their correct size and sphere center automatically when each side shares a common parent, planet size is then adjusted using the radius
• Remove EditorCoroutines package
• Add new skybox for the flat terrain sample scene
• And many more smaller changes & optimizations

The asset store approval process might take a few days, so please give it a few days before you check it out. If you spot any bugs or issues, feel free to report them to me

 

Regarding the future of Orbis: A while ago I began a complete recreation of the asset, with this new version focusing only on spherical worlds (e.g. planets). As Unity is expected to release a DOTS-compatible Terrain solution sometime soon, I don't want to run into direct competition with that. Supporting only planets does simplify many things. This new version will also switch to a stamp-based approach (instead of the heightmap/scattered/procedural one), which will allow much more creativity and control over the resulting terrain.
Another big change will be the meshing itself, as I have implemented a new meshing solution which will be able to vary the vertex spacing based on the detail in the area around it. This means that in flat / planar areas, the vertex density will be much lower, resulting in the final vertex count being much lower. The authing and conversion workflow, aswell as the job scheduling approach will also be completely overhauled, which should get rid of a couple of bugs and issues, while improving performance even more and reducing code complexity. Vegetation will also be completely redesigned.
However, these new updates/changes will be too drastic to just be an update to the existing asset. So I plan to release those changes as a new asset to the asset store, and give existing customers a free upgrade path to it. The bulk of new features will then only come to this new asset, and will be called "Orbis Planet Designer".
The existing "Orbis Terrains" will still continue getting updates and bugfixes, as well as the inclusion of some more features that were introduced with entities 1.0.0 (the current release is pretty much just a direct port of the 0.51 version, with a few things that definitly could use some changes with the new version). But the "main" new feature development will then be for this new "Orbis Planet Designer" asset.

 

Firstly, thank you for the excellent work you are doing with Orbis. 10/10, cant praise it enough. Huge help and essential instrument for a game I'm working on.

Secondly, is it possible to persuade you to continue to include flat-oriented terrain and heightmap based approach in your future asset?
Unity is not known to deliver finished solutions on-schedule. We don't know when the "sometime soon" will actually happen, what shape their solution will be in, what features it will offer and how long it will be till it is indeed ready-to-use.
While you are already proven and capable provider of an excellent DOTS Terrain asset.

 

I tried following the install steps for the new ECS 1.0.0 version of Orbis but i get these string of compiler errors about the transform. Am I missing a package? I'm using unity version 2022.2.12, i also tried the newest 2023 beta version with same errors.

Any help would be awesome

 

Same thing here, just bought it and I get those errors.
I think this is because it uses exp44 and not the more recent exp65.
I already had to deal with transforming some of the scripts from exp44 to exp65 where LocalToWorldTransform has become now LocalTransform, so I think it's something similar here.
Hopefully though the dev updates this soon.

 

So not a proper fix but it gets rid of the errors:

Modify CustomGravitySystem.cs and OrbisRenderingSystem.cs and replace any instance of WorldTransform to LocalToWorld.
Modify OrbisBakingSystem.cs and FloatingOriginSystem.cs and replace any instance of TransformAspect to LocalTransform, also LocalPosition field to Position.
Modify OrbisSystemGroup.cs and add partial keyword to the class.

With that said, this was just a quick run to try to remove the errors. Only the Flat Terrain demo seemed to work as desired with these changes, the Star system demo terrain flickers and the Heightmap one throws a KeyNotFoundException.

 

Hi everyone, I'm currently in the process of sbumitting a new version, which will include compatibility with the most recent (exp65) entities version, as well as some minor improvements and bugfixes. It should be approved by unity within the next few days I hope.

 

Hi, Thank you for the fast reply and fix.

I deleted the old version from the project and imported the new one, errors are not there anymore.
One issue though is that the demos for Star System and Heightmap still do not work. the following error is spammed in the console:

Code (CSharp):

1. KeyNotFoundException: The given key '34712' was not present in the dictionary.
2. System.Collections.Generic.Dictionary`2[TKey,TValue].get_Item (TKey key) (at <cbc72d4a9767498db39486e941a498e3>:0)
3. Orbis.VegetationSpawnerSystem+VegetationSpawnerSystem_62FF658E_LambdaJob_0_Job.OriginalLambdaBody (Unity.Entities.Entity ent, Orbis.Components.QuadtreeLodNode& lodNode, Orbis.Components.QuadtreeLODLevel& lodLevel, Unity.Transforms.LocalToWorld& ltw, Orbis.Components.FloatingOriginRepositionTag& floatingTag, Orbis.Components.NodeSettings& nodeSettings, Orbis.Components.QuadtreeRoot& rootRef) (at Assets/Orbis/Orbis_Terrains/Scripts/VegetationSpawnerSystem.cs:64)
4. Orbis.VegetationSpawnerSystem+VegetationSpawnerSystem_62FF658E_LambdaJob_0_Job.Execute (Unity.Entities.ArchetypeChunk& chunk, System.Int32 batchIndex, System.Boolean useEnabledMask, Unity.Burst.Intrinsics.v128& chunkEnabledMask) (at Temp/GeneratedCode/NewAssembly/VegetationSpawnerSystem__System_14942495870.g.cs:184)
5. Orbis.VegetationSpawnerSystem+VegetationSpawnerSystem_62FF658E_LambdaJob_0_Job.Unity.Entities.IJobChunk.Execute (Unity.Entities.ArchetypeChunk& chunk, System.Int32 unfilteredChunkIndex, System.Boolean useEnabledMask, Unity.Burst.Intrinsics.v128& chunkEnabledMask) (at <ff9bfe52bcad4875a0b52966873ba6f9>:0)
6. Unity.Entities.JobChunkExtensions.RunByRefWithoutJobs[T] (T& jobData, Unity.Entities.EntityQuery query) (at ./Library/PackageCache/com.unity.entities@1.0.0-pre.65/Unity.Entities/IJobChunk.cs:267)
7. Unity.Entities.InternalCompilerInterface+JobChunkInterface.RunByRefWithoutJobs[T] (T& jobData, Unity.Entities.EntityQuery query) (at ./Library/PackageCache/com.unity.entities@1.0.0-pre.65/Unity.Entities/InternalCompilerInterface/InternalCompilerInterface.cs:259)
8. Orbis.VegetationSpawnerSystem.VegetationSpawnerSystem_62FF658E_LambdaJob_0_Execute (Unity.Entities.EntityCommandBuffer& commandBuffer, Unity.Jobs.JobHandle& scheduledJobs, Unity.Entities.EntityCommandBuffer+ParallelWriter& parallelBuffer) (at Temp/GeneratedCode/NewAssembly/VegetationSpawnerSystem__System_14942495870.g.cs:252)
9. Orbis.VegetationSpawnerSystem.OnUpdate () (at Assets/Orbis/Orbis_Terrains/Scripts/VegetationSpawnerSystem.cs:38)
10. Unity.Entities.SystemBase.Update () (at ./Library/PackageCache/com.unity.entities@1.0.0-pre.65/Unity.Entities/SystemBase.cs:418)
11. Unity.Entities.ComponentSystemGroup.UpdateAllSystems () (at ./Library/PackageCache/com.unity.entities@1.0.0-pre.65/Unity.Entities/ComponentSystemGroup.cs:708)
12. UnityEngine.Debug:LogException(Exception)
13. Unity.Debug:LogException(Exception) (at ./Library/PackageCache/com.unity.entities@1.0.0-pre.65/Unity.Entities/Stubs/Unity/Debug.cs:19)
14. Unity.Entities.ComponentSystemGroup:UpdateAllSystems() (at ./Library/PackageCache/com.unity.entities@1.0.0-pre.65/Unity.Entities/ComponentSystemGroup.cs:713)
15. Unity.Entities.ComponentSystemGroup:OnUpdate() (at ./Library/PackageCache/com.unity.entities@1.0.0-pre.65/Unity.Entities/ComponentSystemGroup.cs:666)
16. Unity.Entities.SystemBase:Update() (at ./Library/PackageCache/com.unity.entities@1.0.0-pre.65/Unity.Entities/SystemBase.cs:418)
17. Unity.Entities.ComponentSystemGroup:UpdateAllSystems() (at ./Library/PackageCache/com.unity.entities@1.0.0-pre.65/Unity.Entities/ComponentSystemGroup.cs:708)
18. Unity.Entities.ComponentSystemGroup:OnUpdate() (at ./Library/PackageCache/com.unity.entities@1.0.0-pre.65/Unity.Entities/ComponentSystemGroup.cs:672)
19. Unity.Entities.SystemBase:Update() (at ./Library/PackageCache/com.unity.entities@1.0.0-pre.65/Unity.Entities/SystemBase.cs:418)
20. Unity.Entities.DummyDelegateWrapper:TriggerUpdate() (at ./Library/PackageCache/com.unity.entities@1.0.0-pre.65/Unity.Entities/ScriptBehaviourUpdateOrder.cs:526)

In both cases the terrain is not displayed.
I have not yet tried to create my own terrains based on these so I'm not sure if this a demo issue or an actual issue in this version.
The Flat Terrain demo on the other hand is working as desired.

PS: All required packages are imported (Entities/Graphics/Physics), unsafe code checked in Project Settings. Unity 2022.2.15

PS2: It seems the error is related to the VegetationSpawnerSystem, but checking the subscene in both demos which don't work the Vegetation Settings list is empty, on the other hand the Vegetations Settings list does have 1 element in the Flat Terrain which works, so I'm wondering if the issue is that the system is being invoked even though it should not be when the list is empty.

PS3: I've added an element to the vegetation settings list of each prefab in the subscene of the non working demos, left the element empty (no prefab set or other settings) and when playing other than a few errors which I think are related to the empty prefab, the terrain is now displayed and the spammed error is gone, so I can confirm the issue is related to the fact the system is running the SpawnVegetationJob when it should not.

 

Hm, thanks for reporting this issue. I sometimes got this error when the entity subscene is not loaded. Can you check if the subscene has the little checkmark in the inspector when you get this error?

 

Hey, this looks quite amazing. I'd like to ask a few questions before pulling the trigger and getting it.

Currently my workflow relies heavily on multiple assets to save time, increase visual quality and performance. A simple summary would be something like:

• Gaia:
  • For quickly creating a textured base terrain, made up of multiple terrains.
  • Update the terrains splats whenever i do manual sculpting/stamping.
  • Export terrains splats as textures for use in shaders (modulate grass size and color based on where they are painted for example)
  • Generating low resolution "impostor" mesh terrains for far away terrains (The switching from terrain to "impostor" is done with my own system).
• GeNa:
  • For placing objects around based on rules, spline roads/rivers that deform the terrain, followed by a lot of manual placing of objects for fine tuning.
• MicroSplat:
  • For better performance, visual quality and features for the terrain shader, with a lot of manual painting for fine tuning. (their decal system is maybe my favourite feature for adding a lot of detail on the cheap)
• AmplifyImpostors:
  • For generating impostors for most objects but especially trees and grass clumps for when they are very far away.
• Nature Renderer:
  • For rendering the terrains trees, grass and clutter (pebbles, sticks and fallen leaves etc...) with much better performance.
• GPU Instancer:
  • For handling repetitive objects that are not a very good fit for Nature Renderer, such as boulders, rocks, logs and the like.
  • For things like modular buildings where the same objects are repeated multiple times.
  • For repetitive objects (vegetation for example) painted on regular meshes.

Since the terrain component is not compatible with ECS and a replacement is likely very far away in the future I am looking for a terrain solution that is but at the same time can integrate with these assets.

So I guess my questions are:

• How does the authoring of the terrain work? Is it similar to the usual terrain component with textured brushes/stamps?
• Could I use Gaia in a similar way that I use with the usual terrain component to create a starting point to work from?
• I saw that it supports MicroSplat Mesh Workflow module. Does it support all of its features? How about the other modules? I own every single module so it would be nice to be able to use as many as possible for the best quality terrains.
  
• For a big world, should we use multiple smaller terrains to look like one big terrain or is that not necessary?
  • In the case that we should use multiple smaller terrains:
    • For far away terrains should we use low resolution "impostor" terrains or would that be unnecessary with this system? If it would be a reasonable thing to do, how could I generate them?
• How does your system handle vegetation? I currently use Nature Renderer to render the vegetation because it does it with much better performance than Unity and it has a lot of features to add visual fidelity such as rendering mesh grass with shadow casting, but it only works on unity terrains. Can your system match it in performance/features?
• Can the vegetation have LODs? Are they set up in a similar way to how we do it in regular terrains?
• How about bigger terrain details such as rocks, boulders, logs and the like? Currently I use GPU Instancer to render them as fast as possible.
• Can I use impostors such as the ones generated from AmplifyImpostors on the LODs?

 

Hi, thanks for reaching out. Regarding your questions, I'm not sure if Orbis is a good fit for your project. As it is entirely DOTS-based, it is pretty much incompatible to any other assets that aren't DOTS based (except for shaders/materials, but even that compatibility is not always given). To directly answer your questions:
- The authoring of the terrain doesn't use brushes/stamps. There are different generation modes available: Either you use a pre-defined heightmap (which is created using other tools, such as the unity terrain or outside of unity in 3rd party applications), or you use the procedural workflow, where you use noise or any other code to define heights based on your algorithms.
- Orbis itself is not compatible with Gaia. You could potentially use Gaia to export a heightmap of the terrain and use that with Orbis, but all vegetation and other things that are Part of Gaia either need to be rendered outside of Orbis, or thei will be lost
- I haven't tested all the MicroSplat modules, so I can't give a clear answer here. However, any microsplat module that works with the mesh workflow should work with Orbis aswell. However, some modules might not logically make sense with specific Orbis configurations. E.g. when using a spherical planet in Orbis, the height-based features like the global snow or potentially the global texturing based on height will not work as intended, as I assume they just check te Y coordinates
- Orbis is ideal for large to very/super large terrains, so there's no need to split it into individual parts. You could split it up if you have the heightmap split into multiple parts.
- For vegetation Orbis uses the entities.graphics renderer, which already is highly optimized for large numbers of entities to draw. Vegetation is streamed in and out using rulesets on where to spawn them. Each vegetation/ foliage instance is it's own entity. That means you can use all features of a normal entity, such as colliders, LODs and more. However rendering high amounts of grass meshes might overload it, as ideally the grass would only reside on the gpu side
- For bigger terrain details you can either manually place them as entities, or if it works for you, you can use the procedural foliage placement / streaming of Orbis for them. They will be rendered using the entities.graphics renderer, which of course features gpu instancing.
- I'm not sure if Amplify Impostors are compatible with entities.graphics (also known as hybrid renderer), you'll need to reach out to them to confirm compatibility)

I hope that answers your questions, if you have any more feel free to ask

 

Hi everyone, I just submitted an update to the asset store, which should be online with a few days. It brings compatiblity with entities 1.0.10, unity version 2022.3.2f1 LTS. It also includes a few bugfixes and improvements to the conversion workflow ( using blobassetreferences for the heightmaps now, instead of storing them on the OrbisConfigurator Monobehaviour.
It is also currently included in the worldbuilding sale in the asset store, which means it's 50% off. If you're thinking about purchasing Orbis, now would be a good time to do so.

 

AWESOME! Thanks for the update! Very happy you are continuing this

Edit: Negative feedback got a bit long, good feedback is at the bottom.

I have some software quality & usability remarks:

- the imports in some of the files are a mess, e.g. you even inadvertently introduced a hard compile dependency on Unity.VisualScripting, which every sane person has removed in package manager. Just clean up the many, many unused imports and it's good to go.


- big oof, our inspector is already very crowded and small, please don't put this giant image there. Did you know you can set an Icon for the monobehaviour using [Icon] Attribute?


- This editor... it's not very good. And the values in it are also not very good.
It could just be a curve editor or even a single formula (e.g. maximum range, exponent). Manually choosing these values also means that there's an unnecessary bias, calculating form the formula gets rid of this. If we learned anything from the Pandemic, it's that humans are very bad at exponential curves.

- It's also atypical to have the High LODs be the ones that are the closest and most detailed, usually LOD0 is max in video game asset workflows, and is in Unity, too. (well you can go negative with a bias, but usually higher LOD means further away, fewer polygons)

- overall, the demo terrain pops a lot, this can be improved by more generous LODs.


- sadly the entities (trees) get culled very long before they disappear behind the horizon. I'd recommend a spherical culler, i.e. if the angle between ideal surface tangent is high enough to guarantee that the object is behind the horizon, then cull. Future solution could also use Entnties Graphics's Occlusion Culling, but I don't trust that feature yet.


- that's a very unfortunate way to blend normals! You are losing a lot of quality and accuracy here (and actually correctness!) Use 2 Normal Strength + 1 Normal Blend nodes (link also has the formula). Easy fix for me as a user, but your product demo will look a lot better if you blend the normals better.

- https://blog.selfshadow.com/sandbox/normals.html here's a webgl demo, you are doing the linear blending, which is the least appropriate - this is why your terrain normal maps look so flat in the transition zones. Reoriented normal blending is usually the way.

- not happy with the basic origin repositioning thing, I hope I can find a way to deactivate this - clashes super hard with my own floating origin system (which doesn't need repositioning, but uses camera centric rendering / repositioning in LocalToWorldSystem)

- the demo moons are very unrealistically coarse (and small, but that's ok). If you looked at the earth or the real moon, shrunk them down and put them on a pool table, they'd be smoother than the Cue Ball. There doesn't seem to be a terrain scale factor in the OrbisConfigurator..

Some good stuff though, cause I think Orbis is great:

- based on cube spheres? Perfect, I have my entire texturing workflow in cubespheres and cube maps.

- the steep cliffs on the green world are nice, I can see how I can make nice worlds with it. When I saw that, I exclaimed "hell yes!".

- performance is quite decent even at double detail density.

- good job at dithering the popping, it could only be more adjustable (I just doubled all LOD distances and the quality issues are significantly diminished - I think your settings were way too conservative)

- actually pretty nice choice of skybox, hot damn!

- THANK you for using ShaderGraph, and the graph for the terrain material is even very tidy. I can adapt this quite quickly.


More on Tangents, big and difficult topic
By the way, since you had the normal blending error - are the mesh tangents you generate in MikktSpace? Otherwise it would be good to document what the exact tangent space is so we can adjust our normal maps, and also pick the right blend technique. (and if it's inconsistent between patches, you should make it consistent, because we can't rotate/reorient our normal maps at runtime )

- I find that finding correct tangents is extremely difficult for cube sphere style terrain. You can't use planar tangents, There's always a seam on the sphere where the tangents point the wrong way and you just can't blend the normal textures there, nor can you filter from the other side of the texture to wrap. You should really ensure MikktSpace, is my guess.

- most normal maps and material creation software either assume MikktSpace, or the mesh's specific space they were baked from (not for!). That means your procedural terrain needs to support something else than planar tangent space because there are always 3 edges on your cube sphere where the tangents won't fit. (it's a cursed puzzle, I failed to fix it in my own solution)

- you can use some sort of spherical space for the tangents, but these might fall apart when the camera is close to the ground and the actual generated geometry is very different from "a generally round planet"

 

Sadly, I got one more... you just can't do 8 triplanar nodes in 1 shader in production code.

That's 24 texture fetches. It only holds up because the textures you use are very low res. I reckon there's a lot of hardware out there that can't even do 24 sampler fetches in 1 Shader just for albedo+normal.

EDIT: I just checked, it's pretty dire. A safe value is somewhere around 8 fetches, 16 is really pushing it. (Unity links Textures with samplers, so the sampler count is your limit.

Unity documentation: "For example Direct3D 11 allows using up to 128 textures in a single shader, but only up to 16 samplers." And you aren't even looking up roughness, detail, detail normals, metalness, emission, occlusion and detail occlusion maps yet. (Yet you use a lit PBR shader)


In short: You should generate texture coordinates with the mesh. UVs, Detail UVs, Normals and Tangents.

If you absolutely need more triplanars, at least use a technique that cuts down on the lookups.
1. Just plain Biplanar (because the terrain can't be seen from the bottom, anyway, so 2 planes are usually enough)
2. iq's Biplanar, which is triplanar, but with 2 lookups (this one is indistinguishable and 33% faster)


Generally, normal mapping is even harder for Triplanar shaders (our beloved enemy, the Tangent space). Here's a good detailed explanation and also some nice terrain examples where you can see how you could even further improve your cliffs. Unity's triplanar node does a half-decent job, but it's a very, very expensive node. And it doesn't work for generated meshes, only for meshes that have calculated or imported Mikktspace Tangents! (that is, unless your generated mesh has Mikktspace Tangents + some magic)
https://bgolus.medium.com/normal-mapping-for-a-triplanar-shader-10bf39dca05a


It especially shows how the individual tangent space errors will look, with the example of a "golf ball"-like cubesphere, and how it SHOULD look.

 

To make things clear: Once the Unity DOTS terrain has arrived, will you also work on a flat Orbis DOTS version (maybe based upon the Unity terrain) or will you only focus on spherical Orbis DOTS planets from that point on?

 

Does this have a navmesh?

 

I currently have one problem where spherical terrains get stuck in low LOD state and stop updating for some reason.

My guesses are job scheduling issues when player moves too fast. Although it's always one of 6 spherical terrains that get stuck. It's either a Baking or Scheduling issue. Sometimes after I change around settings it stops getting stuck.

If anyone figures out how to ensure stable terrains this would be a game changer. Anyways thanks for amazing work. Looking forward for any updates.