Rumour has it that space be teeming with life. We're about to find out about that.
While Icey Turkeys hover menacingly over my head, as most of the Intensely Joyous Work on DCS has come to a halt now that it is online and response is ZERO, I remember that there were some spin-offs. One of them is NDS, and it's about time I tackled the Graviton! So here's the Testing Environment of 'Them Spaces'.
Attractors look like full moons. The darkest are the earliest of the image.
Brownian Interaction is marked by a Stretched +, the long bar signifies the axis of speed change.
When the background has a Blue Hue, the Colours have been (re-)initialized. A Red Hue means that there are new Points. They *may* coincide, and then of course the hue is Magenta.
Their numbers don't need to match. Modulo is sweet. The Points have a 2D space and the Colours a 3D space. No solitary confinements here as in some Apps...
They're simply Next-ing and then a few very simple calls - One to the Rgb-maker for the colours and One to the (new) Normalizer for the Points. The movement of the Points enables me to spot irregularities in the algorithms. And yes, I *did* find (and fix) a few errors thanx to these Dancers.
Introduced Normalizer and some interface reductions. Caught a minor bug as well: usage of host's rnd() at one point. Increased size from 10^4 to 10^6 to avoid nasty side-effects at very low initial speeds. Added wrapper for mt_rand calls, which doesn't bother about lowest first, and returns "v0 + (v9-v0)*nds_rnd()" - simple, but no longer vulnerable to low values.
One very serious bug though, which I already suspected from strange NDS behaviour in DCS, came to light. Every now and then the speed of some points went totally berserk. Pinpointed it to the Attractor, but even then it took me short while to figure out WTH was wrong. It was of course very simple. In redirecting the particle's velocity, I had made a mistake. I did "Distance Vector / sqrt(V-squareds)" . That should of course have been ".. * sqrt(V-squareds) / sqrt(D-squareds)".
Much better now. Already active in DCSv3/dev. And as a side-effect, I introduced a [tmp] area in the Space Table. Initialized per 'next'. Attractors now leave their position there. NDANCE currently picks it up and shows a filled circle if there is one. Actually, that was the first time I actually *saw* one. Seen quite a lot of them now. Like them even more, now they function as designed / dreamed.
Brownian Movement now logs its activities in the [tmp] now.
I had the impression that something was wrong with Attraction, and Dance may be aesthetically appealing, but for accurate path tracing, it's too confusing.
So yeah, i positioned the Moons with rectangle co-ords. But that's not an engine fault of course. Fixed it anyway, in Dance as well.
Then I tried Wrap and found them all cluttering at the edges. *THAT* was an Engine Fault for sure. So now the speed direction only changes when we bounce.
To be fair: I hadn't until now any use for wraparound, I only implemented it because it might be useful for *some* App.
Some ideas, sure. Let's see...
Yes, that *is* one of the prime targets of this project.
Phew! Almost forgot. Good of you to remind me. Might not be of much use in Colours, but might sure be fun to watch in Positioning.
BTW : Who says that it *wouldnt* work well for colors? Any Proof somewhere that I dont know of?
"Dancing" with the improved wraparound (thx, Walk), methinx that Bounce OR Wrap may be too restricted. CHANCE TO do the One or the Other would surely add something. Colours would have Chance zero to wrap (usually), but Racers... Well. You know. Sometimes they bounce, sometimes they wrap...
WHOA.
But me wants to think about it first, for what should its other dimensions do? Well, if they dont border, they can stay where they are. And if they do, it's each for itself? Yeah, or maybe decide collectively, and if so: per Particle or per 'Frame' ?
Hm. Darn. But we can prototype this by making the user pgm flip the switch of course! Per Frame, per Image, Not Per Particle, alas, but who would notice?
I have a cunning plan...
Suppose we have 1 Particle in 27 Dimensional space. Make 27 projection images ? Not very attractive.
The plan : Rip it apart. Project all dims in 1 image. The 1st point would be x1-x2 ; the 2nd : x2-x3 ; the 3rd : x3-x4 etc, all the way up to 27th : x27-x1
27 may sound idiotic now, but ... And project the Attrs and Gravitons with a dim-number in them.
26 Maart 2017 - dat is ook weer voormekaar. De Attractor is al netzo schizo. Meteen maar even een generieke pagina gemaakt voor de show, aptly called PSHOW. Moet nog een JS-array in, zodat-ie ook naar hartelust kan omschakelen. CSS Attributen *vw* en *vh* werken in Firefox beter dan %. Er viel een piefke om, zodat de originele pagina's nu niet meer goed uitlijnen. Was de generieke dus net op tijd klaar.
Kan alleen geen *100vx* gebruiken, want dan duwt de Scrollbar de boel opzij. Weten ze al bij Mozilla.
De Schizo moet namelijk vierkant, omdat de [e']en z'n X de ander z'n Y is. Ook meteen de co[o"]rdinaten maar even goed gezet : de oorsprong is nu links-onder. Maakt voor die andere algoritmes niet veel uit. Bovendien is Walk nu een speciaal geval van Dans, namelijk die met NUL lijnen. Maakt-ie bolletjes.
This has nothing to do with testing NDS, because it's a recap of all imagery elsewhere on this page. BUT it has to do with JS, and thanx to javascript.info, that's a new Passion!
The PHP knows which ones exist, through its config. It generates the object-array which is used by the now STRICT js, with let and backtic and all. The PHP has to escape the JS-$ in the backtic-string, but that is such a minor inconvenience when compared to the elegance of the result, that it is utterly worth that tiny bit of effort!