AudiOrbits 2.3 Update for Wallpaper Engine to add 4 new fractals into the rotation

[ssaenger]

Edit: I accidentally added two features to this PR. My next comment describes the 2nd feature (spiral feature).

Added four new fractals

• The positive Barry Martin fractal
• The additive Barry Martin fractal
• The sinusoidal Barry Martin fractal
• The Gingerbread Man

Algorithms taken from https://www.jolinton.co.uk/Mathematics/Hopalong_Fractals/Text.pdf

This is my first time working with javascript. I am not sure how memory is handled in javascript. I am not sure if there is a time penalty accessing fields from an object over copying those fields to a local variable and manipulating the local variable. I also don't fully understand what the D - E parameters are responsible for, so I might not be using them optimally. The same patterns seem to keep on repeating. To hide this fact, maybe an orbital level could combine the four new fractal types.

Screenshots below are taken from Wallpaper Engine using only the 4 new fractals. Each screenshot doesn't necessarily match to a particular fractal type. Actual PR includes all 7 fractal types.

[ssaenger]

Oops, my spiral feature got attached to this PR. That commit rotates a sublevel a degree. It is adjustable from the UI.

Screenshot is with a spiral setting of 4 degrees. Allowable ranges are -180 to 180 degrees

[hexxone]

Hi @ssaenger! First of all thanks for your contribution, I really appreciate the work & dedication :) The new algorithms look good.

Unfortunately, the change you suggested was made to the "legacy" branch of the wallpaper, which I did not really plan to continue working on ^^ On the main branch, the entire code base has been rewritten. As mentioned elsewhere, unfortunately the main branch cannot be used in Wallpaper Engine yet, so if you really want to see these algorithms released on Steam, I could see this making sense. But ideally, we would just make the change to the "new" main branch ^^ Because adding this PR to the 2.3 branch would mean that I would effectively have 2 different versions to maintain. I am not sure if I want to go this way yet. Please give me some time to figure it out :)

The next month will be very stressful for me, so if I have not responded by mid-April, feel free to ping me again ^^ Until then, I hope I can come up with a good solution.

[ssaenger]

Thank you for creating this wonderful wallpaper in the first place.

I understand the implications of an update to a legacy branch on top of having a stressful month. I hope things get better next month.

I chose the 2.3 branch for a few reasons, but mainly to update the Wallpaper Engine version since that's how I discovered AudiOrbits. I hope Wallpaper Engine does eventually get updated to accept the new security requirements needed by 2.4+.

I'll await your decision next month. Let me know if you have any questions or want some help. :)

[ssaenger]

Hey I hope things are going well for you. It's a bit early to phone in, but I have some extra development for your consideration. I went a bit overboard and made lot of modification to the 2.3 branch.

• Added 40 new fractal/attractor oribital designs. Most orbitals can be further customized through the algorithm parms.
• Made each orbital selectable from UI via slider control to set the percentage that each orbital should run
• Updated wewwa.js to fix some bugs and added new features, such as specifying granularity of slider controls and created a "setter" type function to reflect setting changes to UI
• (WEB App Only) orbital selection from UI auto adjusts the other orbital's UI percentage so the sum adds to 1.
• Some minor efficiency improvements, but probably nothing compared to what you are getting with WebAssembly.
• Changes to some settings are reflected sooner by discarding previously generated levels with new ones.
• Experimental 3D plot of orbitals on a separate branch not to be included
• Anything else I am forgetting

So, these changes are somewhat different than what you have created. For instance, I pass in a set of arrays to the web worker with my selection of orbitals to run and their percentage. This fundamentally changes the design you had. I understand if these changes might be too different than what you want in a PR. Maybe it's more suitable to be just changes to my fork. IDK.

Then there is the issue about publishing it on the steam workshop. There are two ways to go about this:

1. You publish my changes as an update to AudiOrbits or even as a new release.
2. I publish it myself under the banner of "AudiOrbits Unofficial 2.3.1" or "AudiOrbits Fan Remix" or something.

The benefit of option 1 is you maintain ownership and control of publication, but the disadvantage is people will go to you for support and once 2.4+ is released on Wallpaper Engine, people would most likely expect it to also have the changes I made in it or they might view it as a regression of some sorts. The advantage of option 2 is that you don't have to do anything. The disadvantage of it is it will most likely detract publicity away from you. I'll give ample credit to you as the originator of course, but not everyone reads the description. And I bet that if people were to give rewards, they will probably give it to me even though you are more deserving. I did 1/10th the work you put in. Much less than that actually.

I have some other future ideas to make but I don't want to feel like I am taking over the project. I plan on commiting my changes tomorrow or Monday for you to take a look at when you are free. Decide if you want to merged it to your branch or not. Once 2.4 is able to be published on Wallpaper Engine, I'd love to port my changes to it if you'd like, but I'd need some help getting setup.

Regards, Shawn

[hexxone]

Hi, thanks again for your extra work and contribution. I appreciate all the little details you have improved and the thoughts you have given regarding publishing etc.

I've had some time to have a quick look at the code and I don't think it's really "too inappropriate" or different, although there is at least one thing I'd like to change before merging ^^ Mainly this relates to "wewwa.js" as I'm not really a fan of copying it to the repo. Instead, it would be nice to branch from the corresponding commit of "we_utils", implement those changes there first, and then reference the new branch & commit in the submodule & PR that way. Although I can see why it was easier for you to do it that way. But right now I have not seen the diff from the original, so its hard for me to see what you even changed ^^ Would you be willing to make that change?

At the same time, it would also make sense to update the README and other markdown files of the 2.3 branch to include some information about the new additional algorithms and settings.

I think your changes would indeed make the wallpaper more refreshing, and it would indeed be nice to have them for the "old" 2.3 and future "2.4+" versions all in one place. I think it would be less confusing, which is always a good thing for "consumers" I guess ^^ At first glance I think it should be possible to port most of your changes to 2.4 as well, it would just take a bit more time and effort 👍

I would also be open to releasing this as a "2.3.1" version update on Steam after sufficient testing with different settings and templates of course. Let me know what you think

[ssaenger]

Thanks. Please review the latest changes and make any changes you desire. I updated the readme and guide as if I was you, so please make changes so they actually reflect your own words.

Also I don't know how to commit the submodule. What I read online isn't what I am experiencing. I created https://github.com/hexxone/we_utils/pull/3 that shows the changes to the branch, but I don't know how to reference it in AudiOrbits. After AudiOrbits 2.3.1 points to this version of we_utils, remember to update index.html to use the correct wewwa.js and delete the one in AudiOrbits ;)

[hexxone]

Hi, no problem :) Thanks for adding the additional algorithm descriptions and creating the PR in we_utils. I have now looked through the code and noticed the thing with the normalization you want to achieve with the chance of a certain fractal being used.

I think it would be significantly easier if you just treated these parameters as seperate "weights" and maybe make them range from 0-100 with a step size of "1", then just normalize the values in the code similar to this:

var parameters = self.GetAttrSettings();
// e.g. lets assume:  [0,0,10,20,30,50,50,100] (should work with any length)

var total = parameters.reduce((a, b) => a+b, 0);
// result: 260

var normalizedParameters = parameters.map(p => p / total)
// result: [0, 0, 0.038461538461538464, 0.07692307692307693, 0.11538461538461539, 0.19230769230769232, 0.19230769230769232, 0.38461538461538464]

var normalizedSum = normalizedParameters.reduce((a,b) => a+b, 0) 
// e.g.: 1 (should always be =1 or very close to it due to imprecisions)

This way you could really save a lot of code regarding the correct distribution and also wouldnt necessarily need the "2-way" interaction with the UI - which doesnt work in Wallpaper Engine (for most users) anyways - whilst achieving roughly the same result.

Sure, the other parameters wouldnt decrease relative to the one you modify, but I guess thats just something one could hint at with a short text label at the top of the parameters in the project.json to be aware of. This normalizing could also simply be done once, when one of the parameters changes and saved for later use. So you also dont need to recalculate anything later or cap it between 0-1 and would not need too much changes in wewwa as well ^^

Aside from that I think the code looks good 👍 nice work

[ssaenger]

I like the weighted system a lot. It reduces code complexity, and I like that the user doesn't have to do any calculations to ensure an Orbital is within the top 100% probability. With the weighted system, anything greater than 0 has a chance of being included. I'd make one change though: treat 100 as 100%. Very often I wanted to play an Orbital exclusively (to see how changes to the algorithm parms impacted a single orbital), so all I had to do was set it to 1. In the weighted system, the user will have to set all the other Orbitals to 0. This can be a hassle. Then after the user is done playing with a single Orbital, he/she would have to readjust all the Orbitals back to their weighted values.

Recalculating the probabilities and pushing the changes to the UI was a novel idea to keep all the orbitals summed to 1. The idea was that if the user lowers an orbital probability from 0.50 to 0, then that 0.50 points would be evenly distributed among the other Orbitals that were non-zero. Besides recalcAttractProb() not working as intended, it actually was a feature I did not like. I couldn't set the Orbitals to a particular probability when they kept changing on me! With the weighted system as suggested, then this feature serves no purpose. I vote it be removed.

Is this a change you want me to do? I ask to avoid double work in case you already made the change.

[hexxone]

Thanks for your feedback! I see what you're getting at with the 100% scenario for a single orbital.

Regarding the 100% chance case: That's a good consideration. But if multiple orbitals are set to 100, we'd still need to normalize them proportionally. Something like this could work:

const exclusiveParams = parameters.filter(p => p === 100);
if (exclusiveParams.length > 0) {
    // If multiple parameters are set to 100, they should share the probability equally
    return parameters.map(p => p === 100 ? (1/exclusiveParams.length) : 0);
} else {
    // Otherwise use the normal weight calculation
    const total = parameters.reduce((a, b) => a + b, 0);
    return parameters.map(p => total > 0 ? p / total : 0);
}

It would be great if you could make these changes yourself since you understand the intended behavior. But I understand if time is limited - in that case, I can implement it in the coming days when I have some available time. Just let me know what works best for you, and we can coordinate from there.

[hexxone]

P.S.: Oh and I just noticed, we would also need to consider the edge-case where all weights are set to 0 by the user and then choose something like a "default distribution" I guess. Either make it fully random, or just hard-code it somewhere maybe? What do you think?

[ssaenger]

These are fantastic ideas! I like the exclusivity of the 100s. Good point about what to do if all are 0. Both randomizing and hardcoding a default Orbital to play is something the user already can do. I think it would be neat for it to do something that otherwise couldn't happen. Like maybe we create a collection of themed orbitals. We play a set of orbitals for some amount, then swap to a different set of orbitals and play those. In other words, if they set it to all 0, that indicates no preference, and that gives us the creative freedom to do whatever we want.

In any case, something has to be done.

I can implement these changes on tomorrow.

[hexxone]

Thank you for making the changes 👍 I think there are some things which could still be simplified and removed, e.g.: implementing bubble sort by yourself isnt really necessary, there are built in functions for that.. but I can also take care of that myself after merging. This old code was not particularly clean to begin with I guess ^^

[ssaenger]

Yeah please make whatever optimizations you find. I am not familiar with all the built-in capabilities of Javascript so I am sure things could be simplified. I didn't find a built-in method for sorting in my quick search. I wanted higher probabilities listed first because that makes the work on the webworker in selecting a fractal a little more efficient.

Thanks for all your help as well. :)

[ssaenger]

When will we see this be pushed to Steam @hexxone?

[hexxone]

When will we see this be pushed to Steam @hexxone?

Hey, sorry, but I still want to test some of the Steam templates for the wallpaper and make sure they don't "break" or look different with the new changes. Also, I might want to make some more small improvements and only have time randomly, so I can't say for sure yet, but I hope it will be in the next several weeks.

[ssaenger]

Yeah I understand. Thanks for the update. Yeah one thing you may want to look out for is the Easter egg I added when the user sets all fractals to 0 when the camera rotation is at -10. You may want to remove that :P