Last week we did a release of our tools that make it really simple to create terrain biomes. You can see it in action here:
One key issue that you can see in this video, is that it tends to produce straight lines. There is still some "diamond" symmetry we need to address the core algorithm. The image below shows a really bad case, where the produced heightmap has parallel features forming an almost perfect square:
At the left, you can see the generated heightmap. The right panel shows a render of the same heightmap.
This did not take long to fix. Instead of running the generation algorithm on a grid made of squares, switching to irregular quadrilaterals is enough to break most of the parallel lines. The following image shows the results after the fix:
We could provide an option to turn this improvement off. That would be the most diplomatic approach. But then what about any other improvements we have planned for the future, do they all get their own setting? At this point, it seems we would be complicating the UI with many options that are meaningless to new users. These would be just switches to make algorithms behave in more primitive forms.
Whenever algorithms create content along with humans it really becomes a muddy, gray area for me. I still haven't figured this one out.
Have a single option that ask's the user if they want Human interaction or not. Based on the answer you can then funnel that into the UI presented to the user and define the complexity you want to present based on beginner/intermediate/expert.
ReplyDeleteThat does however beg the question of how far you are willing to go to take your code and allow that opportunity of manual intervention vs back end coding required.
I like both of the generated terrains and could see myself taking some of the bits in the square one and placing them in the more organic one, so the most sensible approach would be a checkbox 'Irregular Quadrilaterals Grid'.
ReplyDeleteThe most you can do is advertise the big features or fixes in the change logs really. I have Blender and Unity projects that break when opening them in later versions, but I am not going to blame them for improving their software.
There's a reason people choose a fixed version for a whole production cycle and only move to the newest iteration of the program after development is finished. Unless you are say Maya adding a whole new fluids renderer and only then it is better as a separate installation and only for the use of that really specific feature for VFX rather than modeling.
Oh right, the 'Irregular Quadrilaterals Grid' checkbox would be toggled by default.
ReplyDeleteWhen it comes to the settings, set it up in such a way that only the people who want backwards compatibility have to navigate more options, but people who start a new project, don't have to worry about that. Maybe =P.
ReplyDeleteThese are all good suggestions, thanks! In this particular case we will add a numeric value to the Terrain node UI named "warp" or something like that. It will default to zero, so older projects will look the same.
ReplyDeleteWould it be possible to create a proc gen tool? Rather than regenerating the entire world again, you can use the tool to select an area to regenerate with the current algorithms. Alternatively, you could have a tool to lock/unlock voxel data to procedural generation.
ReplyDeleteIt is an interesting idea, but how to manage a smooth transition from outside the area into the area? If the algorithms change, there is no practical way to interpolate from old to new.
DeleteAdditionally, you could introduce voxel layering. Similar to how image editing programs work. If you assigned voxel data to layers. That way, an artist could choose the build order of the voxel data, or quickly hide layers of data to make voxel selection easier. That way if their city ends up in the middle of an ocean or mountain, they can hide the proc layer and quickly/easily select/relocate their work manually.
DeleteA layer translation method would be a great solution.
DeleteThe data is already layered in the engine like that, although not exposed in Voxel Studio's UI.
Relocating a whole city can be quite involved. This is not a feature you would develop naively. People already had this problem in Landmark while relocating entire claims. A claim's size is a fraction of a city's, and just rendering a preview can be challenging. But it is quite doable once the system is designed for it. We'll think about this option.
Relocating a city would be involved, after moving it to the location you would need to correct the height translations of buildings and potentially rebuild/reshape roads/neighbourhoods. But having layers available would make all of that simpler. Not only would it assist in selecting/translating fabricated content. But it would also allow for the creation of a translation layer. A layer where the content creator can freely add/remove from the proc layer without impacting their previously created content.
DeleteInteresting.
ReplyDeleteThese two methods seem to be the same but with different values given to the "regularity". In a sense, it's a bit like changing the amount of blur in an image processor.
The numerical value is the best way to handle this situation as sugested previously. Anyone opening a project without such variable gets the legacy "square" value. This gives flexibility and might allow people to transition if they want to. This way, you're not only implementing a fix but an entire feature by letting people achieve different results by playing around with the values.
Not sure if it could allow for more twisted results but this is good.
On the subject of user made content, you can probably implement a "snap to terrain" based on axis/gravity feature based on the current selection and/or on a specific user modifications layer.
I don't know how the engine handles user content but surely there is also a difference between visible and invisible human made changes ?
Not sure what you mean by visible and invisible user changes. Some user edits are adding "air", which makes portions of the procedural layer invisible, if that is what you meant.
DeleteSnap to terrain would be very nice. In our case it is a bit more difficult since we do not use heightmap topologies only. So you could dealing with a Bat City, which actually hangs from a down-facing mountain cliff. In that case down is up, and figuring out where the city should move is far from trivial.
In addition to what others have mentioned, there are two general practices I like that are applicable; Making all those options that would be 99% of users don't use but are nice to have fore weird edge bases into text tags in an config file or an "additional tags" text box or something, and for versioning backwards compatibility specifically collapsing it into a single number for what version to use instead of a bunch of individual options.
ReplyDeleteI suggest adding a 'Local Procedural Override' tool. It would be an anchored alteration of procedural settings that is configurable and movable. If a procedural change breaks par of your map, then you would copy the procedural settings of the last matching state to a Local Procedural Override object. The override would probably have a radius, falloff settings, an probably some sort of blend function so you can make a more complicated transition mask. This would allow you to keep the terrain under a city static while the world around it conforms to updates. Additionally if it's object based then you could move the object around so you could effectively move geological features with it too. It wouldn't need to be just for localised backwards compatibility, you could use it for all kinds of things.
ReplyDeleteCould existing map formats be ported to new map formats that have additional 3 dimensions of voxels that are perhaps like 10x as big-invisible giant voxels that serve to trace boundaries of areas generated via algorithm, like biomes, and which are used to register marker information like who last changed the voxel and when it was last changed?
ReplyDeletewith regards to determining what to change- run the content generation algo as currently programmed in parallel using existing seeds to get a generic map, diff it, the diff is user changes, then generate the new terrain using the new setup, then import the diff on top of it?
I have a question. This may go far outside of the scope of voxel farm. Currently, procedural content is rendered via noise-based solutions that seek to approximate a 'realistic' appearance. Are there any scientists out there who have developed algorithms that describe actual terrain on earth? If not-
ReplyDeletecould it be possible to import actual natural terrain, use some kind of neural network to "learn" it, then import that into the procedural generation system?
It seems believable that neural networks, which can generate realistic audio, text, and pictures, after being trained, can be used to generate realistic terrain.
https://affinelayer.com/pixsrv/index.html