• Welcome to World Machine Community. Please login or sign up.
October 18, 2019, 06:20:17 am


Read the Development Diary for an inside look at World Machine's progress!

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Zehryo

Bug Reports and Help / Re: Large tiled UE4 Import bad
August 11, 2018, 09:22:32 am
UE4 is a bit of an oddball, in terms of importing scales.
512 is the height reference, if your world machine extent has a maximum height of 2048 (always pick multiples of 512!!), then your Z scale should be 400.
For orizontal scales it's the opposite: 512 (or 505?) as the reference, if you import a 2048x2048px heightmap, your X/Y scale should be 25.

And that's it, it more or less works in multiples of 512. It works like a charm.

I dont know anything about World Composition, but I assume previous answers are correct.

Also, remember that UE4 calculates the zero height halfway throught the range, as it goes from 512 to -512.
Assuming your maximum (possible) height in WM is 2048 meters, if you want your terrain to be automatically imported at UE's zero, you should set your terrain zero at 1024 meters in WM (bring your water level at 1024 meters by adding a constant generator to the whole terrain so that they add up to 1024).
Bug Reports and Help / Re: Can't type in clamp value.
August 11, 2018, 08:41:35 am
Did you try by specifying the measure unit? Like typing in "1000 m"?

More often than not (at least in older versions), WM would assume you mean kilometers, when no unit was explicitly expressed. No idea how it works now in version 3, but worth a try.
More easily, maintaining the same pixel/meter resolution when you reduce your extent's size should fix it. Mostly.

You should be aware that the erosion node is partly driven by the extent's boundaries, which might change the way this node behaves. Althought your terrain doesnt look like it might suffer from this.

An idea could be rendering the whole extent at the same resolution you want for the close up scene, reduce the obj polycount (if needed) in Maya or in ZBrush (ZBrush has awesome tools for decimation) and then capture its normals.

At this point you have two 3D models, one very high poly and one low poly with detailed normal maps, both with corresponding volumes (mostly, depending on the decimation level) and showing the same amount of details.

If they dont need a fly-over take of the scene, cutting and pasting together the close and distant areas should be an easy operation.
I stumbled on this visual glitch myself, usually re-rendering the terrain helps, or even just zooming in and out or changing to the 3D view and back....it should be temporary.
No, he means you should use a "combiner" device and set it to "Average" mode (which should be the default anyway).

You're right those lines are not something you can prevent, since you're basically mixing two hemispherical shapes.
What you could do is making them as a one single shape.

Usually, when I want to make a chain of hills or mountains, I use simple lines and I give vertices different heights (right click on a vertex and select "Enter precise value...").
This way I can manually set the altitude of the area where the falloff of two peaks encounter, leaving no "wrinkles".

I see how using circles makes all the sense in the world, but I find it to be a very stiff way to create elelvations.
Anyway, passing the whole bunch of elevations into one single erosion node could elegantly blend them together even as separate shapes.
Heightmaps basically are grids of numbers expressing altitudes.
At your present resolution, every pixel defines the altitude of a 1.5 squared meters area. Have you tried raising the resolution of your heightmap to something like 1px = 1sqm (or even higher)?

Also, at 16bits you have a range of 65535 levels of grey to express altituteds. If you set your world to have a maximum height of 65535 meters, this means every tone of grey will be equal to 1 meter.
With a 12x12Km extent, I doubt your mountains will be anything wider than 4x4km each at most, which means the maximum altitude will probably be no more than 3000 meters.
If you set your world's maximum height at around 3000 meters, your resolution in terms of grey tones would be 20 tones per meter, 5 centimeters per grey tone. Plenty of resolution, I'd say.

Anyway, a visual hint of your problem would help define a proper solution much faster, mind sharing a screenshot of how things "go south" when you scale things down?
Bug Reports and Help / Re: Can't Import Terrain To UE4
August 11, 2018, 07:45:53 am
First it would help a lot if you could tell us more precisely where you get stuck, what kind of error you are notified with, how UE4 behaves when you try to import your heightmap.

I'm currently working with UE4 too, importing heightmaps just from WM. It's an all new thing, for me, but I'm encountering absolutely no issues.
Hi everybody, been years since my last visit....and the last time I found myself using WM. ^^'

Straight to the problem: I have a 500x500 meters extent; in this extent is an island that takes most of the space; over this island I'm placing some hills of the smooth kind.
Although of the smooth kind, I'd like these hills to have some variance in their base shape (not just roundish like a pregnant lady's belly).
To make the hills I used layout lines with specific altitudes for each vertex. To achieve a more interesting look I wanted to exploit the shape breakup feature.

Alas, the shape breakup scale value can't go anywhere below 333m in size, which means every feature would be roughly 4-6 times the size of the hill itself.
I see no input hook named after this parameter, on top of the device, thus I guess using a scalar input is not an option.

I want orizontal distortion, not vertical bumps, thus multiplying it by a perlin noise wouldn't give me the right result.

Question: is there a workaround for this? Or maybe an alternative?

Thank you. ^^
Hi, I've been away for a while, but lately I've been tinkering with WM again, and I've thought of a feature that might come in handy for those who, like me, like to work with games' worldspaces.

So, this is my idea.
Many game engines have serious problems with steep slopes, especially when they're over 20 meters tall, nearly vertical leaps; furthermore, some of them also have mid-low poly terrain resolutions, which makes very detailed maps nearly unusable because of the resulting vertex spikes.
What I used to do in the past, when making worldspaces for Oblivion and Skyrim, was rendering the terrains at a low resolutions (2048 or 4096), and then use them as file inputs to re-render the terrain at the actual resolution I needed, which was (16k x 16k).
This would eventually soften all the features, especially when coupling the file input with a blur filter or a similar effect.

Would it be possible to make an output/scalar object capable of scaling up/down the output resolution?
Like, the project's base resolution might be 2048x2048, while the output would result in a 16384x16384; all the objects until the final output would process the maps at 2048, but the output would re-process the final map at 16384.

ACTUALLY, it would work better as some kind of "inter-objects re-sizer", like an image processor that takes an object's output and gives out a resized/re-rendered version of it.
Something like:
[Base resolution: 2048] -> [Advanced Perlin] -> [Erosion] -> [Resizer: 16384] -> [File Output: RAW map]

This way, one would save lots of RAM and time; and this is just a very simple example. One could calculate complex maps at low resolutions and then resize them to, like, filter other objects' higher resolution outputs (when super details are not needed).
It would work like a crossbreed of the [Height Output] and [File Input] objects, but without an actual disk output/input (not needed, since the map would still get loaded onto the RAM anyway).

Silly idea? Someone already implemented this in a plugin/macro?

PS: an alternative would be giving every existing object a built-in [Output Resolution] control, but it'd be a nightmare to program, I guess.
I guess my reply is coming too late, but I'd like to try help you.

Both Unity and WM give you quite some freedom, when it comes to the pixels/units ratio. Your best bet to get a full 1:1 correspondence between the WM heightmap representation and the Unity terrain is to give both the same ratio.

Point is that WM best works with powers of 2, which means 8192x8192 is the most fitting resolution you want for your 8x8km map, which you can then split in as many tiles as you want (1024x1024, 2048x2048 or 4096x4096).
If you want a perfect 1:1 ratio, I suggest you to set both your Unity and WM terrains at a size of 8192x8192 meters, which shouldnt clash with any other software restriction.

This should do the trick, let us know if it works. ^^
I'm in, I'd find it very useful; especially when I need to "understand" the scale of a mountain over a very large area.

Also, it would be very useful if we could get some sort of "altitude snapshot" in the 3D view: you know, like a few tags distributed between water and the tallest peak to show lowest, intermediate and highest elevations.
Bug Reports and Help / Re: Link slider
February 03, 2013, 01:17:20 am
Ok, try this.

- Export your terrain heightmap from the game editor and import it back in WM through a file input device (watch for height scales).
- Set an erosion device right after the file input one.
- Configure the erosion decive to a standard, non-filtered, non-geological type, with an average rock hardness and sediment carry amount (everything else to default)
- Then play with the sediment amount until you get the right look of the flowmap

Here a trick to keep an eye on the final result: connect an overlay view output device to the file input device and to the erosion flowmap channel (file input device -> [overlay primary input] ;; erosion flowmap -> [overlay secondary input]).
This way you'll have a glimpse of the flowmap over the non-eroded terrain; the non-filtered erosion should change the overall terrain look not too much so that the flowmap actually fits the original terrain shapes (check attached screenshots).

The point of this all is to use YOUR edited heightmap with WM's erosion flowmap, which should blend in pretty well, if you dont use strong erosion effects.

It's a silly idea, but it's all I could come up with, at the moment.

NOTE: I've attached three pics showing the devices workflow, the erosion device configuration I've used to test and the 3D view resulting from this setup (default perlin terrain + terrace from WM startup chain).
Got your point.

Well, the fact is that erosion flows output is closely related to the terrain heights and shapes and it's not just a matter of marking the "channels".
When you erode, WM calculates movement of debris and sedimentation of the same debris, and then marks the lines through which the debris moved: thus you cant calculate erosion channels without some terrain actually moving top-to-bottom over a mountain/hill.

So no, you cant calculate flowmaps without an actual erosion effect.

Anyway, if all you did was re-scaling altitudes or just lowering some peaks, you should still be ok with the original erosion flowmap.
Bug Reports and Help / Re: Runs forever?
January 20, 2013, 05:46:26 am
Sounds normal, to me.

65535 is an "omg" resolution. It says 76GB, in the screenshot, but it actually is always higher than that.
So it's paging in and out like crazy, which slows the whole process quite a lot.
To speed up my renderings and reduce memory requirements I often bake parts of the chain in separate RAW files and then replace the respective devices with a single File Input.

Everything's ok, as long as the area I'm importing has the same resolution as the main extent; but I often set different extents, if I have isolated isles, so that I can reduce the resolution along with the size and save some rendering time and HDD space.
Since the resulting RAW files are smaller in resolution than the main extent, I have to manually set it to keep the right scale, which is pretty annoying, if I cant remember how many kilometers per side they were.

So, let's say, if my main extent is 4096x4096px and the pre-baked isle is 1024x1024px, I'd like to have a button that sets the size of the input depending on the resolution ratio between the RAW file and the extent, which, in this case, is 1/4.

Would it be possible? =o

PS: please, check this topic too -> http://forum.world-machine.com/index.php?topic=2031.0
No, still using 2.2. I have some kind of idiosyncrasy for beta versions and in this particular case I'd like to be sure I can backstep to any previous project without compatibility/bug problems.

Anyway I dont have any memory issue, it seems I just like to build complicated chains. ^^'

The target RAM I've set is 70%, which means around 8,5GB over 12. Now, the system alone eats about 2,6GB....I should still have 1GB+ of free memory, during rendering, and I do indeed. During renderings the memory usage never goes above 10,5GB.

EDIT: I've also posted an idea in the "Road painter" topic and I'd like to know what you think about it.... =)
Yep yep, I do use that feature to save some RAM, but it's still a resolution of 16384x16384 multiplied by all the heightfields involved in the rendering.....
I have 12GB of RAM, but it's not enough to handle that much for a long chain.... ^^'

EDIT: wow, 56 posts and I'm already a "World Machine Guru"!? =o
I would've said it to require at least 150-200 posts! ^^
I've noticed, when building terrains at very high resolutions, that WM can take a huge amount of memory, when many heightfields are involved at once.

I guess this is how WM manages heightfields when working with several devices:
- it starts with the first device, which may require from one to several heightfields to be calculated
- once the first device is calculated, the result can be one or several heightfields which get stored in memory
- then on with the second device, which may have multiple outputs too, which will all be calculated and stored in memory
- and so on with third device, fourth, etc etc....

This storing has a very useful purpose, which is the one of being able to change some parameters and re-build the terrain starting just from the device that has been changed; as well as being able to select any decive along the chain and check it's specific output.
But this also takes a LOT of memory because every single device has one to several heightfields stored in memory which can be many and at high resolutions.

So I was thinking: why not being able to set which devices should reatain their heightfields in memory and which ones not?

Let me explain.
Let's say we have a chain composed as:
[Layout Generator]->[Advanced Perlin]->[Clamp]->[Erosion]->[Coast Erosion]->[Select Height]->[Simple Transform]->[Height Output]
Now let's say I'm very happy with the layout as well as with the erosion effect, but I want to play with the coast erosion and then with the simple transform to smooth some areas of the terrain.
All I would need is a heightfield for the erosion output to start with, as I would make no use of the ones that precede that device. And yet I have them all stored in memory.
So, according to my idea, I could set all those devices before the erosion one to not retain their heightfields in memory once they're no longer needed for calculations.
Of course I could not step back to check their outputs, but I've already decided that's not a part I want to change anymore. I think this would save a LOT of memory and would also allow me to render terrains at very high resolutions without taking too much RAM: once the output of a device is no longer needed by the following one, all its heightfields simply get unloaded.

I know I can somehow already do that by baking heightfields into RAW files, but this is not be a very dynamic workflow.
Imagine: baking the intermediate heightfield, disabling the calculated devices and then setting a file input to replace them in the chain. But what if I need to change something before that point? I have to re-enable the devices, re-render that part of the chain, save the file again, re-disable the devices, re-load the RAW file again....quite annoying and time wasting, to me.
Also, with the method I'm suggesting you could choose what heightfields to retain everytime you re-build the terrain, so that you can chose what steps of the chain are useful to be checked separately and could eventually need modifications, every single time you build it.
Plus, this would reduce the session status's size quite a lot, I think, as we could write down just the devices' outputs we'll really need the next time we work with that terrain.

Feature Requests / Re: Road Painter
January 16, 2013, 06:43:53 am
It cant be implemented the way you see it in that tutorial, for the sole fact that in WM you're not working on 3D meshes, but on heightfields (images).

You could set a tool that draws lines that get applied only as road masks, and only in the rendering phase, by modifying the altitude of the underlying heightmap to build a flat area perpendicular to the road-line axis.
By interpolating the effect, you could decide how accurately the underlying terrain's heights will be followed, so that you can tune how detailed and bumpy the road will be.

Using this method to paint roads, instead of using "layouts", would save us a lot of calculation time and will also result in a much less heavy tool for our CPU.
You could also set the tool to work as a separate "pre-bake it" one: you set the line, check its nodes (freehand-or-bezier option?) and then you "bake" it, which will make it generate a separate definitive mask. If you need to change the road-line, you just do it and then re-bake it, and yet its nodes' height would stay independent from the terrain's features.

Obviously roads would not show up in the "Layout View", but this would just save us CPU calcs and bring no real problems. It would work great with very large areas or roads that would require too many nodes, while you could still use layout generators for short roads or other kinds of elevated paths.

It would also be great if this tool could have a separate "final rendering" button, so that you can first check the whole terrain and lately apply the roads mask. I know you could actually already do it by manipulating the tools chain, but, you know, just for a matter of not doing it every single time you want a selective rendering. ^^