Trying to map a 2d array into a disk

Forums Fun Stuff
21

Ok, i have reached the point where my math skills no longer can support this project. and saying enough is enough, isn’t something to be afraid of.

the main problem lies within how planets are done. their size can basically be said to be e^planet x size. now if you dont know e^x is a stupid fast function, and world sizes are stupid big. approaching the limit of floating point numbers stupid² fast.

normally this wouldnt be this big of a problem since you can map everything around the player. but my code doesnt handle this case for travelling beetwen planets, and thats where the project is stumped right now.

fixing this would require a refactor so big that i might as well remake everything, and honestly i don’t want to do that.
so, that’s why this project wont develop anymore. as for the reason i post that here is so that it wont end up in a mechaenetia like situation where ill say ill develop on it but dont.

no matter, here is what ive learned that might help mechaenetia:
Handle travelling between planets as soon as possible. that stuff will bite you in the ass if you dont prepare.
make sure you start from the top of the planet and go inn, this avoids planets having the size of a googol but, this is a point you need to be extremely vary off so you dont rewrite everything.
i guarantee many things will be rewritten with this system, especially since no one has done this before, so if you do go forward, be prepared for a lot of rewriting

im probably forgetting something. anyways good luck forward on mechaenetia. But be prepared its gonna be helloffa ride.

2 Likes
22

wazzup, im back from the dead. and currently in the progress of rewritting this into a more simple have everything within a giant struct program. which i personally dont like, BUT daimn it makes everything so much simpler. no matter, here is a tiny progress update

3 Likes
23

Good to know you’re back at it again, don’t give up :+1:

3 Likes
24

Nice to see more progress. Im thinking of writing simillar thing with hexa tiles in godot to play a little with planet physics

2 Likes
25

Minor topology thing: If you’re using hexagons for a spherical planet you must have 12 pentagons to add the necessary curvature. However, if you use tori, you can have all hexagons, because donuts have no curvature

3 Likes
26

finally bit the bullet and started with 3D.
progress is slow, i moved the codebase to vanilla C. This is the work of a couple of weeks

4 Likes
27

cool! But why use C?

3 Likes
28

to make absolutely sure its an information hazard xD

2 Likes
29

Basically boils down to not fighting the compiler and having maximum control over everything. pluss the C libraries that exist are quite nice

1 Like
30

In my experience fighting the compiler offten means that you are trying to do something stupid. (and many times its not easily visible that in fact you are wrong) And in the case that you know you are trying to do something correct that the compiler does not understand you can use unsafe code.

I would really miss higher level constructs that C does not know. Perhaps C++ would be more understandable. C++ at least has generics, namespaces, classes and other organizational stuff. C is great for low level code that is small enough and simple enough that you can handle everything yourself, but the same can be said about assembly.

Will you post the source somewhere?

3 Likes
31

Sure, here’s the source: GitHub - Fyrstikkeske/fyrraria
like any code i write, its all super in development and this is the first time im doing opengl so many things might be wrong, or just done in a bad way.

Now to the fighting the compiler. Rust is to strict, zig is to new and c++ is to bloated.

2 Likes
32

I looked at the code a liitle bit. I found this piece of code where you are setting the block type to air (at the top) and then doing it again (the last line I coppied) with some code in between that has no effect on the second place where its set to air. Sure, its not an error, it will not cause problems with the program but also its useless.

for (int blockiter = 0; blockiter < chunksize * chunksize * chunksize; blockiter++) {
        world[chunkiter][blockiter].type = air;

        // Calculate chunk coordinates
        int chunkx = chunkiter % Worldx;
        int chunky = (chunkiter / Worldx) % Worldy;
        int chunkz = chunkiter / (Worldx * Worldy);

        // Calculate local block coordinates within the chunk
        int localx = blockiter % chunksize;
        int localy = (blockiter / chunksize) % chunksize;
        int localz = blockiter / (chunksize * chunksize);

        // Calculate global coordinates
        int globalx = chunkx * chunksize + localx;
        int globaly = chunky * chunksize + localy;
        int globalz = chunkz * chunksize + localz;
        
        world[chunkiter][blockiter].type = air;
...

About your “Rust is too strict”, maybe you are just not strict enough :smiley:

2 Likes
33

thanks for finding that double insertion.

improved performance so bigger worlds can be made

4 Likes
34

So a friend asked what new happened in disktest, i told him i was struggling with rotations due to so much early prototyping stuff, which made the code hard to work with. But the day after his question just randomly popped into my thoughts. so i thought why not just try every combination until rotations finally worked. 3 hours of brute force later and we have this.

the 3d donut version is still being worked on, A new binary mesher has been added for chunks and lods are id say 20% done. theres a couple of issues yet to be figured out, but work is being done.

image
image808×628 158 KB

7 Likes
35

Nice! Good job!

If you ever want help with math just put it here I will try to help :smiley:

3 Likes
36

im not really good at working on the same codebase as other people(youve seen my spagetti first hand and survived), but math might work.

Now what im most having issues with at the moment regarding the 3d planets, is the artifacts coming from the curvature of the donut planet. blocks on the inner ring are much smaller than the outer ring. basically, theres 2 solutions, 1: make the worlds thin and long, this reduces the local curvature since its total is a constant i believe. 2: dynamically change the length of the world based on where the player is. This might also work due to there always being a select height of the world with minamal artifacts. Option 1 is the simplest personally since its the most bang for the buck when it comes to time to implement, and option being limited some other way. But Option 2 will be needed to make a decent build height.

This is the algorythm ive basically ended up with. The inputs are directly from their voxel map position.

Now, im not much of a math person so i dont know if there is a mapping with less artifacts. But from what i understand, there shouldnt be? but then again i reworked the 2d algorythms version 10 times until it worked like i wanted.

//Inputs
vec3 vertexposition;
float WorldXlength, WorldZlength;
// Normalize inputs
float u = aPos.x / gridX; // major angle around torus
float w = aPos.z / gridZ; // minor circle angle

// Angles
float theta = 2.0 * 3.1415926535 * u; // major angle
float phi   = 2.0 * 3.1415926535 * w; // minor angle

// Radii
float majorRadius = gridX / (2.0 * 3.1415926535); // donut center distance
float minorRadius = gridZ / (2.0 * 3.1415926535); // donut tube radius

float effective_r = minorRadius + aPos.y;

vec3 pos;
pos.x = (majorRadius + effective_r * cos(phi)) * cos(theta);
pos.y = (majorRadius + effective_r * cos(phi)) * sin(theta);
pos.z = effective_r * sin(phi);
2 Likes
37

i just remembered the one thing that ive struggled with. A proper AABB algorythm for looping worlds which does not create subdivisions of boxes to solve the edge cases. imagine the world should loop in that box. now the to rectangles should in theory touch and push each other. But normal AABB doesnt handle these cases. ive tried a few modifications, but only had succes by dividing the rectangles into multiple rectangles to handle edge cases.

if you find a algorithm which can properly handle looping worlds without making multiple rectangles, id be a huge help.

image
image744×501 2.93 KB

2 Likes
38

the greater than and less than operators do work well on a modulo basis without splitting the box itself.

2 Likes
39

can you explain it? When you deal with modular arithmetic you can not order numbers, less than or greater than makes no sense. Because modular arithmetic loops numbers, you take a piece of a number line and glue the ends together, then you can not say one number is less than the other, in a way all numbers will be less then all the other numbers (including the compared number) and also all number will be greater than all the other numbers. So for all numbers A and B, A < B and A > B at the same time and that is meaning less and useless.

3 Likes
40

I am not saying the thing you are saying
I am saying that you only need to check X > A and X < B, so if you check for
X>A and (if (B>M or B<A) then (X%M < B%M or X<M) else X<B)
it DOES work. (M is the boundary to modulo by)

(to be more clear, in your example you are comparing X to A twice, so its useless regardless of modulo as it can never return true ever…)

2 Likes