Oh there is a thumbs up, cool. Achieve static ambient density given the emulator is fundamentally working off discrete principles. Surely there is a way to get closer to the machine is what I am wondering - the end result would be that math.
I’m still lost as to what you are thinking. That formula is for the light scatter simulation. The formula yields a static ambient field density representative of an amassed monoparticle in the center of the cube with no other affectance present. A group of afflates are then to be introduced propagating from one side. As each afflate traverses the mass field, it’s trajectory will be altered.
I knew you would be still lost after I made the post and read it - I am thinking on the fly to see how much of this is internalized hence why I was appreciative of phyllo’s questions. I understand what the formula is for - I was wondering how I could translate it beyond regular code, closer to the machine - assembly code mixed with binary operations.
You are saying to create an amassed monoparticle, in the center of the cube - I am saying the same except I will have other affectance present. Point the afflates at it, as they approach there is going to be “force” between them and the monoparticle, and each other - I imagine some repulsive force is present and momentum to give the slingshot.
There are no forces. Yes, “speed vs Density”, but then also angular trajectory vs gradient.
But one step at a time.
The Ab is the point-by-point ambient density as a result of an amassed affectance. So the speed of each afflate is determined by it relative position to that mass and the combination of its own density and that of the ambient at each point it traverses.
Again, this is a time when you have some freedom to pick and choose which way you would like to setup the field. You have specific afflate characteristics defined as if they were marbles (not yet “fuzzy”), yet the field has no such hard objects within. So if asked what the field density is as some point, {d,e,f}, precisely how are you going to use the local afflates to determine (to declare) the precise density … at any point chosen?
There are many legit reasons. But yes to avoid the overhead of abstract functions and bad optimization on the part of the compiler writer. Binary operations like adding and subtracting I imagine would be good for building massive fields of affectance.
By “point”, I merely mean a chosen location within the space. And yes, choose a type of averaging that will yield the kind of field you are trying to form (smoother, choppier,…).
And you will want to make that a “hook” so that you can play with it later.
A point can be chosen with any resolution I guess, obviously there is more than two “things” involved but points are infinitely small so I could base my average on a small or large selection.
You could, just for example, have a linear decrease in afflate characteristic with distance from surrounding afflates. Or it could be exponential, giving a more choppy effect. I would recommend a very limited local distance for the range of evaluation so as to not consume too much processor time.
I had to think for a while to figure a way to quickly evaluate each afflate’s (or location point’s) immediate surrounding. Of course, you are free to choose your own method.