From WM 1.2 onwards, World Machine has supported Large Address mode, which is handy for those of you building very high resolution worlds (4096+).
You can see more information about the problem, and the solution, here:
http://www.world-machine.com/large_address.html
Note that this is an advanced tweak for power users only. Nonetheless, until 64bit windows is more prevalent this is the best bet for creating high resolution worlds.
Quick translation in french, correct me if I’m wrong :
Quelle utilité :
Améliorer la capacité de World Machine à construire des réseaux de résolution maximale (8192x8192).
Vous pourrez en bénéficier même si vous avez moins de 2 Go de RAM, puisque le problème est indépendant de votre quantité de mémoire physique.
Configuration requise :
Windows XP Edition Professionnelle UNIQUEMENT
World Machine v1.2 ou ultérieure.
Résumé :
Lorsque vous construisez un réseau de grande résolution (2048 et plus), la mémoire disponible est une ressource précieuse. A cause des limitations de Windows, WM 1.2 sera incapable d’avoir approximativement plus de 4 heightfields de résolution maximale (8192x8192) simultanément en mémoire. Suivre ces instructions vous permettra d’avoir 3 ou 4 heightfields de plus, suffisamment pour pouvoir construire des mondes plus complexes.
Plus d’information sur le problème :
World Machine peut nécessiter une grande quantité de mémoire de votre système. Mais la plupart des gens ne sait pas que ce n’est pas la quantité totale de mémoire physique qui définit ce que WM peut construire, mais l’espace d’adressage disponible. Une machine 32bits peut adresser jusqu’à 4 Go de RAM, et chaque programme en cours d’éxecution a son propre espace d’adressage qui lui permet d’intéragir à la fois avec votre mémoire physique et virtuelle. Cependant, Windows ne laisse par défaut que 2 Go d’espace d’adressage pour les applications, réservant les 2 autres Go au noyau. Combiné à la fragmentation de la mémoire et à l’utilisation qu’en fait WM, un espace d’adressage de 2 Go risque d’amener WM à être à court de mémoire après avoir créé ne serait-ce que 3 ou 4 heightfields de résolution maximale (8192x8192).
Plus d’information sur la solution :
Windows XP Edition Professionnelle a un marqueur spécial qui permet au système d’assigner plus d’espace aux applications et moins au noyau. Si le programme a été créé de façon à pouvoir prendre avantage de ce marqueur, il pourra assigner 3 Go de mémoire au lieu de 2. Ce gigaoctets supplémentaire est suffisant pour donner beaucoup plus de flexibilité et de complexité aux réseaux de résolution maximale de WM. Cependant, pour cela, le fichier d’initialisation du système d’exploitation doit être modifié.
Instructions :
ATTENTION : CETTE PROCEDURE POURRAIT RENDRE VOTRE SYSTEME D’EXPLOITATION INSTABLE OU INEXPLOITABLE. PROCEDEZ AVEC PRUDENCE ET UNIQUEMENT APRES AVOIR SAUVEGARDE TOUTES VOS DONNEES. SUIVEZ CES INSTRUCTIONS A VOS RISQUES ET PERILS.
–>Allez dans le Panneau de configuration.
–>Choisissez l’icône “Système” (il devrait être dans la catégorie “Performances et maintenance”).
–>Cliquez sur l’onglet “Avancé”.
–>Cliquez sur le bouton “Paramètres” de la section “Démarrage et récupération”, puis sur “Modifier”
Cela ouvrira votre fichier votre fichier boot.ini.
–>Dans la section [operating systems], il y a une entrée qui ressemble à quelque chose comme ça :
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=“Microsoft Windows XP Professional” /noexecute=optin /fastdetect
Vous devez ajouter le texte /3GB à la fin de la ligne. Pour plus de sûreté, on peut faire une copie de la ligne ci-dessus, et ajouter le texte à la copie, amenant Windows à vous demander au démarrage si vous voulez utiliser le mode standard ou le mode 3 Go.
La section doit alors ressembler à quelque chose comme ça :
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=“Microsoft Windows XP Professional 3 Go” /noexecute=optin /fastdetect /3GB
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=“Microsoft Windows XP Professional” /noexecute=optin /fastdetect
Sauvegardez et quittez la fenêtre du bloc-notes. Redémarrez votre ordinateur. Au démarrage, choisissez l’option “Microsoft Windows XP Professional 3 Go”, et World Machine pourra alors utiliser jusqu’à 3 Go de RAM pour le processus de construction !
Feel free to move this if it doesn’t belong in the sticky.
I have so far been frustrated in my attempts to write 4096x4096 heightfields in Windows 2000. Half the problem is that my test scene has three consecutive erode devices, and it seems memory consumption goes up with the number of devices even after using full memory conservation mode. The other half may be a lack of full interoperability with Windows 2000 memory management.
When my heightfield is built or one device away from being built, a message will pop up informing me that I don’t have enough system memory to continue. This is especially irksome if all I want to do is save the completed heightfield, some 3 1/2 hours or CPU time. This lack of memory error occurs even though I have some 350MB of physical memory remaining of my total 2GB. I can even manipulate images in Photoshop with my remaining memory.
Since no one has mentioned this, I suspect it may be an issue with Windows 2000. World Machine never seems to do any disk swapping–perhaps some of the under-2GB address space is taken up by the pagefile which W-M never addresses? I don’t really know enough about Windows memory management to speculate.
Hi there,
As you noticed, the problem doesn’t have to do with total physical memory per se. Each application gets its own 2GB address space to play in that can use any combination of physical or virtual memory – that part of it is handled by the system and isn’t any concern of the application.
Where WM runs into trouble is that the app itself has a memory footprint that contains all of the different system DLLs used, the program code, program resources, etc. These things fragment the address space, and so it becomes impossible at some point to allocate 256MB or even 64MB of contiguous address space, even though there may be hundreds of “free” MB of address space left in its virtual address space, and maybe even gigabytes of memory left on the system (If you outfitted a WinXP system with 8gb of ram, for example, this would still hold. You may have 6GB of ram free, but WM – or any application – can only use 2GB of it itself.)
The /3GB flag of XPPro gives WM alot more room to breath and tends to help greatly, but Win2k doesn’t support it, although I believe the server edition does.
Is there anything that can be done?
One thing that occurs to me is that multiple Erosion devices can be a big culprit because by default WM saves the heightfields on unconnected ports – like all of the auxillary mask ports for erosion. Normally this isnt that big of a deal, but with Erosion having 3 extra outputs each, and having 3 erosion devices, an extra 576MB of address space is being consumed. This occurs even in Mem Conserv mode (where admittedly a much smarter move would be to kill any heightfields that aren’t connected through its port).
One work around that might help is to “sink” the unconnected aux outputs on the Erosion devices… Chain a bunch of Chooser devices together and wire all of those unconnected aux outputs to the inputs of the choosers. This will deallocate alot of those heightfields and save a good chunk of memory. You still face the same fundamental problem, but it will probably extend the size of the network you can use by quite a bit.
And of course you’ll be handling mem conservation more intelligently in the future, right? 
Since no one has mentioned this, I suspect it may be an issue with Windows 2000. World Machine never seems to do any disk swapping--perhaps some of the under-2GB address space is taken up by the pagefile which W-M never addresses? I don't really know enough about Windows memory management to speculate.
No, seems to be WM.
I have the same problems, with a 4G system (3G available under XP).
With an 8K world, I can’t even do a file input ->erosion->file output. Memory used is 840m.
Memory fragmentation shouldn’t be a big issue with 2000 or XP, NT has allowed discontigous memory for a while ‘sparse allocations’ although I forget the exact API’s. But in any event maybe it’s better to allocate memory on a per line basis. Somehow to me, doing a malloc for the whole block seems a little too simple.
Well, RTFM - I had forgotten the /3G switch, which is odd, as even with it I don’t have any more RAM. I thought I had added it but double checked.
I can now get a 3 node world to build, although the funny thing is that I still haven’t gone over 1.5G or so of VM space for WM. Not even close to the 2G limit.
I’ll try adding more nodes and see how far I get.
The same size world and doing an ‘erosion’ in Leveller takes much less memory, but at least it’s sort of working now.
Again RTFM :oops:
== John ==Does this make any sense with a one GIG-RAM system?
Surprisingly, yes, if you’re trying to build very large resolution networks (8192x8192).
The rule of thumb determinant for if its worth trying:
Are you running into out-of-memory errors? if so, give it a shot. 
If not, it’s not going to help at all.
ah, ok. i will try that. even my little ‘icebergs’ macro needs some ram
Hi,
I’m working at Qubesoftware Ltd. , we bought WM standard version here for r&d purposes, as we found it very cool especially for the quick 3d preview and the bunch of nice erosion algorythms producing quick beautiful details.
But when it comes to rendreing large pieces of terrain to add these crusty sub-details on 8192/4096 or even 2048… we meet the same problems as some other users I saw on this forum. (varies depending on machines)
We went through the “large adress” page advice, but didnt attempt it because we found a bit dangereous.
Even though we’re still fan of the tool, and would be happy to see further updates.
I would recommend, perhaps using something like a scratch disk functionality to give more breath and buffering to the build process : hard drives are fast enough to handle that today, photoshop does it well for example.
Thanks for your help.
Cheers.
Seb.
Hi,
It’s my opinion only, but I think memory problems should be less annoying with the “Tiled Build” feature that will come with WM Pro
The large address mod definitely helps quite a bit with any very large memory usage issues; as well, make sure “Memory Conservation” is turned on in the preferences before you build.
Ultimately, the unavoidable fact is that a 8192x8192 heightfield takes up 256MB of space in memory; and that some devices require 3 or 4 heightfields in memory at once (such as erosion), making memory a problem no matter what on 32bit systems.
There might be some help upcoming in WM pro for this issue.
Hey all,
I took it a step further and had my company buy a 64 bit machine with 4 gigs of ram and we’re still running out of memory. Any helpful hints? We know about all the conserve memory options and even tried the cheat on a standard machine.
Thanks!
Adam
Hi Adam,
what resolution build are you attempting? With how complex a network?
Running under win64 is pretty much the best case scenario, so I’m quite interested in seeing where it is running out of memory.
Sorry for the late reply. We’re trying to build 4096 worlds and the networks are extremely complex. The main reason for this is that we’re adjusting the terrain while feeding in design masks and path masks that the designers have defined as “playable” area’s. While I’d love to post a screen shot, I cannot…)
You in the bay area by chance?..)
Our environment artist is using between 30-40 nodes with a couple of erosion passes. He can send you the network with out the input files if you’d like. Your input would be MUCH appreciated.
In-game we’re running a 4 million poly terrain and would like to crank it to 16. The limitation is not the game engine but our means of cranking out 4096 source files.
Thanks!
Yes… the network alone would be sufficient and could be helpful for me to take a look at.
You can send it to support@world-machine.com
What about tiled builds with smaller tile sizes?
An option to do the internal processing with 16-bit or 24-bit heightfields would also help a lot.
The rounding errors should be quite acceptable for most terrains, as even a 16-bit height field
has a much higher spatial resolution vertically than horizontally.
For what it’s worth. I had the same problem with high res builds. I got round it by splitting the graph into sections and using intermediate files. This works fine. The only problem then is that you have lots of build to run in the right order, but the over all run time is not much longer.
Using tiled files results in a huge speed up as well as requiring less RAM. A build that takes 11+ hours only takes 20 minutes, great. The only problem is that I’m having a problem with the tiled files in reading them back into subsequent builds. See my topic on this.
Barrie