Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Valid_Dark]

Recursive
I cant figure out whats causing the lines, I can PM you some of the source if you want to take a look.

[Skyrunner]

Pastebin it to me, here. Set the exposure to "unlisted" from "public", and enable C++ coloring.

Also, I can make no guarantees, because I've never actually authored a diamond square algorithm, just ported one from C#.

[MagmaMcFry]

Valid, that looks a lot like a midpoint displacement algorithm rather than diamond-square. Sure you diamond-square'd?

[Skyrunner]

I think it's a midpoint displacement, from the source code. He only does the square step, and not the diamond step, hence the square artifacts...

[Valid_Dark]

Then either you didn't understand what you were looking at, or you don't know Diamond Square,
I do both the diamond and the square step,  I have an idea as to whats causing the issue, going to try to fix it now.

[Skyrunner]

I probably didn't understand what I looked at. Like I said, not a diamond-square guru. Dx

Forgot to cross-post this; o_O

Genetic simulation on a large scale.

Spoiler: Graphs (click to show/hide)

10000 entities, 100 steps

50000 entities, 2000 steps

10000 entities, 5000 steps

Allele distributions, normal!


Six cores running little worlds, computer making whirring noises >.>
Also, rest of the computer's programs all shunted onto two cores. It's getting crowded.


Took so long just for this. o_O

My program to simulate polygenes (also known as pretty much every gene in existence) is not only working, but it works on multiple threads at the same time. To be exact, it caps out six of my eight cores, with a total of 75% CPU usage. This confirms that the mendel module for polygenes works as expected, and also has genetic drift towards diverging.
The next step it to find a way to make it bloody massive.
... or not. =_= It'll probably take so long.
The only problem here is that the complexity is probably O(n²) for entities and I can't do anything about it. For time, it's linear.

[Valid_Dark]

I can NOT figure out this line issue, if any of you are experienced with diamond-square algorithms, I'd appreciate it if you could give me a hand.
spent all day trying to fix it and have made no progress.
going to try implementing a smoothing function and see if that makes things a bit smoother, It's basically taking the duct tape route but if it works it works.

[alway]

Where's the link to the code?

Though even without it, it looks like you aren't doing the random offset on the diamond step. each of the midpoints being generated needs to have a random component, not just the midpoints in the centers. Because that looks exactly like my diamond square implementation when I disable the random offset on the diamond midpoints while leaving the offset on the square midpoints.

And if you got the algorithm from wikipedia, it doesn't surprise me. Damn thing is written in the most misleading way possible, to the point where it's basically just wrong.

[Valid_Dark]

no, I use a random offset on the diamond step, My issue is that I initialize the boarder at 0, I'm working on a fix for it, I'm pretty sure I'm on the right track.

Edited out code, was hesitant about posting it in the first place. None of the suggestions anyone gave were correct in the least.

Spoiler: "Recent image" (click to show/hide)

Spoiler: "Welcome to the Island of Demon Mountain (click to show/hide)

I'm rather happy with the way the mountains have turned out.

Don't ask about the symmetry. (The Symmetry wasn't caused by the Tr function, it was caused by a Smoothing function.)

[MagmaMcFry]

Yep, that's a perfectly serviceable midpoint displacement algorithm you have right there. 
(Except for the symmetry part, which happens because you reuse the Tr value.)

[alway]

First thing I notice: terrible naming conventions. It's no wonder you can't figure out what's wrong. >_>

Second thing: you are using Tr for all your diamond offsets. That Tr value is the same for all offsets on the same layer. It should be randomized after each use.

Third thing: Tr is being based on a value 'Coastlines.' What that value is set to, I haven't the foggiest, but I do know it isn't changing during that functions execution. Which means the offset is relatively tiny on the initial layers, and relatively large on the later layers. For proper use, it should be multiplied based on which layer of recursion it takes place in. It's why your offsets appear so wrong on the diamond stage, as well as why you've got so much high-frequency noise on the small scale.

Re-randomize that Tr value each time you use it, then multiply it by R:

Code: [Select]

if (((x2>(WORLD_SIZE_X/16))&&(x2<(WORLD_SIZE_X-(WORLD_SIZE_X/16)))) && ((world[x1][y1].elevation == 0) || ( world[x2][y1].elevation == 0 )))
        temp = (world[x1][y1].elevation + world[x2][y1].elevation) + Tr * R;
        else
        temp = ((world[x1][y1].elevation + world[x2][y1].elevation) / 2) + Tr * R;
        if(temp < 0)
            world[midx][y1].elevation = 0;
        else
            world[midx][y1].elevation = temp;
Tr = (rand()%Coastlines)-(Coastlines/2);
Do that and all but the first thing will be solved (assuming Coastlines is set to a good value; it may or may not need to be increased/decreased for it to look good; though removing it and replacing it with a constant may be better)

[Valid_Dark]

the whole Tr things was what I most recently added, it's not the issue causing the lines, Even when it was a random number generated each time, that was multiplied based on which layer of recursion it takes place in (yes, I've had it set up that way before, and changed it to this far inferior/superior way), there were still issues with the lines.

I didn't realized that Tr wasn't being randomized each time when I changed it to that, and since I made that change i've been too busy looking at the cool stuff it's been outputting to make any changes, but I would have realized it sooner or later.

and my naming conventions make sense to me, the only things with bad names are the things that are obvious what they are/do.

[alway]

What is Coastlines equal to?
Because it needs to equal the same values as are used in r. If it doesn't, you get artifacts.
    int r = ((rand()%(256*50))-A*50);
    int Tr = (rand()%Coastlines)-(Coastlines/2);
should be
    int r = ((rand()%(256*50))-A*50);
    int Tr = (rand()%(256*50))-(128*50);

[Valid_Dark]

-removed by author-

[alway]

As I said, that's the result of the Tr value being relatively high for the small stuff, and low for the big stuff; in short, generating high-frequency noise. What you should really do (which is the way diamond-square is supposed to be done) is more like this:

Code: [Select]

void DiamondSquare(int x1, int x2, int y1, int y2, int displacementModifier)
{
    ...stuff...
    int displacement = rand()%displacementModifier - displacementModifier/2;
    world[midx][midy].elevation = A + displacement);   //square displacement
    ...stuff...
    displacement = rand()%displacementModifier - displacementModifier/2;
    temp = ((world[x1][y1].elevation + world[x2][y1].elevation) / 2) + displacement;  //diamond displacement
    ...stuff....
    const float FREQUENCYMODIFIER = //some number between 0 and 1; closer to 1 will result in more noise at small scales, which seems to be what you want
    displacementModifier *= FREQUENCYMODIFIER;
    DiamondSquare(...stuff... , displacementModifier);
}
Basically displacementModifier determines how high the amplitude of the noise will be, FREQUENCYMODIFIER determines how rough it is. Low values result in it converging to 0 in few iterations, while closer to 1 results in it staying relatively high at small scales.