Game of Life 3D WIP

[Brandon502]

2D functionality still works as intended. Full 3D may be working correctly. Hollow cubes are not working correctly.

[Brandon502]

Goal for hollow cubes would like like a smaller version of this: https://www.youtube.com/watch?v=2XIph-EzBaY. Currently hollow cubes like human sized cube are treated like full cubes with the middle not shown. Because of that memory foot print is much bigger than needed. HSC is ~21x21x21 bits of memory for cells/futureCells instead of ~21x21x5.

[Brandon502]

@ewowi I can't think of a way to project onto a cube like you mentioned, but two ways that may not be ideal but I know would work would be something like this.

for (int x = 0; x < leds.size.x; x++) for (int y = 0; y < leds.size.y; y++) for (int z = 0; z < leds.size.z; z++) {
    if leds.isVirtual(x,y,z) continue;
}

for (int led = 0; led < numLeds; led++) {
    pos = led.getPos();
}

The first option would be easiest to implement into the game logic if it were a thing. Second option I can see being useful for other effects. Not sure if either of these are viable options though.

[Brandon502]

MazeRule.mp4

Messed around with the available control options to allow a text input to change the rule set. Tons of different possibilities. https://conwaylife.com/wiki/List_of_Life-like_rules long list of known rule sets here. Video shows maze like patterns being created by the rule set.

[ewowi]

two ways:

• leds.isVirtual: that would be easy to implement.
  • use projection=None
  • check Fixture::projectAndMap(). There the mappingTable is build
  • mappingTable is a vector of PhysMap
  • PhysMap contains a vector indexes of physical leds if they exist OR! a color if no physical leds exist, in that case color is a placeholder used for getPixelColor.
  • PhysMap currently is 8 bytes !! (+ the length of the indexes vector) I wanted to make a union of it and expected it to be 5 bytes then but that didn't work (WIP). So with a cube of 2000 pixels this is a huge memory foodprint, but still it works (if 5 bytes then still huge but 40% smaller...)
  • implementing isVirtual would just check if (!leds.mappingTable[XYZ(x,y,z)].indexes)
  • I would consider giving it another name as leds is all virtual and ledsP is all physical. Maybe isMapped?
  • Note that Coord3D struct is very handy to deal with x,y,z

[ewowi]

text input to change the rule set: that opens Pandora's box 😱

Maze patterns are very nice!!!

Why not use initSelect and add all the texts in the options so it will be a dropdown?

[ewowi]

Regarding blending: I now just blend the new color with the already existing color. Maybe this blending should only be done if the existing color is not black. If it is black it will not blend but override - I will test that today ;-)

Update: that didn't help as also gol sets pixels which needs to be blackened later ... WIP

[ewowi]

Made a few minor changes in main branch.

I was testing how fast it goes if pauseFrames check was removed and it did not go as fast as it used to be in MM, could also be because of StarLeds ??? (I need to test in MM later).
It is nice for development to have a super fast GOL so you can quickly see how things evolve - WIP

[ewowi]

Added isMapped in 7094e37

[Brandon502]

text input to change the rule set: that opens Pandora's box 😱

You don't like a text input with no validation/sanitation?! I mainly just added it for testing, I've never played around with alternate rulesets before. With a string there are 1 million+ different possible rule sets. If I keep that option around a drop down of a select few would definitely be more user friendly.

I have noticed performance seems worse than WLED currently. I've been focused on trying to get 3D to work properly before diving into performance optimization.

I tested out isMapped... I don't think it is working correctly? Unless I'm misunderstanding it. I added
ppf("x: %d, y: %d, z: %d isMapped: %d\n", x, y, z, leds.isMapped(leds.XYZ(x,y,z))); into the main loop. When using None projection on the default cube box fixture I get this printout:

x: 5, y: 6, z: 0 isMapped: 1
x: 5, y: 6, z: 1 isMapped: 0
x: 5, y: 6, z: 2 isMapped: 1
x: 5, y: 6, z: 3 isMapped: 1
x: 5, y: 6, z: 4 isMapped: 1
x: 5, y: 6, z: 5 isMapped: 1
x: 5, y: 6, z: 6 isMapped: 1
x: 5, y: 6, z: 7 isMapped: 1
x: 5, y: 6, z: 8 isMapped: 1
x: 5, y: 6, z: 9 isMapped: 1

Looking at the f_cubebox.json file only [50,60,0] and [50,60,90] are listed. So shouldn't isMapped only return 1 for 5,6,0 and 5,6,9?

[ewowi]

rulesets: I think I didn't look to closely, I just thought if you enter random text, how can the code make something out of it. I am away from home and only have my laptop so don't take my answers too seriously as I did not have the time to look closely.
Same applies for isMapped, I figured out it should work but didn't test it in a real situation. Coming Tuesday I have more time to take a closer look to things.
One thing you could look at is unsigned8 dim() {return _2D;} in GameOfLife, in this case it will map a 2D effect to a 3D fixture which is still work in progress. If you change this to return _3D it will become a 3D effect and mapping to a 3D fixture will be 1:1

[Brandon502]

@ewowi no worries, I'm in no rush, just throwing around random ideas that I've wanted to code in the past, but never got around to it.

rulesets: ....

I didn't push that change yet. Like you said it is pretty easy to break and it is a bit buggy at startup. My code right now is a mess lol, have so many random changes/print statements commented out.

unsigned8 dim() {return _2D;} in GameOfLife,

Gave this a shot and isMapped seemed to always return 1.

For blending here is my take on it:

blending.mp4

Set it up to only blend dying cells. So now the background is a faded version of previous values. Not sure if this is similar to what you were going for or not. Looks nice in the virtual preview may look worse on a real setup, just need to remap the values on the slider as most are not needed.

Second blend option:
https://github.com/MoonModules/StarLeds/assets/105077712/9be97d22-ef72-4630-8540-315bc8173fe8

[ewowi]

This is current mapping of GOL (2D) to HSC (3D)

It's cheating but looks a bit nice ;-)

Screen.Recording.2024-05-18.at.23.33.36.mov

@Brandon502 , give me a ping if I can test and merge your PR

[Brandon502]

@ewowi feel free to test and play around with it. You can merge if you'd like, but that string input is still in my latest commit. It can be buggy at boot though. I like messing around with it too much to remove it right now. I can push a version without it if you'd prefer that.

[ewowi]

@Brandon502 , good idea to push a version without string input first 👍

[Brandon502]

@ewowi Pushed a version without the ruleset options. I'll have to figure out a better way to re add that option back later.

I quickly tested your isMapped changes and they seem to work how I expected when the Default projection is used. When I switch to None they seem to show the wrong values. Sorry if I'm leading you down a rabbit hole.

[ewowi]

Hi @Brandon502 , I checked your latest commit, without ruleString, it works fine.

• I think coord_to_index({x,y,z}, leds.size) is the same as XYZ(x,y,z) (or XYZNoSpin). True?
• I am a bit hesitant to specify it as a 3D effect already, but if you are confident it works fine on 2D fixtures and will work on 3D we can merge.

[Brandon502]

Hi @Brandon502 , I checked your latest commit, without ruleString, it works fine.

I think coord_to_index({x,y,z}, leds.size) is the same as XYZ(x,y,z) (or XYZNoSpin). True?

Yep, didn't realize. I can swap those to XYZNoSpin later today.

I am a bit hesitant to specify it as a 3D effect already, but if you are confident it works fine on 2D fixtures and will work on 3D we can merge.

Definitely works great for 2D currently, fully 3D cubes might be working correctly. I would have to create a test case and run through it slowly since I don't know 3D patterns. Hollow cubes aren't quite there yet. I'm pretty confident I can get them running on smaller cubes. But for large/HSC I won't be able to use None mapping. Maybe there is a way for it to work with default? I'll have to start looking into that later.

[ewowi]

Merged and replaced coord_to_index with XYZ() (not nospin as we want to be able to spin gol as well 🤓)

[Brandon502]

Merged and replaced coord_to_index with XYZ() (not nospin as we want to be able to spin gol as well 🤓)

It actually works while spinning? That's crazy if it does, can't play with it for a bit. I'm struggling to wrap my head around 3rd dimension and projections... now you're spinning things.

If I commit anymore changes will this PR automatically reopen since it was merged, or do I need to do anything different?

[ewowi]

Haha, yes it does, tilt, pan and/or roll 🤷‍♂️, it is one of the projections currently implemented - the projections is similar to expand1D in WLED and resembles maybe the pinWheel you made for WLED.

But this rotation not really making GOL more beautiful
Multiply mirror is nice though:

Screen.Recording.2024-05-19.at.21.11.42.mov

I guess for GOL 3D the projection = default (I think I said none in the past, but I meant default) is the best to start with.
Also still thinking isMapped should work for that ... (but will really look at this later this week).

Also note that we are doing bleeding edge stuff here. Idea in StarLeds is that Effects itself has little to no notion of in what context they are used - check also 'orthogonality' in https://ewowi.github.io/StarDocs/StarBase/StandardsAndGuidelines/ .

Also until now, Effects are either 1D, 2D or 3D as it evolves from the way effects are setup in WLED. We are now trying to make GOL as an effect which runs 'natively' on both 2D and 3D (for the first time natively, until now all effects work in any dimension in StarLeds, but projected: 1D/2D/3D effect to 1D/2D/3D fixture) - running natively was something I hoped we could do with more / all effects in the future - hope this makes sense ;-)

Finally see also here about speed: #3 - another idea to make the speed slider more predictable.

So a lot to work on, and like I said - bleeding edge stuff ;-) - let's do it little step by little step

I think if you commit more changes the PR will reopen indeed

[Brandon502]

Hey @ewowi.... It's so close to working properly. I have to limit HSC to 15x15x15 to not throw >4096 errors.

15cubeGoL.mp4

Regarding pan/tilt/roll. I mainly tested roll since that's just spinning. Using XYZ for setting cell values as alive or dead in the bitmap is breaking the effect. Using NoSpin for those "fixes" it. But it breaks finding the parent colors so it fades away quickly sometimes. I'll keep using just XYZ for now until I can fix getting colors while spinning.

I'll look into changing up the speed slider at some point, I mainly just max it out unless I'm making sure something isn't broken.

Btw, there seems to be a single random pixel that is "misaligned" with the others on HSC

[Brandon502]

Glider traversing cubeBox. Seems to explode at a point so something is broken. But still it's progress!

BoxGlider.mp4

Full GoL on cubeBox
https://github.com/MoonModules/StarLeds/assets/105077712/88c9fc04-e0dd-439c-b59e-534ad5a8bdfe

The glider breaking bug is really strange... When I swap to 10x10x10 HSC and back to cubeBox it no longer breaks and continues forever. I don't even know where to start figuring out why.

Performance is still not amazing. ~23fps on 32x32. I took out crc/repeat detection and dominant color tracking and it didn't change at all. I'm not sure what could be optimized. Edit: never mind, I was using a single pin and that tanked it. 4 pins is ~53fps. ~59fps without fastled show check

Pushed the changes to my branch. Didn't seem to reopen this PR automatically unfortunately.

[ewowi]

Wow, this is impressive!!!!

I see this (with your repo setup as remote):

Is GoL 3D Hollow Cube WIP your latest commit? It's not listed in / as PR, but I can merge it in main if you want, or I can give you direct access to MoonModules/StarLeds if you like. Then you can make a GOL branch there directly and merge to main whenever you feel next steps are ready (still happy to review if needed).

I was thinking, the Effect class has also setup(Leds &leds) implemented, we could maybe think of a way that setup 'probes' what fixture is in place, identify adjacent planes and the loop function acts on that. But probably needs memory to store that information, which increase the footprint of the effect maybe too much?

And I was also thinking - as you also made pinWheel - the projection stuff is inspired by expand1D (combined with the other things in segments - mirror/reverse etc) but then 'expandsAnyD' - most intelligence is in Fixture::projectAndMap(). If you have ideas to improve that - you are most welcome to help here.

Are you on discord BTW? Maybe I've asked before - but forgot your discord name then ;-)

[Brandon502]

Hey @ewowi. That is my latest commit. Definitely not ready to merge though. It works perfectly (outside of a weird bug) on smaller cubes, X * Y *Z <4096 maybe. Once you go over isMapped stops functioning. So HSC is broken on that commit. I can fake it like before only using isMapped on smaller cubes, but I'd like to find a method that works on large ones.

If the effect knew it was a box with 6 panels it could reduce memory size needed. But I think it would make the neighbor logic of finding which panel to jump to on the edges very complicated. Like if you have 6 8x8 panels. When you're looking at panel 1 say in the front. (0,7) would need to look at the right panel (0,0) and top panel (7,7) among others. Maybe you know an easier way? Right now it just checks all 26 3D neighbors which was easy to add.

I looked at the projection code briefly before. I somewhat understand 1D projected to 2D and 3D. Once you start projecting 2D to 3D I'll have to look over way more. I think Pinwheel could work in a few different ways, I may play around with it at some point.

I'll dm you on discord.

[ewowi]

4096 is the limit until PhysMap is optimized. After that I hope on 8192

I agree on the complications as you describe it. I just wanted to point out the possibility to do something in setup and now I have no clue of a better way yet

[ewowi]

Tested latest commit (>=32x32 2D or 16x16x16 cubeBox)

1. Creating a 16x16x16 cubeBox is a hell of a job -> todo is add the size as a parameter to prefill the fixture generator table.
   Workaround is change the code:

Note: I first tried 16 but that generates an 18x18x18 sized fixture, which caused dev > 4096 errors (I still need to fix) so worked around this by generating length 14 cube

2. SysModInstances crashes sometimes
   This is temporary fix (but will be solved in next update of StarBase / Merge into StarLeds

3. Looks: what is better, to have black dots not displayed or displayed as black dots?

No black dots:

Screen.Recording.2024-05-21.at.17.53.45.mov

Black dots:

Screen.Recording.2024-05-21.at.17.56.37.mov

[Brandon502]

Using the fixture generator took me a while to create the current max size allowed. Wish I thought about editing the code. If you're able to up PhysMap to allow 8192 we could go up to 20x20 cubeBox, unfortunately HSC is slightly too big. You'd have to not use the last couple rows at the bottom to make it work which would still look nice.

No black dots looks pretty good. I swapped to nyan (I think) theme so the dots were easier to see for debugging. If I had to pick one I would probably pick dots just so I can make sure things are working easier. A toggle would be great though. Would also be interesting to see what it would look like without transparent walls. Would be able to see what it would look like with panels in person.

I've been slowly rewriting a lot of the code to make it cleaner and easier to understand. I added a isWithin method to the coord3D struct, that tells you if the coord are within 0,0,0 and rhs. I may change this to isOutOfBounds though. Also thought about having a wrap method to wrap the coord back into the rhs. Not sure if any of these would be helpful in other effects yet or not.

Would changing up the bit array code be a good idea? Thought about creating a struct to make indexing and changing bits much easier.

[Brandon502]

@ewowi for rotating effects have you looked into rotating by skewing? It prevents pixels from being lost on certain angles, may look better? https://www.youtube.com/watch?v=1LCEiVDHJmc I learned it from this.

[ewowi]

I need to give it some more thought also to make sure O am not mixing up virtual and physical. Physical pixels are now bound to 4096 (HSC has only 2000), but virtual is unlimited now until it crashes 🙂 . But crashes earlier because of the large physMap struct.
In general, go ahead with everything you think is an improvement 👍. Some things should end up in StarBase though, like Coord3D modifications, but that can be done manually later

[ewowi]

Rotating by skewing is interesting, never thought of that (cc @softhack007)