Hi folks! Lots of things are in flight right now on the dev branch — time for a progress report.
One of the things that goes hand-in-hand with the previous library and multiresolution support is the ability to create things in localspace. What does this mean?
Localspace
Localspace is a mode switch for your generators to allow you to create “free floating” individual textures, hero terrain elements, etc. These items are not located anywhere in the world; they don’t have a firmly defined scale or location. Think texture assets.
You can feel free to use all of the potentially-problematic devices you want (flipper, displacement, normalize, etc). As the packet is guaranteed to exist only in isolation, these manipulations are completely OK — there’s no tiles to mess up or anything like it. And you can of course save or load them like any other terrain (the library I/O works great here for banks of textures, etc).
Into the World …
When you want to integrate the localspace items into the world, you use a Placer device to insert the localspace item at a particular scale, to a particular location. And of course, the Placer uses the same sampling framework as introduced previously, so you can use fractal resampling, etc when placing it.
I’ve talked to a number of people who have found the “Object Placer” macro very useful when creating their worlds. This is basically the same idea, but formalized and integrated into WM itself — and consequently more powerful.
… with Tiling
In addition, you can use the Placer to tile the texture across the entire world. Right now there is only the option of regular tiling, but eventually I could see the placer also having an option to randomly scatter the object throughout the world, with optional rotation, etc.
An additional device that will eventually appear to complement the above is a seamless tile making device, which takes any localspace packet and blends the edges so that it will tile seamlessly when inserted into the world. In addition, it’s technically straightforward (though UI-wise somewhat challenging) to allow periodic noise and cellular textures, so that those generators will natively tile.
So that’s the plan, how are things progressing? Functionally, we’re almost at 100%. As always, the lagging element is the GUI — everything from displaying what is local and what isn’t, to making it illegal to cross-connect local or worldspace items except through designated devices, etc. There’s a lot to be done in that department yet, and as usual for GUI work, it’s slow going.
In other news…
A New Interpolation Technique
Something neat that I ran across earlier today and I thought was work a mention.
Here’s the scenario: You are using a texture atlas or something similar, where each color has an encoded meaning (perhaps RGB(0,255,0) is grass, and RGB(127,64,64) is mud). Or perhaps you’re trying to segment a world into regions.
When re-scaling this texture or placement map, traditional interpolation techniques give very bad outcomes — they introduce new intermediate values that are no longer correct in your texture atlas index, or that don’t map to your region correctly.
What you really want to do is have the output use only the exact same colors as the input. Of the common interpolation methods in broad use, only Nearest Neighbor does this. And it looks terrible.
Here’s a different way of doing it:
From left to right, we have:
- The 64×64 Voronoi-colored source texture
- #1 resampled to full size using nearest neighbor. Ugh.
- #1 resampled using “A New Technique“!
As you can see, we’re using smooth interpolation techniques to find the edge, but then snapping the output color (or height value..) to the nearest (in a least-squares sense) of the existing inputs. This provides a very neat “set-preserving” interpolation that is very useful for texture atlases.
I haven’t decided yet if this interpolation technique will make an appearance in WM; it seems simple but useful, so it has a strong chance.
5 replies on “What’s new on the Dev Branch”
Very exciting stuff, Stephen!
Sounds really nice. I was thinking that together with the “Placer” device it might go very well a “Bomber” device to spread “instances” of heightmaps and texturing devices over a predetermined area defined by the “Placer” device and/or maybe using an alpha map for placement inside the “Bomber”. Have to say WM is developing really nice.
Hi Takulas,
Absolutely — these are good ideas. I would probably make the “Placing” and “Bombing” be two different methods of operation in the same device rather than separate devices, but I do like the idea of allowing a mask for placement; the “bomber” would be very very similar to the current probability device, but outputting actual results rather than placement data.
Thanks for your answer Remnant. Yes indeed, like the probability device, with a similar behavior. Do you think it would be possible to control the amount of instances with a min/max value inputs? And if I want a precise number I will set the same integer values for both min and max? I also think that controlling the rotation and scale of the instances will be a nice feature, not only with integers but also with greyscale bitmaps. Or even by using a slope selector. And if all this will be possible to do it with color maps not only heightfield data will be very powerful. And one last thought. Maybe using more than one source as input for the bomber, or a source folder inside the project directory, or I can manually set the amount of inputs and manually plug each bitmap/terrain source will give me even more freedom. Definitely, a good time to be a world machinist. 🙂
Takulas,
Coming back to this now, I think you might be right — I have decided to segregate the behavior of the tile and the scatter device. They share some commonalities but they are often used quite differently in practice so far that I’ve found, making them make more sense as distinct devices.
I like your idea of “variation” inputs, both for rotation/scale and for multiple data inputs.