commit 0e27f4cc94d8ea489a0447a1bd220ae9798268f0 Author: emamaker Date: Thu Jan 19 12:46:06 2023 +0100 Initial commit diff --git a/.domains b/.domains new file mode 100644 index 0000000..8e9a3e4 --- /dev/null +++ b/.domains @@ -0,0 +1,3 @@ +www.emamaker.com +emamaker.com +emamaker.codeberg.page diff --git a/atom.xml b/atom.xml new file mode 100644 index 0000000..fa26411 --- /dev/null +++ b/atom.xml @@ -0,0 +1,63 @@ + + + Atom feed + + + + https://emamaker.com + 2023-01-19T12:45:17+01:00 + + Developing a Voxel Engine + + /projects/voxelengine.html + 2023-01-06 23:07:22.301262025 +0100 + + + Google Meet Bot attends online lessons for me + + /projects/googlemeetbot.html + 2023-01-06 21:56:22.760129090 +0100 + + + MakerFaire Rome 2017 + + /events/makerfaire2017.html + 2023-01-05 23:12:11.151727127 +0100 + + + EmaMaker’s blog | Events + + /events/index.html + 2023-01-05 22:13:20.140865078 +0100 + + + EmaMaker’s Blog | Projects + + /projects/index.html + 2023-01-05 22:12:57.653996091 +0100 + + + Voxel notes + + /notes/voxel.html + 2023-01-04 03:07:46.913167282 +0100 + + + EmaMaker’s Blog + + /index.html + 2023-01-02 12:14:37.793859526 +0100 + + + SPQR Robotics Team + + /projects/spqr.html + 2023-01-02 12:09:01.573397744 +0100 + + + EmaMaker’s blog | Notes + + /notes/index.html + 2023-01-01 19:34:48.045143605 +0100 + + diff --git a/events/index.html b/events/index.html new file mode 100644 index 0000000..9afaf6a --- /dev/null +++ b/events/index.html @@ -0,0 +1,41 @@ + + + + + + + +EmaMaker’s blog | Events + + +

+ +

Report of events I take part in, or simply go to.

+ +

+ Author: EmaMaker + emamaker@tutanota.com +
+ This website is statically generated from markdown using rivet, + a static website generator written in POSIX compliant sh by my dear friend Alessandro Mauri. Check him out! +
+ This website is hosted on Codeberg Pages. + + + +MakerFaire Rome 2017 + + +

+ +

MakerFaire Rome 2017

+ +

MakerFaire 2017 and our project

+ +

The December of 2017 started with a beautiful experience: I took part, with some other friends and our parents, to the MakerFaire 2017. We had our own stand and we showed to the big public of the Faire our project. What was is about? It’s called 3DPacRobotMan and it’s a real-life version of the Pac-Man game. Pac-Man is a videogame that came out in the ‘80s and still today is very famous.

+ +

+Our version uses new technologies to make a funnier and cooperative version of the game:

+ +

The field is all made of laser-cut wood. On the underside, the field is divided into sections. Every section has a board that controls a group of reed sensors. This board communicates in SPI with a central shield, which takes count of the reed sensors activated under all the field, turning off the corresponding LEDs, mimicking the coins in the original game. +As in the original game, there are five characters: one is the Pac-Man and the others are the ghosts. The ghosts have to catch the Pac-Man, which has to escape from them. If the ghosts catch the Pac-Man they win, otherwise is the Pac-Man to win. Again, a reed sensor on the PacMan recognizes when the ghosts touch it. The robots are made using Arduino Uno modified Boards and remote controlled with Radio Frequences @2.4GHz.

+ +

I took care of the scenic (so to speak) part: a Raspberry Pi serial communicates with the field to let the players see the score, the highscore, and plays the game sounds.

+ +

Note as of 05 Jan 2023, as I’m porting this to the new website: Everything was made in Java Swing. This was the only language I knew at the time, and I admit it was pretty bad. Swing GUIs do not update if no callbacks are called, activated by user action. My workaround was to create a button with transparent background and no text on it, and I had a script moving the mouse and simulating left clicks (I do not remember if it was external, launching a script from the terminal or integrated in my Java program). +If I was to do it again today, I would make it in Processing: easy serial communication with arduino, no reason to do weird workarounds to update the gui, easy sound playing +Cherry on top, I actually lost the source code to this master piece of a program.

+ +

3d Pac Robot Man on ‘The MagPi’

+ +

Do you know the Raspberry Pi? It’s a credit-card sized computer, that you can buy for just 35$. +The Raspberry Pi Foundation has its official magazine, called “The MagPi”. I had the luck (and the guts to ask them) to speak with the Raspberry Pi Foundation guys at the MakerFaire 2017 and I told them about our project. +They liked it and they published and article about our project in the February 2018 Issue of the MagPi. Down here there are the photos of the two pages about our project, but you can always download it for free from The MagPi’s official website. I also have a mirror on this website, should the link be dead. + +

+ +

+ +

Hello, I’m Emanuele, and this is my website!

+ +

I like coding, electronics and robotics :)

+ +

I started messing around with LEGO Mindstorm when I was around 10, then I started using Arduino while in middle school. +While in high school, I studied industrial automation and had a chance to pursue my passion for robotics. I’m currently studying to get a bachelor degree in automation engineering. +In this little corner of the web I will write about my projects, ideas and notes on the stuff I think could be useful to others, or that I just feel like sharing.

+ +

I have never really fancied the use of social networks, I only ever had an Instagram account which is now quite abandoned. I currently only browse Reddit and YouTube to keep up with the stuff I like, via FOSS apps like Infinity and NewPipe.

+ +

I really like the style of HTML-and-CSS static websites, hence the simple style of this one. This website is statically generated from markdown using rivet, a static website generator written in POSIX compliant sh by my dear friend Alessandro Mauri. Check him out!

+ +

Enjoy!

+ +

Latest Posts

2023-01-06 - Developing a Voxel Engine

2023-01-06 - Google Meet Bot attends online lessons for me

2023-01-05 - MakerFaire Rome 2017

2023-01-04 - Voxel notes

2023-01-02 - SPQR Robotics Team

+ +

+ +

Here you can find a list of notes I take about the ideas I come up with. I take notes directly in markdown, which makes them easy t oconvert into html to be presented here.

+ +

+ +

Old voxel engine:

+ +

Data structure

+ +

Used 1d arrays for storing blocks in Chunks. This is good enough, 1d arrays are faster to poll than 3d arrays. Memory usage shouldn’t be that bad.

+ +

Used 3d arrays for storing chunks in the world, this is VERY VERY bad, there’s a lot of wasted memory. Each update loop the engine looked in a sphere around the player of radius RENDER DISTANCE and updated each chunk that needed it. Then each chunk, using a JME3 Abstract Control was updated each loop and the chunk was removed or added to the scene if needed. This infact created a constant usage of memory, but a limited world.

+ +

Save files

+ +

Saved and loaded from file by saving every single block, again very very bad. Could create up to GIGABYTES in save files

+ +

New voxel engine

+ +

Data Structure

+ +

Using interval trees to store blocks in Chunks, as suggested by 0fps and on reddit. Thought about using SVOs (Sparse Voxel Octrees) as described in the nvidia paper or even SVDAG (Sparse Voxel Direct Acyclic Graph) but they just don’t look like the right tool for job.

+ +

Chunks are then stored into an hashmap as they get created and destroyed. This ensured O(1) access to a Chunk and good memory usage, while not giving limits to the size of the world +Interval trees kinda give built-in memory compression like in Run length encoding, with O(log n) average and O(n) worst case time to add or remove nodes. I’m not really removing nodes right now when needed, and they tend to grow pretty large in memory footprint as of (15/08/2002).

+ +

Actually Interval Trees don’t really seem like the best tool for the job either, as they require a start and an end to an interval, while I just really need to know the start of the interval (like in Run Length encoding) representing a run of identical blocks, and assume that it will either continue until the end of there will be a new node in the tree representing the start of the new interval right after it. I will probably be better off using some kind of Binary Research Tree, storing a key-value pair where the key is the start of the run (interval) and the value is the type of block. Probably the best option is to use a Red-Black Tree instead of a plain Binary Research Tree. This is similar to what the reddit guy did, except he was using C++ IntervalMaps, which are implemented as Red-Black Trees

+ +

Update

+ +

I implemented IntervalMaps starting from Java’s java.util.TreeMaps, which are implemented as Red-Black Trees, and had a huge reduction in memory usage +improvement (down to 80-85 MB of memory from 400+). +For further compression, i think some kind of space-filling curve could compress the tree even further by better expressing local conglomerates of the same kind of blocks in the 3d-to-1d flatteing. By researching space-filling curves, on wikipedia, I’m lead to think that an Hilbert Curve is better than Morton curves or Morton ordering for my scope, although I’ve seen morton ordering used in big voxel engines projects. I will try both and check which one compresses better. +By researching 3D Hilbert curves, i stumbled upon this website, which brings to this other site for C implementations

+ +

Update 2

+ +

Implemented Hilbert Curves and re-run benchmarks on all branches and techniques used until now. I apparently had huge problems in my old benchmarks, because I reported very different numbers across all tests, even on stuff I haven’t touched in a while.

+ +

I tested these three techniques: +- Interval Trees, with my own (crappy in some ways) implementation, with nested iteration as a 3d-to-1d flattening +- Interval Maps, with nested iteration as a 3d-to-1d flattening +- Interval Maps, with hilbert curves

+ +

They all use chunk states instead of queues, as continously filling and empting queues was not making the garbage collector happy and some huge memory usage spikes could be seen in VisualVM

+ +

In the end, all the techniques seem to perform about equal in my base benchmark (creating a cube of render_distance*2 side, generated with arrayGenerateCorner. Cubical chunks with a side of 16 voxels), reporting:

+ +

RENDER_DISTANCE = 8

+ +

Chunk size 32 (just creating chunks, no world update)
+ + + + + + + + + + + + + + + + + + + + + + +
Type Normal Heap (used/allocated) After 1GC (used/allocated)
Interval Trees (nested iteration) 74/154 32/112
Interval Maps (space filling) 128/210 26/98

Chunk size 16 (normal world update loop)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + +

Type	Normal Heap (used/allocated)	After 1GC (used/allocated)
Interval Trees (nested iteration)	148/196	81/196
Interval Maps (space filling - Hilbert Bits 2)	100/193	59/193
Interval Maps (space filling - Hilbert Bits 4)	88/192	55/193

+ +

To be noted: +- IntervalTrees seem to have a less “spikey” use of ram, but that could be due to other causes rather than the data structure itself +- Using a spacefilling curve requires more calculations than nested iteration, but that can be optimized +- The manual GC call just cuts the allocated heap, as the used heap already falls on its own once chunk generation has finished

+ +

I honestly cannot explain myself how intervaltrees can have such a similar memory usage to intervalmaps. On one hand, I know that my implementation of intervaltrees lacks the removal of adjacent similar nodes, and that leaves a lot of unneeded nodes around. Maybe this could be better noted once block picking is added. As of right now, this situation doesn’t really occur. +On the other hand, java’s implementation of TreeMaps has some stuff that I don’t really need, and the memory size of the structure itself could be reduced if I were to reimplement it to better suit my needs.

+ +

Also I haven’t tested interval trees with a space filling curve, but I don’t think that would change much.

+ +

Ideas

+ +

I’m currently using greedy meshing to obtain a triangle mesh out of the interval tree, by first converting it into an array. It is possible that, by changing the function i use to flatten a 3d index into a 2d one, the interval tree could be used directly into the greedy meshing function without a preliminary conversion to an array. The use of an array could still be need for fast chunk generation though
If going with bigger chunks, probably it will be best to just transform the tree into an array past a certain height (meaning very different blocks)
At some point, chunks need to be unloaded from memory. This can be done in three stages:
+ +
1. Chunks within render distance are shown and eventual logic gets updated
2. Chunks little outside of render distance are show but no logic gets update (what about LODs?)
3. Chunks that havebeen far from render distance for a short time are kept in a separate hashmap with just the deltas stored. After enough time has passed, they get dumped to the HDD and completely unloaded from memory
+ +
This method makes an assumption on chunk structure, such that generation is done at runtime and only modifications are permanently stored. This also means that generation data and modification data are stored in two different places, possibly using two different trees, a tree and an array, or something else
SVDAGs look like an interesting structure to look more deeply into and try to implement in some way. Maybe textures will be difficult to implement, but they would probably give access to some non-cubical blocks, by making them up of blocks smaller that the 1-Unit size decided for a single voxel

+ +