[Released] Orbis - DOTS Terrains

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
• Extensive documentation
• Example shaders and materials for flat and spherical terrain, and atmospheric effects
• Use any number of terrains in the same scene, and terrains can be any size

[Asset Store]
[Website / Documentation]

 

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.

Fun stuff! Can't wait to toy with it more.

Don

 

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

 

I've seen this in the editor where the frame rate was really high. I'd wager that if you cap your frame rate, this will go away.

Code (CSharp):

1.  void Awake () {
2.      #if UNITY_EDITOR
3.      QualitySettings.vSyncCount = 0;  // VSync must be disabled
4.      Application.targetFrameRate = 45;
5.      #endif
6. }

 

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

 

Hi, I found Orbis is so promising, ... just want to know the possibility ti work with WheelColliders?
I believe DOTS collider will not work with GameObject collider, but just wondering if there is a possibility to implement it in the future.

PS : Added Orbis to my Favorite asset.

 

Glad to hear you're enjoying Orbis. The MonoBehaviour WheelColliders currently will not collide with the terrain, as they are completely separate physics worlds. I am planning on injecting MonoBehaviour colliders for the terrain in a future update, so they would be compatible with existing non-DOTS physics systems. But this will still take a while, if i ever get it to work.
Meanwhile, there also is the option to use DOTS-physics based vehicles with Orbis. I've attaches a sample video of that below (using scripts from the unity physics samples):

 

Hello!

I love the asset! I'm running into some issues when trying to implement a system for moving the bodies around. I've been able to update the Spherical Center point, however, the meshes only update their positions when their LOD changes and not when the center point is changed.

Here is my current script:

Code (CSharp):

1.  
2. using Orbis.Components;
3. using Unity.Collections;
4. using Unity.Entities;
5. using Unity.Mathematics;
6. using Unity.Transforms;
7. using Orbis;
8.  
9.  
10. [UpdateBefore(typeof(QuadtreeLODSubdivisionSystem))]
11. public class UpdateMeshPositions : SystemBase
12. {
13.     GravityEngine ge;
14.     protected override void OnUpdate()
15.     {
16.         ge = GravityEngine.instance;
17.  
18.         if (ge != null && ge.GetEvolve())
19.         {
20.             NativeArray<int> ids = new NativeArray<int>(ge.bodyIds(), Allocator.TempJob);
21.             NativeArray<float3> positions = new NativeArray<float3>(ge.positions(), Allocator.TempJob);
22.  
23.             Dependency = Entities.WithBurst().WithAll<MeshQuadParentId>().WithAll<SphericalPlanetConfiguration>().ForEach(
24.             (Entity ent, ref SphericalPlanetConfiguration spc, ref Translation translation,in MeshQuadParentId id, in Offset offset) =>
25.             {
26.                 for (int i = 0; i < ids.Length; i++)
27.                 {
28.                     if(ids[i] == id.id)
29.                     {
30.                         spc.sphericalCenter = positions[i];
31.  
32.                         //translation.Value = positions[i] + offset.value;
33.  
34.                     }
35.                 }
36.             }).WithDisposeOnCompletion(ids).WithDisposeOnCompletion(positions).Schedule(Dependency);
37.         }
38.     }
39. }

My last attempt is commented out, I don't understand the math enough to determine the positions of each mesh in realtion to the CenterPoint I tried caching it into a component at their creation but couldn't find where some entities were created, and I'm too new to ecs to make a good search.

Could you point me in the direction of good practice for smooth motion of these meshes?

Thanks!

OB

 

Hi, i never really thought about moving Orbis terrains around in realtime, but it should be doable. Now that i think about it, the terrains are being moved using the floating origin system, so you could take a look at that system to see how it's done. You can find it in "Orbis Terrains/Scripts/ECS/FloatingOriginSystem.cs". Note that the FloatingOriginSystem does not update the spherical center for other reasons, but in your case you will also need to update the spherical center.

Basically, all you need to do to move the terrain is changing it's translation (note that both the translation and the spherical center are in world space, and no parenting is done on the ECS side). Also, you will need to move the spherical center by the same amount you moved the Translation.

So there's no need to cache the offsets of the spherical centers, just move the terrain around as you wish, then calculate the difference between the new and old position, and then move the spherical center by the same amount.

Hopefully this helps, if you have any more questions or need a code example, please tell me.

 

Thanks for replying.
Yea seems like still many years ahead to fully convert a car physic based game to a fully DoTS format....

But I am always open for any hybrid approach if available, even though performance will not be so optimized.

Thanks.

 

Hey David, sweet asset!
I'm having an issue where only the flat terrain is rendering i.e. spherical isn't rendering.
I'm on Unity 2020.3.13f1 with latest entities 0.17 and hybrid renderer v2.

I'm very suspicious that it is caused by Netcode and the non standard world configuration since the only way I can get the flat terrain to work is inside the subscene that is loaded into the client and server worlds. Doing it this way does put the entities into the client and server worlds but only the flat terrain seems to work.


Anyone else have this issue?

 

Hi Krooq, glad to hear you're enjoying Orbis. Personally i never encountered an issue as you are describing it. Does the termin log any errors?
Also, to further debug the issue, you can try to disable the "sphere culling" parameter (if you are on the latest version, 0.2.0) and see if that changes things. If this does not change/cause the issue, try temporarily disabling the "spherical configuration tag" to check if the same terrain renderers correctly when set to flat.
Both flat and spherical terrains should be rendered the same way, the only difference is in the mesh generation algorithm.
I never used Netcode before, so i'm not sure if that could be interfering, but it should not cause the flat terrain to work while the spherical one doesn't.
If the issue still persists and you need further help, please respond here or directly contact me at orbis.terrains@gmail.com.

 

Those DOTS-physics based vehicles look very cool, time to recreate Moon Patrol in 3D! Lol.

BTW, I upgraded Orbis to the latest Unity 2021.1.19 and everything works great, no errors in URP. If I use HDRP I get one shader failing, here's the error:
A Hybrid Renderer V2 batch is using a pass from the shader "Shader Graphs/AtmosphereShader", which is not SRP batcher compatible. Only SRP batcher compatible passes are supported with the Hybrid Renderer.

Where'd you get the DOTS-physics based vehicles code and setup? I'd love to play with that on your terrain system.

 

Hey FYI, a new Unity version 2021.1.20 just came out a few hours ago and I got it and your stuff worked flawlessly in URP with the LATEST PACKAGES listed in your docs in the install section.

This version also seems to have fixed the Atmosphere bugs. I converted 3 different test projects using Orbis so this isn't a fluke; they all worked consistently. You might want to change the text in your description since it is not limited to Unity 2020 now.

If you have any links or code that works with Orbis, like the DOTS vehicle physics, that'd be awesome to share. I'd really like a flight DOTS physics sample.

 

The HDRP warnings will be fixed in the next upload. Regarding the vehicle physics, you can find the official unity ecs samples on Github:
https://github.com/Unity-Technologi...sSamples/Assets/Demos/6. Use Cases/RaycastCar
They should directly work with Orbis terrains.
I'll give unity 2021.1.20 a try, and update the description if everything works.

 

Wow, just impressive.
@davidus2010 just to confirm that I can generate random planets at runtime? I'm getting so exited.

 

Hi, yes you can generate random planets at runtime. Just instantiate one of the prefab entities and you should be good to go. You can further randomize the planet by changing the "ProceduralHeightGeneratorSettings" component on the terrain entities.

 

Hi David, That'll be awesome! I'd like to land my spaceship on the planets. currently it just falls through
oh man, this thing is blazing fast! many thanks for giving us this asset.

 

Hey! My name is Snake Plissken and i am now one of your biggest fans! i would always have a entry question with major assets like this and i would say a first question; wile i have looked around a bit in editor, and sorry if this was asked already but would be: Is it possible to have a entire planet spin or rotate on a axis's at a slow rate or speed? thanks for any response. or some type of replication of the effect using one planetary body and one or two objects in space.

I would also like to take a moment to say thank you. i see alot of potential here and i would simply like to make a sorts of suggestion and pass by you to take notice of a asset called: SpaceCombatKit by VSXGames. i bring this up because i picture a asset like this that allows most any other character controller asset available to get in and out of a vehicle or the controller's set to other objects. i see such a FPS controller and said feature working fluidly with Orbis one day.
oh and also in general, thank you for all your hard work and labor. with a few additions this asset has consumed alot of my time spending it in game-editor window, and in a fun way, so hey thanks again.

 

Hi, thanks for your message, glad to hear you like the asset.

Regarding your question about moving/rotating planets: Yes, in theory it should be possible, but i have not tried it (yet). Using heightmap based planets, you should be able to use any rotation/world space position you want and the terrain will work. However, using noise-based procedurally generated planets will not work without minor modifications to the code (which you could try), as the height samples are based on the current world position. Also, there might be issues when using LOD transitions. You can take a look at my floating origin system, it also moves the terrains around at runtime.

Any DOTS-based asset should be directly compatible with orbis, but mono based FPS controller assets will not easily work with orbis. However, we are starting to get more DOTS-based assets in the asset store, an example for a character controller is: https://assetstore.unity.com/packages/tools/physics/rival-dots-character-controller-195567

 

@krooq I had the exact same problem you did when I was trying to use Netcode and URP. I found somewhere that URP doesn't like having multiple worlds when rendering. I think it doesn't know which world to render and just gives up.

Switching to build in renderer got it to work fine. But I am not sure if I was setting something up wrong or hadn't swtiched to Hybrid Renderer Version 2. There is a comment in the install instructions on how to switch to that new renderer.

Let me know if you figured it out, I really wanna use Orbis with some multiplayer stuff.

 

Been playing with this for the last 4-5 hours, and here is some feedback:

• The QuadtreeSchedulingSystem is not using the CollisionLOD from QuadtreeSettings for creating Collision meshes, it's using MaxLOD, so if the collision LOD is smaller than MaxLOD, it is never being created.
• The website documentation needs updating, it's not "OrbisInterface" in the asset, it's OrbisConfigurator
• Suggest adding documention on how to disable built in DOTS gravity (eg with a Physics Step component) so that the Gravity Center works properly with the prefabs
• The prefab atmosphere/skydome shaders don't seem work with HDRP out of the box. The shader graphs are looking for a Universal renderer.

 

Hi, thanks for the feedback. Most of the issues you mentioned will be fixed in the upcoming version, just the skydome shader will need to wait for another bugfix, as i'm still looking for solution that contains directional light input and works with all render pipelines.
The collision lod and documentation issues will be fixed in the upcoming version.

 

hello, I have a problem all is pink yet I follow the configuration word for word. unity 2020

thanks again, best regards.

 

Hi, thanks for reaching out. Can you give me a few more details about the issue?

What render pipeline are you using (or is it built-in renderer)?
Also, is the issue also present in the sample scene, and does it affect both the terrain and the atmosphere for the planet demos?

 

Hi David,
Thank you for getting back to me and sorry for not responding sooner.
Disabling "Sphere Culling" did nothing however removing the "Spherical Planet Configuration" component did give me a cube world! Getting closer to a sphere XD

Ok success! Not sure how, but its goin!

 

I also noticed quite a few places where there were not so much "seams" but little imperfections or artefacts in the mesh rendering. Maybe it's floating point accuracy issues or maybe something else.
NOTE: turning on the generate skirts removes the "seams" but not these snowy mesh artefacts.
It would probably be easy to solve with a smoothing shader of some kind and some other little tricks, it only stands out here cos the white of the sky shines through the dark green grass.

 

@davidus2010 is there a way to check that a terrain has finished generating and is rendered?
I tried OrbisConfiguration.initializationDone but it seems it is only the start of it.

This is important to know when colliders are ready so objects don't fall through the terrain.

 

Hi again, glad to hear you got the spherical terrain working. As for the other issues you mentioned:
As you noticed, generating skirts fixes the seams between the terrain chunks. I'm having some trouble actually noticing the artefacts in the picture, are those the small white/light blue pixels indicating that the terrain is see-through there or is it a snowy mesh artefact? Maybe you can try getting the camera closer to one of the positions where the artefacts occur, and try looking at it using wiremesh mode in the inspector? It's the first time i've seen those artefacts, as the meshes should be totatally "airtight", as they are basically just a displaced grid. If you could provide me some more information about the artefacts or how i can replace the issue, that'd be great so i can fix it.

In regards to checking whether the terrain has finished generating meshes and colliders: That's a bit complicated, as the terrain also gets updated during runtime when the character moves around and other parts of the terrain need to be higher detailed.
There are 2 ways you can approach this, with both requiring a bit of work on your side. It seems like this is an important feature, so i could create and include public methods for both approaches.
- The first option is to check if the terrain at a specific position has finished mesh and collider generation. For that, you need to figure out which terrain chunk entity is at the target positition, and check if it has a collider. This is the more complicated approach, but a similar operation is already implemented in the height modification system. If you choose this approach, you can get detailed information about the terrain just where you character is, independently of the remaining parts of the terrain and whether they are already done generating.
- Another more simplistic approach to ensure that the terrain around your character has been created at the begin of the game is to check if there are currently any mesh/collider generation jobs active in the "QuadtreeSchedulingSystem". If there are no jobs active and OrbisConfiguration.initializationDone is true, the terrain and the colliders should be done generating.

I can prepare a code snipped for you before i include those features in an upcoming version, please let me know if one of those approach sounds useful to you

 

Thanks for the very detailed response!

I will investigate further on the mesh rendering artefacts and let you know if I find anything.

On the other topic. I did try the 2nd approach with mixed success. It does work but as you point out, its quite a tricky problem as the terrain generates during runtime over several frames emptying the job queue several times, this means I sort of have to guess when it is actually "done". I think the first approach is the best. Before I spawn a character I can drop a CollisionInvoker tagged entity at the spawn point and wait until the collision mesh has been generated then spawn the character. I'll let you know how I go.

EDIT: I ended up going a slightly different route. Instead of checking whether the terrain is done directly I instead use the CollisionInvokerTag and a simple raycast to check that a collider has been generated. It works quite well. The code for the raycast can be found on the unity physics package manual page and all you need to do is make sure you have a collision invoker on the entity located near to where you want to test.
I still have some LOD fade in rendering that I'd like to avoid but it's not that bad tbh.

 

@davidus2010 I found fixes for 2 issues mentioned before.

1. VegetationSpawnerSystem throws exceptions in game using Netcode.
Reason was that VegetationSettingInput places converted vege prefabs into the default world however in a Netcode setup, the default world typically does nothing and it's the client and server worlds that handle the logic. Fix was to just add a World parameter to the convert function in VegetationSettingInput i.e. change signature to
VegetationSpawnerSystem.VegetationSpawnerSetting convert(World dstWorld, BlobAssetStore assetStore). Then we can just pass in the system World of the VegetationSpawnerSystem.

2. OrbisConfigurator OnDestroy job handle not complete before dispose.
The OrbisConfigurator is a singleton so is not really expected to be destroyed however I have some code that unloads active scenes on entering playmode to ensure that the play mode experience is as close to the build as possible. Anyway, as a result the singleton is destroyed before being recreated, this causes an issue in the OnDestroy since the job handle has not been completed before being disposed. The simple solution is to add handle.Complete(); to the first line of the OrbisConfigurator.OnDestroy() method.

These are obvious edge cases that would not show up in internal testing but should be pretty easy to reproduce. Hopefully they can make it to the next version

 

Hi, thanks for pointing out the issues and i'm glad to hear you were able to solve them. I never tested the asset in a game using netcode, and did not create it with multiplayer in mind. However, i'm glad to hear you actually got it working.
The mentioned fixed should be included in the next release, thanks for pointing them out.

 

For the white points, you could try rounding vertex positions to pow(2,x) where x is a negative number,
( so 0.25, 0.125, 0.0625, 0.03125 etc... )

 

@davidus2010 could you provide an example of Orbis working with MicroSplat?
I've was able to apply the MicroSplat material to the terrain and it shows the first texture element on the terrain but there is no layering or anything else.

I'm not really sure this can work out of the box since there is a lot of custom stuff goin on in the terrain shader you provide with Orbis.
Would be really nice to have a bridge between this and MicroSplat as a feature.

 

Hi, you need to add the 'BiomeSettings' component to the terrain, which has a parameter called "MicroSplatVertexEncoding" with some additional settings. You can read more about it here in the documentation: https://orbis-terrains.netlify.app/docs/configuration/components-in-detail/#biomesettings
On the microsplat side, you need to use the mesh workflow set to "Vertex Mode" to work together with orbis. Then just assign four textures (biome A/B, cliffs, peaks) and you should be good to go. Please note that the LOD dithering feature does currently not work with microsplat and could cause rendering artifacts if enabled.