• Welcome to World Machine Community. Please login or sign up.
October 13, 2019, 06:16:33 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 - Beherith

Pretty much finished, only source available though:

I did not pursue the further development of this plugin, so this is pretty much the latest build for now. The source code is shared and Public Domain.
Plugin Development Forum / Re: Ambient occlusion plugin
February 15, 2014, 06:22:41 am
please forgive my ignorance, but i learn best from examples. could you link to a multithreaded working simple example, as the way input and output heightfields are passed to the multithreaded implementation is not clear to me. thanks!
Plugin Development Forum / Re: Ambient occlusion plugin
February 13, 2014, 03:25:48 am
I just ran my plugin on an 8192 sized map, and it only added half an hour to the run time, with settings that could be considered 'good quality'.
This is faster than using xNormal (which is an excellent program, but is designed for meshes, and jamming in obj meshes of this size is not prudent).

My next step is to use reflective scattering (similar to tone mapping) as the following:
-If a ray hits a bit of terrain, it will use the texture color in the area.
-if a ray does not hit terrain, it will look up the sky color at that point from a 'sky color map'.

The only thing missing (forgive my ignorance) is that I cant seem to find a good example of reading the RGB values of a bitmap input. No method similar to the HF() wrapper seems to exist.
Plugin Development Forum / Re: Ambient occlusion plugin
February 12, 2014, 12:40:21 pm
You are free to use the source (its included in the archive), completely free license.
I do have one more question though, as I couldnt find a good example: how can I multithread this device?
Plugin Development Forum / Re: Ambient occlusion plugin
February 12, 2014, 09:35:25 am
Unzip the .dll file into plugins/devices.
Plugin Development Forum / Re: Ambient occlusion plugin
February 12, 2014, 04:27:30 am
Image of the AO in action:
Plugin Development Forum / Ambient occlusion plugin
February 12, 2014, 04:26:39 am
Would there be any interest in an ambient occlusion plugin? I coded one that looks quite reasonable, but its performance isn't so good (takes about 10 seconds for a 1024^2 heightfield at sensible settings).
The source code and the built x64 device is attached.

It takes a heightfield as input.
You can specifiy the number of rays per pixel, the minimum hit distance for a ray (this is great for edge highlighting) and the maximum distance a ray travels, along with a height scaling factor.

Made with pdk 2.3.6
Often times Blur devices are very expensive for me (I probably use too much of them with too high radii anyway), even if i'm only using them masked off on small parts of the terrain.

Would it be a good idea to check if the mask value is zero before calculating the gaussian blur of a pixel? This could be applied to other slow devices as well.

EDIT: it just occured to me that gaussian blur seems to be a 2 pass algorithm, (cause its ordo linear with kernel size), so implementing this might not be straightforward.
Thanks Remnant, ill post the finished device!
Ok, I found the bug; I needed an extra heightfield to store what parts of the input heightfield was already iterated over, and I used RetrieveInput(0,context) twice, hoping that I would get a free heightfield. While this worked fine, it broke tiled building.

Now I added an extra input to the device, but that input is not used, it is only used to mark where the stepwise algo visited already.

How should I use the framework to allocate a heightfield without using new or delete?

HFPointer hf = HF(RetrieveInput(1, context) ); // Use the RetrieveData(),StoreData() pair to get and set your heightfields
HFPointer hf2 = HF(RetrieveInput(0, context) ); // Use the RetrieveData(),StoreData() pair to get and set your heightfields
HFPointer hf3 = HF(RetrieveInput(0, context) ); // WOOHOO FREE HEIGHTFIELD!
Are there any guidelines or prerequisites for preparing a device for tiled builds? Also, could you please move this thread to the plugin subforum? It has grown beyond just a feature request :)
Works just superb in layout mode. I just modified the Activate function of the example inverter device in the PDK.
Pastebin Pillars.cpp http://pastebin.com/ftRHmEV9
Ok, for some reason, if there is a Pillars device in my world machine graph, tiled output does nothing. Any ideas?
If anyone wants to try this, you can download the .dll here:

Please note that it only accepts CONVEX SHAPES (good old voronoi cells are guaranteed to be that, unless you distort them) as a segmentation input.
The primary heightfield input can be anything, and the device is easily maskable as well.

This archive includes the source. The license is the 'do whatever the hell you want with it' license.

Ok, nevermind, I set the max stack depth to 2000, cause it was crashing around 4000, and also fixed a but in the stepwise walk algo (no steps backwards) that relies on the assumption that voronoi shapes are convex!
Ok, so I took a cell type voronoi and a default perlin hill, and then collected all the pixels that correspond to each segment, and the read the height from the perlin at the geometric center of the segment, then mapped that value onto the whole segment area. Kinda happy :)

Ill share the device once it crashes less :P

EDIT: i think im running into a max stack depth issue when walking around the segments, what can i expect that to be the max?
I know you are a busy man, but there is one thing that has been bugging me about the voronoi noise generator, And its the fact that I have been tryin to acheive basalt columns ever since WM 1.x, but getting the tops of the columns flat has been impossible.
It would be amazing if Voronoi had another heightfield input, where the heights for each column are sampled from this heightfield, and not assigned at random.

I wish to achieve this basalt effect:

I would happily use the PDK to modify the existing voronoi device code, I just dont wish to recode it from scratch :(
Ive even gone as far as to use an external python script to generate the voronoified heightfields :)
Development News / Re: 2.3 *FINAL* Available
April 02, 2013, 04:36:53 am
2.3 is absolutely amazing!

I love all the new devices and especially the example world files. The examples offer great starting points to both newbies and more experienced users alike.
I really like the additional window option, too bad it only allows itself to be launched if you have 2 monitors. I turned on a secondary monitor just so I could enable it on my single screen.

The splat device is godlike, replaces a ton of extra useless boilerplate nodes in my workflow.

Thank you for your continued hard work!