[RELEASED] Ruaumoko: iso-surface, voxel mesh generation and terrain engine

New demo of my toying with an Octree-based LOD scheme.

Use WASD + arrows and QE to steer the "space ship". The texture stretches badly and you'll see holes, but you'll also see a decent sized moon!

@Zynx: look in the "DoSculpt" function and play around with the minX, minY... lines. The first value in the Mathf.Max() and Mathf.Min() control which voxels in the block can be sculpted. By default they're 0 [array dimensions], but setting them to 1 and [dim]-1 or such might be just what you're looking for!

 

Huzzah, top notch Dr. B! I'd been poking around neighbor and d values without much luck. Have a better understanding of density at least.
As far as I can tell, this method seems to solve my problem entirely.
I'll do more testing tomorrow, I'm very grateful for your help.

 

So, earlier I asked:

Dr B replied:

And here's my code, fully functional and tested as of 2013-12-3, but a naive brute force approach. Hope it helps you:

Code (csharp):

1. using UnityEngine;
2. using System.Collections;
3.  
4. // This script is free for your use, written by Logan Park, Ph.D., and dedicated to his amazing wife.
5.  
6. public class HSSpawnExcavator : MonoBehaviour {
7.  
8.     public GameObject VoxelTerrainParent;  // Drag the RuaumokoTerrain script's parent gameObject onto this field in the editor.
9.     private RuaumokoTerrain VoxelTerrainEngineScript;
10.     public float DelayThisLongBeforeCreatingVoid = 3.0f; // Allow dynamic voxel cells to spawn before screwing with them.
11.     public float VoidRadius = 6.0f;
12.     public float VoidSurfaceSmoothness = 1f;
13.     public bool IAmDebugLogging = true;
14.     private bool IHaveNotFoundTheCorrectVoxelCell = true;
15.     private bool ImReadyToSearchForTheSpawnVoxel = false;
16.  
17.     // Use this for initialization
18.     void Start () {
19.         VoxelTerrainEngineScript = VoxelTerrainParent.GetComponent<RuaumokoTerrain>(); // Get reference to the Ruaumoko brain
20.         Invoke( "SculptVoidAroundSpawn", DelayThisLongBeforeCreatingVoid ); // Setup a function to carve out a void around this script's transform
21.     }
22.  
23.     void SculptVoidAroundSpawn () {
24.         ImReadyToSearchForTheSpawnVoxel = true;
25.     }
26.    
27.     void Update () {
28.         if ( ImReadyToSearchForTheSpawnVoxel ) {
29.             Vector3 spawnLocation = transform.position;
30.             spawnLocation.x = Mathf.Round( spawnLocation.x / VoxelTerrainEngineScript.cellSize );
31.             spawnLocation.y = Mathf.Round( spawnLocation.y / VoxelTerrainEngineScript.cellSize );
32.             spawnLocation.z = Mathf.Round( spawnLocation.z / VoxelTerrainEngineScript.cellSize );
33.  
34.             string voxelCellContainingMyTransform = spawnLocation.ToString( "f1" );
35.  
36.             if ( IAmDebugLogging ) {
37.                 Debug.Log("Spawn Excavator: targeting voxel cell named " + voxelCellContainingMyTransform );
38.             }
39.  
40.             foreach( Transform voxelCellChild in VoxelTerrainParent.transform ) {
41.                 if ( voxelCellChild.name == voxelCellContainingMyTransform ) {
42.                     IHaveNotFoundTheCorrectVoxelCell = false; // Yatta! http://www.youtube.com/watch?v=j0WGly9xRgA :)
43.  
44.                     if (voxelCellChild.collider.CompareTag( "Sculptable" ) ) {
45.                         SculptParameters sp;
46.                         sp.point = transform.position;
47.                         sp.power = 10f;
48.                         sp.radius = VoidRadius;
49.                         sp.shape = SculptBrushShapes.Sphere;
50.                         sp.smoothness = VoidSurfaceSmoothness;
51.                         sp.texturePaint = Color.gray;
52.                         sp.mode = SculptMode.Sculpt;
53.                         voxelCellChild.collider.SendMessage("Sculpt", sp, SendMessageOptions.DontRequireReceiver);
54.  
55.                        
56.                         if ( IAmDebugLogging ) {
57.                             Debug.Log("Spawn Excavator: Thus, accomplishing my sole goal, I am cast aside; discarded like so much digital detritus to the bit-heap where only the NSA cares to snoop through the trash." );
58.                         }
59.  
60.                         Destroy( this ); // Tidy up and remove this script
61.  
62.                     } else {
63.                         if ( IAmDebugLogging ) {
64.                             Debug.Log("Spawn Excavator: Seriously? You have me scanning stuff (like " + voxelCellChild.name + ") that *isn't even tagged as sculptable?*  Why do I even try? Go play hide-and-go-screw-yourself." );
65.                         }
66.                     } // End Sculptable tag check
67.                 } else {
68.                     if ( IAmDebugLogging ) {
69.                         Debug.Log("Spawn Excavator: I wasn't able to match this voxel cell (" + voxelCellChild.name + ") to the name provided (" + voxelCellContainingMyTransform + ").  Either it hasn't spawned yet OR you're an idiot and gave me the wrong name.  We're all clear on which possibility I favor." );
70.                     }
71.                 } // End name match
72.             } // End foreach
73.         } // End ready check
74.     } // End Update
75. }
76.  

Usage: drop this into an object that should not be enclosed in terrain. It waits awhile for chunks to spawn, then carves out a void around itself.


Let me encourage my fellow Ruaumoko users to post useful snippets-- we all gain a lot when we each help a little. <3

 

Hmm. I appear to be encountering a few bugs with Ruaumoko lately:

The first bug is a familiar one: seams between voxel cells between LOD levels and within each LOD level. Very similar in appearance to the seam stitching gaps posted in this thread earlier in the spring. Harmless enough, but distracting. I'm aware that between-LOD seams are already under active development, so that's cool.

The second bug is harder to ignore: after running in the editor for approximately 90 - 120 seconds, my Ruaumoko-based project freezes Unity completely. It all works fine if I set the Dynamic Terrain (RuaumokoTerrain.cs) gameObject inactive. I'm running Unity Indie, so detailed crash info isn't automagically compiled--how can I provide useful troubleshooting info? If I had to hazard a guess, it *might* be related to how Ruaumoko seems to keep generating chunks at increasing distance from the player's avatar regardless of what value I set for LookAhead (default 4). But that is a wild stab in the dark absent any real information.

EDIT: Example webplayer (90 mb!). WASD keys + space/shift to move, mouse to look. Or use a PS3 controller. Right mouse is the sculpt tool if you need to use it to get around.

 

Hi again just wondering where I should start if I wanted to make the planets have a more terrain like surface ( Like your recent demo of an octree LOD) I would really like to have planets and asteroids like that.

 

@LP: seams between LODs is acceptable for now, but not within an LOD! That's bad. I've seen it too and think it is a result of the asynchronous mesh updates now. I'm working to fix it!

The crashing is troubling. LookAhead will grow if it can't find any cells, you can disable this in RuaumokoTerrain.cs in CheckBlocksNearPlayer() (line 480 in my working copy). You have a very big scene build in the editor, which causes the project to freeze? It might be a memory issue since the blocks retain all their voxel data and don't unload it–functionality that needs to be updated, clearly.

@Terry57: by more terrain like surfaces you mean the shape of the surface, or the texture? For the shape try this: create a new scene, create Ruaumoko Terrain (from one of the menus), and set the terrain shape to "Planet" (default is "Flat"). Apologies for this not being intuitive (it will be updated): the size of the planet is controlled by the "Lowest Frequency" number (1 / Lowest Frequency = radius in world units). Play with the Octaves of Noise and Noise Strengths to get different hills/valleys/caves/etc. See this document for more details on that. Let me know if this helps... or what functionality you would like to see. How would you like to use it? What buttons/numbers would be helpful?

 

I'm not too troubled by it, @bens1984; as you've said, its already on the roadmap and you've been hammering away faithfully for awhile now.

Well, crap. Now that you mention it, I'd disabled the LookAhead grow in the previous version of Ruaumoko and wiped that modification by installing the latest. Aaaand back came the crash. Completely forgot about that. I really should be using version control software...but for a just-for-fun project it feels like overkill.

I'll look into exposing that LookAhead disable/enable toggle in the editor portion of the script and as a very simple API-type call in the code. If it ends up reasonably poetic, I'll contribute the code to Ruaumoko users.

 

Hi, I think I'm getting the hang of working with Ruaumoko. Anyone know any tips whether through the noise parameters or whatever to reduce or eliminate floating islands (blobs of unconnected terrain floating above the rest of the world)?

 

Thanks again for a quick reply got great results for planet surfaces and the new LOD is awesome!

I am trying to have a few planets that get generated with a random seed I have this all set up now but I would like to have the planets generated at run time but not based around the player position as the player will go to the planets from space and the generated Cells seem to get removed at a distance and the planet would disappear.
The old Big Planet demo that works quite well, but I would need noise to have a more terrain look on the planet.

I don't really know what to do now on this unless you have a better idea on how to get the result I'm trying to get or a better approach I have been going for quite big planet sizes this is probably part of the problem but I don't want to start making a planet too small as it will start feeling more like your walking on a sphere.

I'm using 0.004 to 0.006 for Lowest frequency this makes a good nice size for a planet to walk on I might want to go bigger later.


I did try changing code in RuaumokoTerrain.cs and attempted to add another player position so it would generate around 2 positions or more so it would generate the whole planet after a bit of time but I couldn't quite get it working, it would start to generate at both positions but the generateloop would only work on the normal player position this would have worked well if I figured out how to add more generate positions properly.

Alternatively I then chose to make planets in the editor but what would be really nice is if I could save the cells that are generated at runtime around the player so i can then edit them in the editor as clicking to get cells generated for a large planet would take extremely long time.

Also the smooth tool also does not work with planets it opens up holes and makes seams between each cell its not much of an issue at the moment though.

I also wondering about saving and loading planets and terrain for example save the game and come back to it later with all the changes done to the surface saved I saw that saving has been added but I don't know how to trigger it so a game world is saved for the player to come back to.

Also about the liquid demo you did a while ago how would I go about using Ruaumoko to do that?

Thanks again.

 

Hello Dr.B,
I have taken great interest in this asset since I learned of it's existence, and this does seem to be THE asset for what I want to do. However, before I make the leap to purchase this I would like to ask about what I specifically want to pull off, and the feasability of this.

I've tried your planets demo, and the infinite paging terrain...ultimately my goal is to have both. I wish to have a finite terrain generated in the same shape as the planets demo, given a specified thickness for the world. I would like to be able to apply a planetary gravity system, so the entire terrain would have to be generated initially and then at the center point, the gravity "core" of sorts would be placed so that the outside surface of the planet is always below you. Paging obviously would allow a world that is too large to be loaded, to be loaded/saved only when the player is near. I am curious if you could suggest how this would be pulled off, I assume I would have to write some sort of generation code to go along with what you provide? To reiterate, I don't want the solution, just some direction.

 

@dagarath: glad you've found Ruaumoko. What you want to do is certainly feasible, and is somewhat built in already. The terrain generation part of Ruaumoko has 3 primary modes: flat, caves, planet. Most of the demos are of the flat mode, but by changing the math under the hood a bit the other two modes make a very fundamental change to the world. Planet builds the type of terrain you want! I have a parameter exposed in the Inspector pane to specify the radius of the planet (added in the upcoming update).

You'll have to handle all the gravity and camera angle changes, of course. And you will want to play with the generation code in terms of which cells to prioritize for loading. At the moment it's fairly naive and will leave gaps until the player's about to step on them.

The next update should be out in days, I'm just stamping out the last (hopefully) bugs that I'm likely to find!

 

also, dagarath, check out this demo I've put together to test a new direction I'm working in that should be very interesting to you:

https://dl.dropboxusercontent.com/u/26291791/PlanetTest/PlanetTest.html

It's using an octree algorithm to subdivide the world and load meshes using an LOD scheme. This won't be in the Ruaumoko release until I get it generally stable and fix problems, but thought you might dig it.

@Terry57, I see I missed your post due to the holidays. Assuming your issues are still current I'll take a stab at answers soon.

 

Sold, I don't get $$ for another 8 days but this is exactly what I have ALWAYS wanted to do with my dream game. I can finally be proud of my terrain because it will do everything I want. I have a renewed vigor and motivation to push this project forward =)

 

No problem, I updated the post to whats relevant now anyway so its a good thing that you missed the post before.

 

Any chance for GPU accelerated surface extraction?

Any news on reading and marching raw 3d arrays and such?

 

Hi DR B!
I just bought Ruaumoko and Ruaumoko DC edition from the asset store and I am getting this error after importing the assets:


Any ideas on how to solve this issue?

 

Whoops sorry image was too small

Debug Log:

Assets/Dr B Games/Ruaumoko/Core/Demo/BasicShape.cs(43,41): error CS0117: `MarchingCubes' does not contain a definition for `Singleton'
Assets/Dr B Games/Ruaumoko/Core/Demo/BasicShape.cs(58,25): error CS1061: Type `MarchingCubes' does not contain a definition for `GutterSize' and no extension method `GutterSize' of type `MarchingCubes' could be found (are you missing a using directive or an assembly reference?)
Assets/Dr B Games/Ruaumoko/Core/Demo/BasicShape.cs(59,25): error CS1061: Type `MarchingCubes' does not contain a definition for `SetDensityMap' and no extension method `SetDensityMap' of type `MarchingCubes' could be found (are you missing a using directive or an assembly reference?)
Assets/Dr B Games/Ruaumoko/Core/Demo/BasicShape.cs(60,25): error CS1061: Type `MarchingCubes' does not contain a definition for `March' and no extension method `March' of type `MarchingCubes' could be found (are you missing a using directive or an assembly reference?)
Assets/Dr B Games/Ruaumoko/Core/Demo/BasicShape.cs(62,25): error CS1061: Type `MarchingCubes' does not contain a definition for `GenerateAmbientOcculsion' and no extension method `GenerateAmbientOcculsion' of type `MarchingCubes' could be found (are you missing a using directive or an assembly reference?)
Assets/Dr B Games/Ruaumoko/Core/Demo/BasicShape.cs(63,25): error CS1061: Type `MarchingCubes' does not contain a definition for `CenterAndScaleVerts' and no extension method `CenterAndScaleVerts' of type `MarchingCubes' could be found (are you missing a using directive or an assembly reference?)
Assets/Dr B Games/Ruaumoko/Core/Demo/BasicShape.cs(66,25): error CS1061: Type `MarchingCubes' does not contain a definition for `UpdateMesh' and no extension method `UpdateMesh' of type `MarchingCubes' could be found (are you missing a using directive or an assembly reference?)

 

Is it possible to generate a full landscape + liquid water (incl. Trees + grass...) with this engine?
Sorry for this question, but im searching a good voxel engine + liquid water to realize my project plans, and i want to know if this things are possible with this engine, bevor i buy it.

 

Hey there folks, does anyone know what the prime differences are between the regular and the D.C. edition? Do I need them both, is one better than the other? Looking for opinions, my team is trying to make a randomly generated 3D terrain that isn't blocky or sharp.

 

@GentleForge: At the moment it includes a grass engine, written for this package but it's actually capable of running on any mesh based terrain. Other biome elements (trees, debris, etc.) would need to be custom coded in. Liquid is not included at this time.

@TheXWolk: The DC edition is intended as a cheaper option that just includes the Marching Cubes and Dual Contouring implementations, ready for the coder that has their own applications in mind. The regular version has all of the terrain generation, paging, world sculpting, editor tools included.

NEW! As of the next release (this week) Dual Contouring will be included in the main release as well.

 

Hey the issue I was having above is solved now, It works perfectly.

 

So for those of us who want the complete toolset the regular one is better, since it also has/will have the MC/DC contained in it?
Just wanted to make sure, I don't mind purchasing both, just wanted to double check. Is the M.C. system in the regular already,
or should I purchase the DC in conjunction?

Edit: Also Doc, did you manage to see my PM?

 

The new version (1.1) is in the hands of the Asset Store clerks, on its way to you!

I would urge caution in upgrading large projects: please make a backup! In order to provide better performance through multi-threading and functionality and stability in the editor I had to make some significant changes behind the scenes. Several components that were static at run-time are now attached to game objects in the scene, which may cause parameters to be reset to defaults when you upgrade. It may require manual re-entry of terrain parameters, or reconstruction of the Ruaumoko components in your scene (although I hope not!).

Dual Contouring is now included in the full version! This relieves the need to purchase both packages, making the DC edition a subset (at a lower price point) of the other.

I ran it through as many tests as I could, but please notify me of any bugs you find! As a team of one I can't spend enough time hunting for problems so assume I don't know whatever you find is an issue and I'll thank you for a PM with details!

 

Awesome! I'm thinking about purchasing, however i am curious to know how well the planet LOD's are working and if it is possible to create even larger scale planets now. Is there anyway you could submit an updated planetary demo?

 

bens?

 

@TippyK: Check this. This is coming down the pipeline, but is not in the asset yet. You can see holes between the LOD meshes, of course, and it needs some optimization. It's an octree based system so it can handle HUGE planets (or landscapes) and will always show something at a distance, rather than leaving empty space.

@Curious: GPU surface extraction is not in the plans–it would make collisions difficult, which is necessary for this asset. However, reading and marching raw 3D arrays is going to be here SOON. I recently connected with a group of researchers that need to visualize 3D data sets, bumping this feature to the top of that stack! It needs to be functional by the end of March and I'll be sure to get it to you by then too.

 

Ruaumoko A* Pathfinding ??

I'm running the full version of both Ruaumoko Unity Pro.

Is Ai Pathfinding possible with Ruaumoko ?

sorry if this sounds at all vague.. I haven't tackled Ruaumoko lately as I've been busy with pathfinding setups.

 

So how does this compare to TerraVol, currently the top asset in the category? Also how mobile friendly is it and can I simply use it as a editor and convert the whole thing into a static mesh after?

 

Is it possible to generate the surface of a planet quickly at low LOD and as you approach the surface, generate the level of detail seen in the world sculpting demos?

 

I have both Terravol Ruaumoko. I have not used them for a few months as I'm waiting for pathfinding to be integrated. Terravol now incorporates pathfinding but TerraVol is not as detailed as Ruaumoko. In TerraVol you tend to cut huge amounts of the terrain whereas with Ruaumoko you are able to cut much smaller. There's a probably a tonne of differences... this is only from what I gather from a very basic understanding of the two. I like how I can sculpt now in edit mode with Ruaumoko although I am having problems creating a relatively smooth terrain as I had before.. all my terrain is somewhat blocky often painting terrain in edit mode places pieces of terrain in areas such as floating high above where I isn the terrain to be. Would be cool to be able to stipulate an object to paint on... then delete the object later... this way I could create a terrain in Maya paint over it then have the exact shape I'm after.

 

@Banksy: A* pathfinding is certainly possible (the algorithm is very flexible, in principle), but would need to be custom implemented to work on the 3D nature of the terrain. The typical implementations arbitrarily divide the world by some grid, then move a capsule around on the grid checking to see if an AI can stand there and where it could move to to build the navigation data. Of course this isn't in Ruaumoko yet!

The idea of creating a terrain in Maya and getting the exact shape you're after is very interesting. Would you just want that mesh (from Maya) transformed into a Ruaumoko object so you can deform it? This is a capability that I've been contemplating for a while, and it might be time to work on it–if it's of interest to you.

@ncho: others will have to answer the comparison to TerraVol. I've been in touch with Amfu (dev for TV) at different points but haven't kept up with where he is. Ruaumoko runs on mobile, but the generation scripts are very slow on mobile processors. I would be curious to hear if anyone has found settings that work acceptably–I imagine scaled up game objects (spreading out the voxels) and using smaller voxel chunk (block) sizes might work.

@jason.fisher: This isn't built in at the moment. What you really want is an octree type solution, as I've started implementing in Ruaumoko in this demo. You can see the seams, but I believe the LOD generation is stable and efficient.

 

Thanks for the reply. That is definitely what I am interested in. It looks like it also solves the problem of needing to pre-generate a ton of detailed voxel blocks at run-time init for long distance RTS-style views.

Have you considered implementing the TransVoxel algorithm? It is basically marching cubes with a more complex lookup table that solves seams between LOD changes. The table was "opened" by the author (the same as the C4 engine).

I believe this is a fork of an original repository, but it is pretty self contained:
https://github.com/oggs91/TransvoxelCS/tree/master/VoxelStuff/src

You can also find it in C# in a Transvoxel-XNA repository here, where the core class should not require XNA: https://github.com/BinaryConstruct/...ansvoxel/SurfaceExtractor/SurfaceExtractor.cs

 

Oh wow what a cool looking asset

 

I was able to get a ~3x performance increase on density pre-generation (basically looping through x/y/z for an area and invoking Generate/Go forcefully) and clean up the cellsToGen queue by modifying InsertIntoCellsToGen to check/filter the density prior to queuing. I added a "force" argument that the AddNeighbors hasMesh passes through to force generation of air blocks surrounding blocks with density.

I avoid checking the entire density for a block and instead only select one point. Because of this, I generate when I see a 'dense air' result (-10f here). I rely on the AddNeighbors hasMesh call to InsertInCellsToGen with force enabled to fill in the gaps after my initial run-through. This allows me to relatively quickly pre-generate a 16x8x16 area during world generation/load prior to the real-time dynamic generation kicking in. Without this pre-check the pre-generation process would take ~2 minutes, and after it takes ~33 seconds.

The basic check looks like this, where new Vector3 (x, y, z) are your RuaumokoTerrain VoxelBlock coordinates. This is checking the 0,0,0 local position density of that VoxelBlock. Checking one or two more positions would be more accurate, but the neighbors have forced the queue on the misses.

Within a RuaumokoTerrain class:

if (!force density.CalculateDensityForVoxel((Vector3.Scale (new Vector3 (x, y, z), transform.lossyScale) * cellSize) + new Vector3 (-0.4f, -0.4f, -0.4f)) < -10f) {
return;
}

 

It seems the latest release is missing the Dual Contour classes. Could you upload an update?

 

Well, that would not be good! I will check it out and make sure a _complete_ asset package is uploaded. Sorry about that!

 

Any chance you could include the volatile liquids demo in the asset also? Fantastic package -- a wonderful resource for anyone wanting to learn more about marching cubes, scalar densities and paging terrains. Thanks again!

 

Hey, Awesome plugin

I was curious if Ruaumoko is capable of creating a large spherical object like a planet? If it can, how large could it be? Also wondering if it can it be used with other plugins like TerrainComposer and Relief Terrain Pack?

 

From what I know of the current release:

You can set the dynamic terrain script to "Planet" and generate a spherical object terrain with noise. There are also separate demos that do not use the core dynamic terrain script, but instead use parts of the API to pre-generate the entire sphere -- these can take a minute or longer for a 256x256x256 planet, where each unit is a density that contains a number of voxels. (8x8x8 maybe in that demo?). The advantage of the dynamic terrain script is that you only need to pre-generate the area around the camera/player, and the terrain will 'page' around that position as it travels. You could write/extend your own pre-generation logic into the dynamic terrain to pre-generate a very low LOD of a planet--the further the camera goes from the surface, the more work you will need to do on optimizing LODs. With optimization and some pooling/pre-generation work, 512^3 or 1024^3 chunk planets could be workable. You will need to find spherical gravity elsewhere.

This wouldn't be compatible with TerrainComposer -- this uses a noise generator to fill 3D arrays with density values that dynamically generate meshes using Marching Cubes, with the main benefit being that the density (and thus the terrain/object) is interactively modifiable at run-time and support terrain features such as caves and overhangs. You can provide a height map (2D) file to use, but it wouldn't have caves or overhangs. TerrainComposer uses the built-in Unity terrain system, which is height map (and thus 2D) based, but Unity terrains are not modifiable dynamically. You might be able to generate a terrain in TerrainComposer and feed a resulting height map bitmap (2D) to turn it into a modifiable terrain. TerrainComposer would be more efficient for larger terrains if they do not need to be spherical, have overhangs/caves or topographical changes at run-time.

RTP's triplanar texturing should be compatible without much effort, but I haven't tried it yet here.

You may have to address LOD stitching issues in the current release if you have a far viewpoint. Marching squares could be implemented (separately) to create meshes that fill vertices between chunks, but I am sure this is something being worked on.

Side note:

A few of the demos include unreleased features that you may be interested in following. If you want a planet that allows you to fly up to it and see foliage and interact with high detail at a close-quarters level, the Planet Octree demo will show you 'ledges' on an small planet with very high detail, but because the grass and shaders do not take spherical forces into account, in the demo the grass is always on the standard plane axis, instead of growing outward from the planet.

The Octree data structure I believe is what allows for the great dynamic range between far and close LODs in the Planet Octree demo, but there are probably a few issues to work out before it can be released -- i.e. it should probably be based off of dual contouring and deeper Octree levels vs Octree levels affecting Marching Cube LODs, but the Octree allows for the planet to render in low detail very quickly as a complete sphere, and the LOD to increase as you approach. With the current release, you can achieve this but it requires greater pre-generation time and some custom scripting to achieve a similar affect.

 

Hi,

I'm using the Plane mesh in a scene.
I think it may be built into unity.
Works fine.

When i run a scene that uses Ruaumoko, it deletes that core plan mesh.
(it's based on the demo 4b world sculpting height map example.)

So, in a multi scene web experience, when i go back to the scene that uses that mesh, it's gone.

Any idea how to fix this?

thanks,

Shwa

 

@shwa: I know why you're having this problem and will look at fixing it directly. The problem is a result of Ruaumoko using the Plane prefab as a convenient way to create ready-to-go mesh objects. However, Unity pushes any mesh changes back to the prefab during runtime, effectively destroying the Plane as a plane. Creating objects from scratch for Ruaumoko to use, and leaving Plane alone, should solve this. Sorry about that.

 

Any Update on the Octree based LOD?

 

I've been dreading this point. The thread has come to a standstill on an asset store item that i think is absolutely freaking great looking. I've messed with the demos, read the contributions from very helpful lovers of the asset and think this is without a doubt absolutely what I want for what I intend to do - particularly interesting were the ideas of texture by density when sculpting, the lifesaver of a script for easy terrain feature placing and the creators aptitude and enthusiasm for the project. I've been poking about others but the in so many ways feel 'meh' to me, especially as i'll be using it in a project that can't really account for 'forgiving' natures as it's possibly largely non-gamers being introduced to something completely new and possibly open to scepticism

Bugger it i do go on

 

Have it now, the current grass placement should be enough to figure out other placement, the package i got from the asset store still lacks the dual contouring

 

Hello!

How easily can you make islands with this? Could each island have individual properties?

Could we spawn villages, NPCs, etc... with this?

Thanks!

 

It seems as though Bens1984 has moved on from the package [temporarily?]... Have any of you other Ruaumoko users been able to find / fix a bug where cells / chunks keep generating regardless of LookAhead distance? Even loading up the default examples has the generator making around 4500 cells and then crashing.

 

I'd hope temporarily - Unity support isnt even paying attention to requests for refunds even though the asset store package is not as advertised. This is a massive pity, i really like this asset and i really want to use it but at the moment it's kaput for proper use. Even if the features that were said to be in there, were in there, it would be fine but they arent.

I havent had any probems with too many cells being generated, they tend to generate as i move but perhaps a little slowly unless i set an extremely short fog distance to hide the popping, at least when i want the landscape building entirely procedurally - regardless of this it looks fantastic, i just cant use it in anything other than personal fun as it stands

Maybe push come to shove i'll try implement some missing stuff myself, or shell out for the DC flavour too, but thats a big chunk of time learning things i didnt want to learn particularly, or money i was expecting to need to spend

 

Hi,

Considering buying your system. Could you give an indication of the size of the files/data that are created. Particularly for maps that are created in the editor.

Also is there a video or manual that explains how grass can be defined and added in the editor.

Also how fast can chunks be loaded that are defined in the editor (so are not procedurally generated at runtime)

 

Hi,

I was wondering, is it possible to create biomes?
With biomes, I don't just mean changing the texture after a x/z-value. I mean really changing the cliffheights, etc..
@LoganPark I see that you script might come in handy for spawning gameobjects in the world. But If I understand correctly does the Ruaumoko - package not include this option? Say if I wanted to make a Town in a random location, is it possible with Ruamoko or will your script be needed?

Thank you Unity Community,

Eli

 

Are there any updates coming up with more mobile optimizations?