Thanks my saviour!
Why did I never thought of that?
Only problem is that it’s only square/rectangular prism, which helps but not when you need circular things…
Thanks my saviour!
This will be Super helpful with my games. Terrain has been awful to work with for the longest time.
Oh, sick! In the future, will we be able to change the terrain voxel size? That, and being able to make hollow terrain, would make terrain amazing to use. (Also occlusion mapping please)
The brush part disappearing is absolutely annoying, other than this, I am pretty happy with the update. If I want to visualise the terrain which is under a part, I have to use wireframe mode to preview it :////
I’ll look into fixing above indicated bugs, they should definitely not be happening. I’m not really able to reproduce the wireframe bug, but upon looking around it does seem to happen in the “Starting Place” demo for some odd reason. This might be a bit of a tougher one though, because the origin of the bug doesn’t seem to make any sort of sense. If you remember, what template did you start for with this place?
The brush part disappearing when you are working was intentional. We spoke with some artists, who said they prefer the brush be out of the way while they’re working so they can more easily see the changes they’re making. I’ll revisit this as well.
We thought it would be better to keep combine the sea level and fill tools in this case. We mostly did this to boil down the toolset into the simplest components, but will also take this feedback into account.
Are there any plans to make the LOD system for terrain rendering editable?
So we as players can make terrain render properly at distance if we so choose maybe via a slider next to graphics settings?
There are plugins which expand this limit to infinity and I havent encountered issues with that yet. So could you add an option to deactivate this limit? That would be super helpful in order to move/duplicate larger terrain blocks.
I have a weird feeling the team is ignoring this suggestion entirely. Either that or they have this in the works already. It better be the second one. It’s just weird to see them saying they want games using terrain to look better, but then persist to not implement the correct features.
100% agree. The terrain system needs a huge overhaul with how customisable it is. It’s getting a little annoying when they don’t even tell us where they’re at with some of these features.
Will we ever se any mesh to terrain tool/system? For converting meshes to terrain? I remember a guy made a plugin like that, which i am using currently, but it would be much more efficient if it was already a studio feature!
Agree, the new shortcuts are far less intuitive on keyboard and mouse than old ones.
For those running into issues with the Wireframe, the issue will be fixed in the coming weeks. This is an issue with WireframeHandleAdornment.
For your information, if you have an older place that has parts with SurfaceType properties, there is a good chance that they (or at least the visual adornments they produce) are responsible for the wireframe being offset in strange ways.
Thanks for the feedback! Though these sorts of improvements aren’t in this update, we know that additional options for customizing terrain are important and hope to have more to tell you in the future.
I’ve tried removing the limit given our new algorithm for rotating and scaling terrain. Unfortunately this is extremely slow and in the worst case crashes studio. We may look into ways that can make these processes run in the background and which make sure that studio does not crash.
any chance these mentioned algorithims will become part of the engine API? It would help a lot when trying to dynamically load and edit terrain in game. For example, a method that moves a terrain region to a certain cframe would do wonders.
I’ll consider it, though it might take a bit of time for that to go through as a public API. It is also a bit whacky since, as many people are no doubt aware, terrain is based on a voxel (3D pixel) grid. In this case, the plugin calls copy region, calls the ApplyTransform method, and then pastes the region back in. The ApplyTransform method does two things, which is:
- Determine a new bounding box which needs to be used in order to properly fit the extents of the rotated chunk
- Iterates over every voxel in that new bounding box, then inverting the transform cframe in order to get a source voxel (plus some interpolation magic for scaling)
For now you could theoretically imitate this in Lua, though it would be slower. Its also worth noting that once you apply a rotation there is no good way of getting back. Also, once you have such a rotated region, it would be fairly problematic to rotate again as your TerrainRegion (or in the case of Lua, your 3D voxel array) also contains a bunch of empty voxels. In other words the operation is destructive and the TerrainRegion degrades the more you rotate the same one.
Gotcha, even if there are limitations to the API like only being able to rotate regions by 90 degrees to maintain voxels, anything would help vs what we have now. Anyways, thank you