Author Topic: Voronoi column heights from heighfield  (Read 8684 times)

0 Members and 2 Guests are viewing this topic.

Beherith

  • World Machine Veteran
  • ***
  • Posts: 38
    • View Profile
Voronoi column heights from heighfield
« on: May 11, 2013, 06:15:26 AM »
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 :)

Remnant

  • Author
  • World Machine Guru
  • *****
  • Posts: 2311
    • View Profile
    • http://www.world-machine.com/
Re: Voronoi column heights from heighfield
« Reply #1 on: May 11, 2013, 02:06:14 PM »
Hi there,

yes, this is something that I"m interested in as well. I will put it on the backlog -- the method you specify is probably the easiest to get up and running and so is a strong candidate. I am particularly interested in the most-general scenario of this effect, which is to say essentially creating soft or hard segmentations of the terrain for further processing or texturing.
-- Stephen Schmitt
- Creator of World Machine

Beherith

  • World Machine Veteran
  • ***
  • Posts: 38
    • View Profile
Re: Voronoi column heights from heighfield
« Reply #2 on: May 12, 2013, 03:57:46 AM »
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?
« Last Edit: May 12, 2013, 04:10:35 AM by Beherith »

Beherith

  • World Machine Veteran
  • ***
  • Posts: 38
    • View Profile
Re: Voronoi column heights from heighfield
« Reply #3 on: May 12, 2013, 05:09:01 AM »
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!

Beherith

  • World Machine Veteran
  • ***
  • Posts: 38
    • View Profile
Re: Voronoi column heights from heighfield
« Reply #4 on: May 12, 2013, 05:15:17 AM »
HELL YES!


DaveD

  • Community Member
  • **
  • Posts: 5
    • View Profile
Re: Voronoi column heights from heighfield
« Reply #5 on: May 12, 2013, 05:05:58 PM »
Very nice Beherith!  I'm imagining epic battles taking place on each of those plateaus.  Mini battlefields, each one of them.   :D

Beherith

  • World Machine Veteran
  • ***
  • Posts: 38
    • View Profile
Re: Voronoi column heights from heighfield
« Reply #6 on: May 13, 2013, 04:43:51 AM »
If anyone wants to try this, you can download the .dll here:
http://beherith.eat-peet.net/stuff/Pillars64.7z

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.

Beherith

  • World Machine Veteran
  • ***
  • Posts: 38
    • View Profile
Re: Voronoi column heights from heighfield
« Reply #7 on: May 13, 2013, 08:57:02 AM »
Ok, for some reason, if there is a Pillars device in my world machine graph, tiled output does nothing. Any ideas?

Remnant

  • Author
  • World Machine Guru
  • *****
  • Posts: 2311
    • View Profile
    • http://www.world-machine.com/
Re: Voronoi column heights from heighfield
« Reply #8 on: May 13, 2013, 05:39:18 PM »
Hmm. Does your device work in Layout view?

If not, I suspect you have additional information being carried within the Device class that needs to be copied when a copy of the device is made with doClone().
-- Stephen Schmitt
- Creator of World Machine

Beherith

  • World Machine Veteran
  • ***
  • Posts: 38
    • View Profile
Re: Voronoi column heights from heighfield
« Reply #9 on: May 14, 2013, 12:47:18 AM »
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

Beherith

  • World Machine Veteran
  • ***
  • Posts: 38
    • View Profile
Re: Voronoi column heights from heighfield
« Reply #10 on: May 16, 2013, 02:38:14 PM »
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 :)
« Last Edit: May 16, 2013, 06:20:17 PM by Remnant »

Remnant

  • Author
  • World Machine Guru
  • *****
  • Posts: 2311
    • View Profile
    • http://www.world-machine.com/
Re: Voronoi column heights from heighfield
« Reply #11 on: May 16, 2013, 06:31:30 PM »
Moved the topic to the plugin forum..

Well, there really shouldn't be any reason why it wouldn't work in a tiled build. I will describe how the tiled build operates which might help:

1) At the start of a tiled build, the DeviceWorld that is the principle container for the instantiated device(s) in question is copied multiple times, with each private copy of the world assigned to a worker thread.

2) The area to be rendered is split up and each builder thread assigned different areas to create -- again, in their own copy of the world.

3) The builders go to work and the results are collected at the outputs and written as temporaries to disk. Your device instances will never be called from more than one thread, but any class-static data or global state must be threadsafe.

4) After all building has finished, the framework combines together the various tiles, doing blending as appropriate to make them mesh together well.


As mentioned this process is very similar to the way the Layout View operates, so if it works in that it should also work in a tiled build. As long as your plugin is well-behaved it should Just Work. (and I didn't see anything in a quick look through your Pillars.cpp that stood out as wrong).

I would double-check that everything is as expected with a simpler plugin device -- for example, double check that the default example Inverter device works as expected in a tiled build, which will quickly start narrowing down possible problem areas.
-- Stephen Schmitt
- Creator of World Machine

Beherith

  • World Machine Veteran
  • ***
  • Posts: 38
    • View Profile
Re: Voronoi column heights from heighfield
« Reply #12 on: May 20, 2013, 02:54:44 PM »
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?

Code: [Select]
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!

Remnant

  • Author
  • World Machine Guru
  • *****
  • Posts: 2311
    • View Profile
    • http://www.world-machine.com/
Re: Voronoi column heights from heighfield
« Reply #13 on: May 20, 2013, 06:22:30 PM »
ah -- yes, the Tiled builds operate under memory conservation, so the first RetrieveInput takes permanent posession of the input heightfield so that the second call fails. This would also be the case for a normal build if mem conserv is checked.

To create your own heightfield of the same dimensions as the input, just call:

HFPointer myHF = GetNewHF(context);

or exactly equivalently:

HFPointer myHF = HField::CreateNew(context);

where context is either the BuildContext passed into your Activate function or the PacketContext residing within an existing heightfield (retrieve with hf->getContext()).
« Last Edit: May 20, 2013, 06:25:41 PM by Remnant »
-- Stephen Schmitt
- Creator of World Machine

Beherith

  • World Machine Veteran
  • ***
  • Posts: 38
    • View Profile
Re: Voronoi column heights from heighfield
« Reply #14 on: May 22, 2013, 05:47:22 AM »
Thanks Remnant, ill post the finished device!

kalwalt

  • World Machine Veteran
  • ***
  • Posts: 15
    • View Profile
Re: Voronoi column heights from heighfield
« Reply #15 on: February 11, 2015, 05:00:47 AM »
Thanks Remnant, ill post the finished device!
Hi, @Beherith did you finished this device? I'm interested in it.

Beherith

  • World Machine Veteran
  • ***
  • Posts: 38
    • View Profile
Re: Voronoi column heights from heighfield
« Reply #16 on: August 04, 2015, 12:24:52 PM »
Pretty much finished, only source available though:

https://github.com/Beherith/world_machine