Jump to content

  • Log In with Google      Sign In   
  • Create Account

Wyrframe

Member Since 28 Jun 2000
Offline Last Active Yesterday, 05:12 PM

Posts I've Made

In Topic: Generating Provinces From A Map

19 June 2016 - 12:37 PM

For the slowness concern; when I write iterative generation algorithms like this, I usually allocate a block of ints twice the size of the map, and re-use it over and over as the process continues, sometimes as a doubly-linked list structure. Before the "grow" step I described, I'd initialize all elements to 0, and all unassigned land adjacent to assigned-province tiles into the list. After changing province assignment of a tile, I'd add all the adjacent, unassigned land to the list. This way, every pass I'm just walking the list of province-bordering tiles, not the entire map. You can tell if a tile is already in the list and doesn't need to be added, because one or both of its pointer indexes will be nonzero. The phase is done when the list is empty.

 

Once you add the Conquer phase, the blockiness of some provinces will start to disappear, especially if you make your initial seed chunks a little smaller.


In Topic: Generating Provinces From A Map

18 June 2016 - 09:32 AM

Here's an algorithm that might do what you want.

 

1) "Seed." Iterate over your map in small chunks, e.g. 6x6 tile/pixel chunks. In each chunk, randomly pick a tile inside. If it is land, assign it a new, unique province ID.

 

2) "Grow." Once you've done that for the whole map, iterate across the entire map repeatedly. For each tile that does not have an assigned province but is adjacent to at least one province, have it adopt the province of a random cardinally-adjacent tile (or any adjacent if you're using hexes). Repeat this process until you walk the map and find no unassigned tiles that have at least one assigned neighbours.

 

3) "Sweep." Remove all land that has no province assignment at all. These are any islands which you didn't hit during the seed step.

 

4) "Inspect." Walk the map and get data for every province. You'll want to be able to take a province ID and look up its total area (how many assigned tiles), a location inside its borders (any will do; top-left, original seed location, whatever), and any other data you want to track about them at this stage. You'll also want to generate an adjacency map at this time.

 

5) "Prune." You'll probably have some provinces too small for your purposes, which won't be able to grow in the next step. For each province under a size threshold which also has zero neighbours, turn it into water and discard the province.

 

6) "Conquer." At this point, the average size of a province is going to be around the 6x6 area (remember the chunk size, in 1?). But you'll have lots of variety in size and shape everywhere. They will all have grown into irregular, blobby shapes. Now what you should do is start fusing these micro-provinces together! Start randomly picking provinces from the bottom 25% or so of them when ranked by size, and have it merge with a random neighbour. Overwrite the neighbour's tile assignments with its conqueror's, union the adjacency sets, and re-insert the new larger province in the rankings. The wider the conqueror selection is, the more variety in final province sizes you'll have at the end.


In Topic: Help with UV mapping procedural game

14 June 2016 - 07:42 PM

For exclusively plane-aligned faces, yeah it's overkill. I had domes and arbitrary 2D CSG polygons extruded upwards into buildings to cope with.


In Topic: Help with UV mapping procedural game

14 June 2016 - 11:55 AM

Although it's highly dependent on art style, I've used an object-space trimapping technique to avoid U/V mapping on my procedural terrain and CSG buildings. Each "material texture" is actually three textures, for the XZ, XY, and YZ planes. In the pixel shader, I use object-space position and a (uniform) scaling parameter to sample each of the three textures, then use the object-space surface normal to slerp between the three samples.

 

Con: no texture alignment; it's only suitable for tiled or detail textures on static objects.

Con: is relatively quite expensive when applied mostly to planar-aligned geometry.

Pro: works on any geometry; with good texture selection, it looks like natural, carved, or poured material.

Pro: no mapping or stretching artefacts.


In Topic: HUD algorithms for glass HUD/MFD window

05 June 2016 - 09:58 AM

Just figure out what the elements you want are, and design them out on paper, and start working out how to generate shapes that depict that. A compass tape, for instance. You want vertical lines, of varying heights. Assume model-space 0,0 is the center of the tape, take as input the bearing and desired width (in degrees) to include notches for and let some parent function deal with the position and size of the tape on the HUD (by setting the modelview matrix appropriately).

 

You'll want to use the the fractional part of the bearing as a horizontal bias for the notches, and then generate several notch lines left and right of center, all of them offset by the bias. If you use integer modulo tests to determine whether to use a short or tall notch, you should probably add 360 to your bearing first, because most languages' modulo operator doesn't treat negative numbers correctly.

 

If you do it right, it should be configurable and controllable by *any* simulated data. You should be able to make a test viewer where you set the "flight" parameters in a GUI form using text boxes and numeric sliders, and see the resulting HUD rendered, without any simulated airplane ever being involved.


PARTNERS