Trying to map a 2d array into a disk

No Mechaenetia make me sad, so i decided to figure out. How hard can it be to map a 2d array into a Disk. Answer: Very hard

Anyways so to to make this i had to rewatch a video on making minetest into a torus some times and mix some values and figure out some constants over and over again. but i think i have a ok method now.
Dont mind that its circles(i am too lazy to connect squares)

you can find this project at this github url, though i dont recommend using any of this code as it sucks and the math is barely right

5 Likes

some more progress later and ive made this


the weird chunks is because i just rotate a square texture without moving the vertexes to go into each other

i have 3 things that i can do next.

  1. fix the math(its duct tape together, and i dont know math)
  2. fix the vertexes together(dont wanna, and never done shaders before)
  3. make a donut(oh hell naw)

basically im to lazy to improve this anymore

2 Likes

Mechaenetia is probably having Donut worlds.

Donut worlds? How hard can it be to make donut worlds? know what, ill make a donut world thingy, and as a matter of fact ill do the 2D version which should be much easier, this shouldnt take more than a couple of hours. ¯_(ツ)_/¯

So yeah, im back. and ive slightly made my algoritm a little better. While i still dont know why it works, it doesnt feel duct tape together anymore, very few constant numbers and if it is, it is in places where it makes sense. For example

x:(x as f32 *2.0 /ARRX as f32 -1.0) * std::f32::consts::PI

the (x as f32 *2.0 /ARRX as f32 -1.0) is there to reduce the lenght down to -1 to 1 no matter the size BUT. Why do i multiply by pi, I dont know, but i have a theory, you see the X is the circumfourense of the world, so maybe it just works that way since then ill map from -PI to PI, and would you look at that computers calculate Rotations from 0 to 2PI, which is the same length as what i multiply, i suspect why this works.

Suddenly this

Became this

now, my height mapping algorythm looks like this

y: (y as f32 - ARRY as f32)/12.0

the twelve is there just simply because my boxes wont connect if i dont. like this


the fix is simple, just force them close enough together. This should be made automatic with some algorithm, but i dont know of it and 12 works wonderously for now,

you might wonder, why dont i force this between -1 to 1.

simple reason actually, i want it to go on infinity deep in. if i try to do it in a more proper way by normalising it beetwen -1 and 1, i get this.


while this keeps the correct aspect ratio when i go in, which is the most importan property.
Id also have to unhardcode that number 12, because when i increase the amount of boxes it gets more dense. as can be seen here

now if you ask me what is easiest, make an algorythm that makes a more correct algorithm work, or just allow the boxes to naturally shrink in the void with some hardcoded number.

Note that both ways look excatly the same.

Obviusly im just gonna hardcode.

Now to the most important piece of this code. The above just prepares it for this step.

    			let mut worlds_complex = Complex{re:box_world[x][y].y, im:box_world[x][y].x};
    			worlds_complex = Complex::exp(worlds_complex);
				let node_x = worlds_complex.re;
				let node_y = worlds_complex.im;

i dont expect you do get this, honestly i still dont. but ill try explain it to you.

So basically

let mut worlds_complex = Complex{re:box_world[x][y].y, im:box_world[x][y].x};
this just turns the X and Y position into their imaginary counterpart, prework for the next part.

worlds_complex = Complex::exp(worlds_complex);
This is the heart of my algorithm and also the part i understand least of. basically since complex math is done on a 2d grid, math just works differently there. Nah but for real, the limit of what i know is that i transform it with EXP, which is taking e^x, which i didnt know for a long time btw. The reason i know that this is important is that EXP maintains correct aspect ratio no matter what.
all my math is taken from this video btw, go watch it its great.

now

let node_x = worlds_complex.re;
let node_y = worlds_complex.im;

isnt really that importan since it just takes the imaginary and real part into X and Y, unnecacary but i do it for clarity.

good, you have done this, but oh no, why is it just a tiny dot in the middle of the screen?
image
well you see, everything has been normalised. so everything ranges from -1 to 1. to fix this you have to options, either scale the Y with something like this

re:box_world[x][y].y + world_offset_height

which can work, but remember this goes right into an exponential function, so things shrink and grow pretty fast. value of 7 you might see the entire world, but at 10 you see nothing as youre inside the hole within. or the other way, by scaling the blocks directly.

let node_x = worlds_complex.re * radius;
let node_y = worlds_complex.im * radius;

the benefit of doing it this way is that if the radius = 100, the world will be 200 pixels big. quite simple.
though the downside is that when you zoom into the world you will eventually stop, even if the world is much deeper. this is because of something known as floating point inacurasy. the EXP function grows extremely fast big, which is bad for us since floating numbers though can be immense have a limit. But the

re:box_world[x][y].y + world_offset_height

method bypasses this since its doing the tranformation before the EXP function. Which means, that we avoid reaching insane values for what we see, and is interested in. NICE

This is basically the gist of it and i hope this has been useful to any idiot with similar ideas to me

and yes the source code can be found at: GitHub - Fyrstikkeske/disktest: insanium

i have some ideas about collisions and stuff, this shouldnt be too hard since i can do the collisions in the 2d grid before i turn it into a torus and things should behave similar. which is great since then the edges while looking ugly doesnt affect the program at all

3 Likes

trust me, this is important to my program

2 Likes

soooo, i dont really know where to start. So much has been added since last time, so ill just do a list to start off.

  • world size can be customised as much you want without problems. just dont go smaller than 3 on length
  • Chunking is implemented, this means that no matter the world size, it will only store the closest chunks in memory. Saving much ram and processing power.
  • simple terrain generation based on math
  • a player we can follow
  • Collisions, yes you can collide with the world
  • Placing and removing blocks.
  • saving the world

honestly, dont really know how to make this as i’ve forgotten 90% of how the code works

3 Likes

Insane progress, waiting u to add ore processing xd :laughing:

2 Likes

I remember one idea to a game(like 3 years ago) , that uses terrain like this. I think it will be interesting to listen, so i tell u about it. It had to be a evolution game like spore, with multiple planets and only multiplayer. Evolution had to work in the way of adding really small changes over and over, if u want to make something new. Creatures have brain, that can handle info about how to live(it got it by players that play this type of creature, i know its really hard to implement). Creating a technology in game had to be very hard, because u need to create a thing with everything needed to use tools, to build and blah blah… But u didnt have to do this. U could make space giant panda that harvests planets or anything cool, like bio-spaceships. Thanks for reading it!

2 Likes

Oh nice, though I would change the Stone Texture to be less white and more gray.

2 Likes

evolution like Spore does it would definetly fall out of the games scope, but maybe something much simpler would be possible. and travelling to other planets is 100% something that will be added

2 Likes

Would liquids be added? Like molten liquid in the centre of the planet…

2 Likes

maybe, if i am too add a molten liquid in the centre of the planet it would probably be a circle and you would place some kind of extraction device on the bedrock. this is just a limitation of the algorythm. but water and lava is something i want to do eventually(a long time till)

2 Likes

on limitations, this character is exactly 20 blocks tall, and is exactly inside of the blocks. But then you might wonder why is the blocks above him a little away and the blocks under a little inside. after a little thinking i figured it out. You see due to turning the world into a sphere, the blocks above his middle point are slightly larger and reverse under. This causes length to also contract and expand. this could be fixed by putting the transformation code into the fragment shader as it would then transform each pixel inside the image instead of making the image larger. Fortunatly it isnt really necesarry as a bigger world also makes the artifacts smaller

A planet the size of 20 chunks

200 chunks size planet

2 Likes

Can someone pull requests to repository if he want?(Like me)

2 Likes

Hmmm… Rust learning speedrun for mecha modding and this xd

2 Likes

Yea, there is no problem with that. github can be found here: GitHub - Fyrstikkeske/disktest: insanium

but be warned, the code is a cognitohazard.

2 Likes

I love doing this type of code in python. I remember… Emm, if u read this code ull die, so i wont say anything xd

2 Likes

Ahh… I have a headache after reding guides for rust. It a LOT harder than python. Like everything. But ill continue, because why not? I think ill try to make a simple text game with 2d array moving about slime with no eyes to gwt better in rust, wish me luck :four_leaf_clover:

2 Likes

good luck, rust is heavy in the start but it will become easier after a lot of pain i can promise

2 Likes

hotbar finally

2 Likes

Hmmm, i already was thinking about pickaxes in a code when i read it. But then i said: bro, this game has no inv and things, how it could have pickaxe, it must mean something another lol. Now i understood :wink:

2 Likes