• Welcome to World Machine Community. Please login or sign up.
May 24, 2019, 10:56:04 pm


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 - hogjonny

Guest Forum / Tile output not overwritten
July 31, 2017, 04:01:53 pm
Build 1:  I built a 4 x 4 tileset, everything wrote out fine.

Build 2:  Then I used the same world, but built a 16 x 16 tile set ...

Any tile in the original 4 x 4 Build 1, was not overwritten in Build 2 (I can clearly see from the 'date modified' file data)

I've checked that the folders/files in the file tree are NOT read only, that would have been my first guess.

Anyone seen this before?
I have seen this issue before.

This usually has to do with devices that show the red !, for example the Clamp node if you set it to 'normalize' ... and I think it's basically informing you that this type of operation may behave differently in a single tile versus whole world as it operates on the current data.
World Machine has a bug ... it can't validate a tile-set with relative paths!!!

'Specify from Files...'

With the checkbox 'Use relative path to file' selected, the node can't validate the tileset.  Absolute paths work fine.

The problem here, is this is going to cause issues with portable automated builds:

  • I am creating world templates, set up with staged automation:  Build tiles, stitch tiles, etc.  So if I provision new levels from this template (copy the template to a new location), these absolute paths now have to be updated manually before the world can be built.

  • Automated builds will break.  Develop in branch 1 locally, build in branch 2 in a workspace on a remote farm - the absolute paths will cause the build to fail

Feature Requests / Re: Improved curve editor
July 18, 2017, 08:00:46 am
Also, it would be nice to overlay the linear curve while editing ... currently, I pull the curve strength down 100% to visualize the drawn curve against the linear one, then ramp the curve strength back up after editing.
Feature Requests / Improved curve editor
July 18, 2017, 07:42:42 am
Some additions to the curves node editor would be nice

1 - Visualize water height, I want to draw out flat under the water and smooth beaches along the coastline.
2 - Point based curve, so I can drop in points with specific heights
3 - Overlay a histogram, so I can visualize the curve against the input height fields data more easily
This morning I encountered this same problem ...

I am utilizing relative paths:

And I am trying to load a *.raw file from:

IF 'use absolute path for filename' is checked in the File Input Node, the image loads fine (and displays the warning 'No scale data present in file!')
        full path:  C:\depot\project\worldmachine\basicworld\inputs\height.raw

IF I uncheck that box (for relative path), the image will not load:
        relative path: Input\basicTemplate_4k.raw

- If you start with it checked, then load the image, then uncheck it ... the path doesn't update.  It seems this flag only modifies the next image load.

I think this topic may cover my needs:  http://forum.world-machine.com/index.php?topic=2400.0
I am trying to figure out if there is a way in the automation scripting, to specify which tile to build?

ideally, I could push the same world data (folder and file structure) to 16 machines, and have each build and render a single tile.

As far as I know, which tile to render is not exposed to the automation scripting .xml file!

But I was reading this about Wildlands:

And it mentions this:
We requested some additional dev to Stephen Schmitt, author of the World Machine. He added an additional variable exposition to the tile rendering system in order to use with a dedicated render farm written in c#.

Does anyone have a working example of this or know how to do it???
General Discussion / Re: Relative Paths
May 10, 2017, 03:51:27 pm
So there is one 'half measure' around this ...

In each world machine .tmd, you can go into the Project Settings and change: 'Default Relative Path'

I set it too:

Now, if I go back and reload the height map input, I get a relative path (downstream from this new root):

Of course, I've mitigated some concern for modularity if I change this root far enough back (to a common root) in each world file.

But, I still have the issue of data portability and a depot would still need to be mapped to the same drive and location for every user and build machine working in the project.

General Discussion / Relative Paths
May 10, 2017, 03:22:29 pm
Relative Paths don't always work the way I would expect them to...

Consider this situation:
- I want to use a Sand world, but then use it in several other worlds
- I want a Rocky world that also uses Sand
- I want an Island world that also uses Sand

I have two separate setups for folder structure that I tried.

{one} - This one is more flexible and ideal for modularity

My Depo:

My Rocky World

My Sand

In WorldA, I want to use and output from WorldB ...

  • when I use a input node, and point it to the height.tif from WorldB I get an absolute path:

  • C:\dev\worldmachine\WorldB\input_maps\height.tif

What I would expect as a relative path:  ..\..\WorldB\output\height.tif

Relative paths can usually be up and down the filetree?

{two} - this one allows for downstream cascading only, far less modular


In WorldA, I want to use and output from WorldB ...

  • when I use a input node, and point it to the height.tif from WorldB I DO get a downstream relative path:

  • WorldB\output\height.tif

There are a couple of issues and problems with this workflow,if you are trying to build modular and automate world building:

  • Data portability:  If I copied the c:\dev\worldmachine folder to another drive like D: the path is no longer valid, as it's absolute instead of relative.  Think build machines, source control, multiple users, workspaces and depot mapping ... this will eventually be encountered.

  • Modularity:  I have to always order reuse in a downstream way.  Eventually this will be a mess and become inflexible.

I wrote a set of stitch and split python scripts...
So I could stitch a world, then modify in photoshop
Then resplit the world into tiles.

I think at the time I was using PIL as the image library.  But I have since done similar things with OpenImageIO.

The biggest hurdle you are going to find, is how big of an image you can fit together and store or use.
- Photoshop allows for a maximum image size of 300 thousand  pixels in both width and height.
- 32bit photoshop can only handle something like a max size of 2G
- 64bit can go higher, with a PSB format you can go 300k x 300k as long as the image can be stored in 60GB (but I can't make one, because I don't have that much free scratch disk size)

It all depends on memory, file formats, image library support, etc.

But with my automation, the largest I even handled before running into issues of one kind or another was 8 x 8 x 4096, so you may be fine.
When setting up a world in the GUI,
in the Project Settings, you can create a 4 x 4 world
then you can 'select tiles to output' ... for instance, just 0,0

Basically, I want to do the same thing with the automated scripting (but can't figure out how).
Effectively, I want to render the world 16 times and each call, tell it which tile to specifically build.

Has anyone done this and have a working example?
You could theoretically use a language like python to script around the automation scripting?

- from heightmap input pool (folder)
- iterate through all heightmaps
-- for each:
--- copy heightmap from pool, overwrite the heightfield input file used in worldmachine
--- call to render output
--- call to move / rename output to a new location
General Discussion / Re: Automation Issues
May 10, 2017, 12:26:58 pm
I was wondering, if there was a way to specify in scripting to only render ONE specific tile?

I want a 4 x 4 world, but I want each of 16 machines to render a tile.
General Discussion / 2.3 vs 2.9 file support
June 02, 2014, 12:45:07 pm

So my CD created a .tmd in a version of 2.9 and I can't open it in the release 2.3 version.  I assume they are just not compatible?

Is there any way to port it to work in 2.3?

- hogJonny
I can't seem to find a link for downloading a 64bit .exe for the latest release - is there one?
Feature Requests / WM unit support
March 13, 2014, 10:26:42 am
Would it be possible to support a more generic base unit - as a whole unit?

As a game developer, I tend to think more along the lines of this:

1 unit:
    - what is 1 unit in my game engine?
    - what is 1 unit in my 3D editor?
    - how tall is my character in units?

1 unit = :
    - generic unit in engine
    - 1 m in maya (and/or 100 cm)

Character = :
    - 2 meters in height

terrain tile = :
    - 1024 units / m on edge
    - 2048 texels on edge :: macro = 2 texels per unit = texel is 0.5 u/m
    - 64 texels per u/m ::
        - 1024 detail map = 16 u/m = 64 x detail repeat

So in World Machine, I tend to want to just work directly in meters/km - the crux is that likes in many cases WM likes to display in km:
    - I put in 1024 m
    - it displays 1.03 km  (It would be nice to at least get another decimal place so I can work with a precision that represents my whole number units with confidence!)

What I do as a work around?
    - I let 1030 m / 1.03 km be my default tile width/height (because then, any whole number multiplier of that works out 3 tiles = 3 x 1.03 = 3.09)
    - basically, 1.03 km = 1024 units (which is a bit funky for artists to think about)

Switching to 'World Machine Unit' doesn't work out well, as it's basically a floating point (which is even less artist friendly)

Anyone else have any thoughts or input on this?
Feature Requests / WM save button icon
March 13, 2014, 09:06:37 am
How about a toggled save icon, that indicates visually if the files current state has been saved (like notepad++ has)?
Feature Requests / Re: Incremental Save
March 12, 2014, 10:21:05 am
More on this for anyone interested:

When at LightBox Interactive - we created a backup daemon (in python I think), that would run in the background and take local snapshots and do nightly backups, so we had revision control between perforce checkins.

But while working here at Bluepoint Games,  I recently found a really awesome tool that does this (that is easy to set up), it's called FileHamster.  It will snapshot a revision backup every time a file is saved (in a marked location), there are additional settings for #of backups, etc.

It's a great tool!

I have a feature request (a few points I may have brought up before)

1. Relative input/output/paths:
These are obviously useful for project automation (build as well as !setup!), organization, etc.

  • You CAN already specify 'Default Relative File Path'

  • SOME nodes like 'File Input' and 'Heightfield File Output' support relative paths

  • Other nodes like 'Bitmap Output Properties' DO NOT support relative paths

It would be REALLY nice if everything supported relative paths!

2. Scripting support for modifying/setting file input and output

The WM automation is a great feature!  It would also be really fantastic if there was scripting support for setting up projects, files, node structure, input/output.  I can imagine the ability to fully automate and script the setup and build for a massive world built from tilesets.

Want to go the distance- add a python API!  I volunteer to help :)

Some context:
For my projects, I set up a template world.  We have a common folder structure and naming conventions, to help with automating preview builds, full-res builds, processing and converting.  Pretty much, I remove as many sets as possible from people's daily routine - so they can do what they do best creatively.

We have setup scripts, which clone the template to properly set up new worlds that match project conventions - the only real significant hurdle right now; is that after cloning a world, in order to ensure the world builds into the proper paths is to make sure they go touch every bitmap output node to make sure it's pointing to the proper location.

The biggest snafu is that this is error prone, it is easy to miss a node for example - and this is lost time if it's a mistake in a large world that takes hours to build full-resolution!