Possible Charged Particle Field

I also changed how you set the boundary type to use. It is now a property of the MotionEngine, called boundaryType. The possible values for it are:

PIM.BOUNDARY_TYPE_SOFT
PIM.BOUNDARY_TYPE_HARD
PIM.BOUNDARY_TYPE_PORTAL
PIM.BOUNDARY_TYPE_STICKY
PIM.BOUNDARY_TYPE_DESTROY

So you can just set it in a scenario like this:

Code:


engine.boundaryType = PIM.BOUNDARY_TYPE_STICKY;


.
Still enjoying my review.


Collision Test 02. Yesterday I posted Collision Test 02 results - I mistakenly called them Test 01 results - above/below comparisons showing little to no improvement in collision ‘accuracy’ after your first effort at colliding/overlapped particle separation. The gif shows the same Collision Test 02 results are now ‘perfect’. One can see a little hiccup or irregularity - the particle popping back into position; it's explained by the next set of images.


This group of six gif stills (sampling at 30x a second) shows the large overlap that the collision overlap removal function has successfully removed.


I forgot to mention – the celestial sphere is awesome. Inside or out you know exactly where you are. It’s in perfect contrast with the particles and adds information to images. Anyway, I loaded Random 01 and let it go for a while. The boundary soon become a very large ‘particle’ of its own. Most of the particles shown outside the boundary are orbiting the outside of the boundary. I know, I know, that’s just plain wrong, still, I had to mention/point-it-out. For one thing, it shows increasing system energy.
.

Excellent analysis. Perfectly showing the overlap and its resolution.

Would I be correct to assume those particles were created outside of the boundary? Instead of moving from the inside to the outside and then getting stuck out there.

I have added a new menu for the user to select the boundary type and its radius. They are just too much fun for me to leave them in the hands of developers only. We can still set them in the scenarios, but the user can override them.

The boundaries should not increase the energy in the system. I am not saying that they don't, just that they should not, and I don't think that they currently do. Although I am a bit unsure about the elastic boundary (formerly called soft), which may be able to introduce small amounts of residual velocity depending on the trajectory of the particle. The hard boundary should not change the total energy. The portal boundary does not change the velocities at all. The sticky boundary actually saps energy from the system as it stops the particles in their tracks. The destruction boundary does the same by removing the particle altogether.

I think the energy increase is coming from the collisions when there are multiple particles colliding on the same frame. Occasionally I see a particle or 2 shoot out of a pack. Somehow the velocities don't stack correctly. Not really sure at the moment.

https://www.nevyns-lab.com/mathis/app/cpim/test.html?cp=1&rnd=0&bnd=1&r=100&scenario=Gravity.Close&graphics=n,n,n,n,y,n,y

Check this out for some weird awesomeness!

https://www.nevyns-lab.com/mathis/app/cpim/test.html?cp=1&rnd=0&bnd=1&r=100&scenario=Gravity.Random%2005&graphics=n,n,n,n,n,n,y

Warning: May cause large numbers of computations.

The problem of increasing energy comes from the forces themselves, too. Charged particles and ambient charge can be explained by the ambient field. Not seen in the model, but ever-present. Gravity, on the other hand, is pure creation of energy. All of the gravity scenarios just place the particles, they do not start with any velocity of their own, so all motion is caused by gravity.

.

Collision Test 07.

I had to create a new collision scenario - Colliding Test 07 - before letting myself post again. I succeeded, but upon reopening, the linear array of particles with large separation distances exceeded the default boundary and caused a particle pile-up. No problem, I just expanded the universe slightly and the scenario operated properly. I need to re-read your instructions above to see if I can set the boundary limits from the scenario itself.

Your boundary types/radius is a fine addition. I'll need plenty more time to play with it. Of course if the user is bored or inquisitive enough, he/she might also play with it, using the boundary in non-physical, ‘unjustifiable’ ways. Oh well, the price of fun.

Would I be correct to assume those particles were created outside of the boundary?

Negative. The random 01 particles all began inside the boundary. Over time, more and more particles penetrated the soft boundary and took up orbits there. I’m overly concerned with energy balance, I’ll keep a close eye on it. Thanks for discussing it further, sounds like gravitational potential energy.  
.

I have made changes to most of the boundary classes to deal with particles that do not have a velocity. The first versions assumed that the particle had to travel out of the sphere, so they would have a velocity to work with. However, that is not the case when things are created outside of it, or they have a collision while outside.

I have seen particles moving straight out of the boundary and then colliding with another that puts the first onto an orbital trajectory. They can loop around quite a few times before sinking back in or colliding with another particle.

I've been thinking about creating a new Boundary class that increases the mass of a particle that exceeds the boundary. Just for fun. Imagine the PortalBoundary and every time a particle is transported, it gains mass. It could be a good way to test that mass is being used correctly in the math. But really, just for fun.

.

Imagine the PortalBoundary and every time a particle is transported, it gains mass. It could be a good way to test that mass is being used correctly in the math. But really, just for fun.

I won't understand that til I see it, why not try it.

I must point out that with the all the action taking place at the center of a sphere, all scenarios with high velocities tend to come back the spherical center – the universal focal point. Please consider an additional/alternative boundary shape, the cube. If space was cubic, then only the velocities perpendicular to the boundary walls would tend to come directly back. Using that fact, one may create particle streams out of transported particles in wraparound space in +/-X. +/-Y, or +/-Z directions. A big cubic space (wraparound optional) was my original presumed shape of the boundary space, I never imagined a sphere.
.

I initially thought I would create both a spherical and a rectangular boundary, but it was a lot easier to work with spheres than rectangular shapes. I still wrote the code trying to keep it neutral, so that it would work with both, but some of the implementations do rely on it being spherical.

I spent a bit of time working on a rectangular mechanism, but it makes things difficult. I'll see what I can do when I have a bit of time.

.

Not overlapped, just close.

I had to share this gif, an example of gravity and two close particles left after Lattice 03’s breakup. Previously, this pair would get closer and closer, merging/melding then bursting - aka Bug 01. Here, I observed several minutes of close interaction, their spinning changes as they interact – not entirely correctly. Nevertheless, I believe the particles are interacting in a natural way. They cannot separate without a collision by another particle.  

With respect to the boundary, a big difference between spheres and cubes/solid rectangles is spheres cannot fill all space. I believe that’s a practical problem here. I remember seeing some sphere partitioning that involved curved cubes/sphere algorithmic mapping last week. This may make cubic or rectangular space more ‘sphere-like’.  
SphereCube
http://www.sai.msu.su/~megera/wiki/SphereCube

SUMMARY
The quadrilaterlized spherical cube, or quad sphere for short, is an equal-area mapping and binning scheme for data collected on a spherical surface (either Earth data or the celestial sphere). It was first proposed by Chan and O'Neill in 1975 for the Naval Environmental Prediction Research Facility (Reference 1).

.

The recent spin update I did was only to add the spin caused by a collision. It does not calculate the interaction of the existing spins on the particles. In the above example, the particles should pass their own spin onto the other, ending with them both spinning about a common axis, but in opposite directions from each other. I will get to that at some point. I had a quick go at it a few weeks ago, but it didn't work in all situations.

While a cube geometry can contain more space than a sphere with the same diameter as the box is wide, in this case it is that geometry that defines space. There is no concept of filling all of space because the boundary sets the outer limit of what space is. But that isn't my problem anyway. Spheres are easy to deal with because you don't have to care about direction. The boundary of a sphere is always the same distance from the center as any other part of that boundary. You don't need to figure out which surface is being collided with and handle it appropriately. With a sphere, you just find the tangential plane at the point and that is your surface. A rectangular shape requires calculating which face of the geometry we are working with in a particular collision. It's just more math and more difficult to handle. Not impossible, just not as easy as a sphere.

Personally, I prefer spheres in most situations. Especially if it is to represent the boundary of a universe. I don't see how any natural boundary would be a rectangle. They might look cool with corner collisions and stuff, but they don't really represent nature very well.

Part of the problem at the moment is that the boundaries are 1) enabled by default, 2) set to a small size by default. That is just for the moment as it makes it easier to work with as a matter of testing. Now that I have added the URL parameters to specify the type and size of the boundary, it isn't really needed. I will change them later today and relegate them into the distance and turn them off by default. You can enable them in any particular scenario if you want to. Although I might need to make sure that the user selected boundary is applied instead of the scenario specified one.

.
This is what counts as discussion. Don't go solving spins until we're good and ready.

Can we include a Pause button? Or Loop?

Thanks for all the details. As you must know by now, I like to throw ideas out there, usually making many wrong assertions. You know I just sound like I understand things better than I do. I think I’ll be happy with what we’ve got, but it seems I need to understand what we’ve got a little better.

Please excuse the expectation/confusion. Spherical space is a new idea to me, I'll get used to it. In fact, I think the celestial sphere should be a Graphic option whether the boundary is active or not. Anyway, more than cubic space or the spherical space’s center, I seized on the possibility of making portal-ed particles the ambient field. Please recall I asked whether we could create particles or a particle stream and you rightly said the program doesn’t operate that way. It seems to me particles making endless portal boundary crossings in a general direction are no different than a very regular particle stream. You mentioned giving boundary crossing particles additional mass, and we can define the boundary pretty much however we like (?) so we don't even need cubic space. What else can we change? It seems to me we can recycle  portal particles into a perfectly good source for the ambient field. Is that reasonable?  
.

Yes, there is already code in there that can pause rendering. It just needs to be bound to a key and/or some button. I'll probably bind it to the space bar.

What do you mean by a loop? To be able to set the number of frames, or time, and then it resets all of the particles and starts again after that? That is feasible. I can easily add URL parameters to do it, but it will take a bit more effort to setup a UI for it.

.

What do you mean by a loop?

Gifs - moving images - are extremely useful, but they are usually too big (>1M) to post. This program can do better than gifs, people could create their own motion studies - or verify what they think they just saw (?) - using the Loop function. See something interesting? Hit Pause (the spacebar) and go back the last 10, 15 or 20 seconds - or by using Reset, can I stop just before the moment of interest occurs, then begin a Loop?  I guess one could reset a clock on a given scenario to any point of time in the output (throwing out uninformed thoughts again). Would it be possible to save the scenario settings for a Loop file? Or to replay saved files? I'm not thinking of recordings or am I? Note, this is discussion, questions. If you’re motivated to make any changes great, otherwise, please don’t take this discussion as a bunch of requested taskings. You’re so creative, I'm a bit gun-shy, a random thought may cause you to rebuild the whole place again.
.

.
I got around to unbreaking Lattice 03, 04 and 05 by excluding gravity and ambient charge as you indicated I should – oh, long ago. 01 and 02 are still quickly crushed and broken – good abject examples. In 03 I brought the neutrons back together showing spins close up. 04 just sits there spinning, the neutrons aren’t dropping, I wonder why? The neutrons still drop in Lattice 05 – 4 neutrons above 4 protons; but 05 now has a new problem, when the neutrons are half way down, resistance appears to be removed and the neutrons accelerate downward.


Neutrons stuck outside the hard boundary. Clearest with the group closest to the lower left hand corner.

I like the Gravity group’s new random choices. Unfortunately, there’s a problem with the random choices and the 100 unit radius hard boundary. Many neutrons were generated outside the boundary. There’s no problem with the 200 unit radius. Unless you indicate otherwise, I’ll clean that up tomorrow.
.

Hmm. Maybe I can get something like that working. Probably not exactly, because it isn't a movie where every frame is available at any time. What I can do is record the current state of all particles (just like it does for the reset action) at some point in time or some key press or some other action taken by the user. Then count the number of frames until some condition occurs (time elapsed or stop button pressed). Then it can loop between those points in time.

I could introduce stepping functionality, like an application debugger. Effectively allowing the user to step through frame-by-frame. You can't step backwards though. You can't go back to the previous frame.

I could save the current state of all particles to a file. Then load it back in and start the application. However, I will likely need some back-end services to do that, which means that I will have to use a server-side language like PHP. This will make it difficult for you to run it on your own system without setting up a server. There are some client-side tools I can use, but they are HTML5 specific, and the last time I tried to use them like this, they failed and crashed the page. Maybe browser support for these features has improved since then. I might create a new branch to work on that, just to keep it separate from the rest of the app.


When you disable gravity and the ambient field at the same time, then the old proton attractions (implemented in the charge profile) come into play again. Maybe that is what you are seeing and it behaves differently to what we expect now.

Don't fix the problem with particles being created outside of the boundary. That must be handled by the boundary implementations. I have code in there to deal with it (it generally just puts them at the boundary, or a little bit inside of it), but I don't think it is working perfectly. It does look like some particles get stuck rolling along the boundary. I can't tell if it is just a time issue, in that they need a bit of time before gravity starts to pull them inside of the boundary, or if it is something more serious.

.

Terrible results. Broken Offset Collision Test 07. Using stationary unmovable target particles – still at the grid. I could see the collision repositioning function as a vibration, resulting in small final unmoveable position changes, especially in the two closest to head-on-like collisions in the center of the array.

I love playing with functionality, setting-up shots and sharing the results. That’s why I’d like a Looping ability. But that may be asking for too much. Keeping it simple by adding common function buttons like Pause (“spacebar”), and Step (“stepping functionality(?)”), to the existing Reset and Reload, sounds like a better choice than the need for back-end services; File saving sounds like more difficulty than it’s worth.

There is indeed a time delay before the Gravity group’s random particles created outside the 100 unit radius boundary re-entered the Universe. All is well.  
.

I have implemented a time management system that allows you to start/stop the model and you can step through it, frame by frame. You can even mark a certain point in time and return to it, replaying the model from that previous point.

The following key events can be used:

Key	Action
space	toggle between running and stopped
down arrow	stop the model
up arrow	start the model
right arrow	step to the next frame
Enter	mark current point in time
left arrow	replay from mark

If you pause the model, then mark the current state, then step to the next frame: you can now move between the previous frame and the current frame by repeatedly pressing the left then right arrow keys.

I have created a new Boundary that works just like the PortalBoundary, but it creates a random position to teleport to and a random velocity to apply to the particle. This represents random loss and gain of particles from the environment while maintaining a constant number of particles. Not exactly natural, but a useful boundary.

Site is updated with all of the latest code: https://www.nevyns-lab.com/mathis/app/cpim/test.html?cp=1&rnd=0&bnd=5&r=100&scenario=Gravity.Random%2005&graphics=n,n,n,y,y,n,y

.
Zuper!  We can freely move about while motion is paused, easily stepping or looping - examining any item of interest in as much detail as we like. See how collisions work, each involves a small amount of particle overlap, then the overlapping particle pops back into place. Anyone can see for themselves better then any gif I can make. Or one can verify any detail we've discussed.

The two neutrons on the left just separated after a collision last frame.

Works perfectly. As usual, your implementation exceeded my imagination. The additional functionality is impressive.
.

But wait!

There's more!

If you call within the next hour, you'll also get slow down functionality!

That's right. You will be able to run the model at a reduced speed, without needing to step through it yourself. How convenient is that? No more fumbling around in the dark, trying to find the right key to press. Just sit back and watch the action at any one of 9, yes 9, speed settings!

Slow down functionality may be available even after the one hour promotion.

Key	Action
,	slow down by 1 step
.	speed up by 1 step
1 - 9	set speed

The amount of slow down is set using a formula. The slowness factor is a number between 0 and 8 inclusive. That value is then used to find the number of frames to wait by finding 2^N, where N is the slowness factor. Then it calculates the modulus of the current frame count and that number. If that equals 0, then a new frame is rendered.

In mathematical form, a new frame is rendered when: ( frameCount % 2^N ) = 0.

.
Dang, I was whittling away at the edge of collision test 07; ready to talk about including user velocity choices. Then your latest - in all the excitement, I Fetched, Pulled and Pushed, and now I see I merged branches. I hope that's OK with you?
.

Nah, that was actually my fault. I didn't fetch before pushing my changes. All is well, no problems. It just looks a bit funky on the commit graph.

.

All is well, no problems.

Ah, wonderful. Even though I replied within the hour, I was worried whether I could keep the slow down functionality. Thanks.

I usually like chaos, while you tend to simplicity. Except with gravity, I believe my favorite scenario at this point is Gravity, Random 01 - it starts with 10 particles. I would like to suggest being able to select 2, 3, 4, 5, or other single digit up to 9 particles. I see the Gravity group already includes 8 buttons. Maybe a slider would work for 2-9 particles, and maybe another slider with 40 - 400 could replace four of the Random buttons.
.

You can ask the user for input during the initialization function of a scenario. The simplest way to do that is to use the prompt function. You pass in a message for the user, and optionally a default value, and it will show a dialog box with the message and a control for them to enter in some text.

Code:


var count = prompt( 'How many particles would you like to create: ', 100 );
if( count != null )
{
   count = parseInt( count ); // make sure we have an integer
   count = Math.max( 10, Math.min( 300, count ) ); // make sure it is within reasonable bounds
}
else
{
   count = 100; // default value
}


Don't bug the user with a lot of prompts. If you have many things to ask, then it is better to use a custom dialog box. We can cross that bridge if/when we come to it.

I have created a Help dialog that provides information about the app such as the available options and the keyboard bindings. Added descriptions for boundary types, precision, etc.



I have imported Bootstrap to do the UI, so we can create some nice dialogs for user input if we want to.

.

Collision test 07, I included what I hope are properly scaled post collision lines. It may be a keeper or not.


How the position lines and lengths are calculated.

Help Dialog boxes. Bootstrap UI (look that up). It sounds like I need to brush up on my Customer Service skills.  

I unintentionally merged branches again, in the same way as yesterday; I thought it was my fault - yes I'm still using the terminal. I thought I must commit my own changes before I Fetched, Pulled and Pushed. I guess I should not have positioned myself on the top line which indicated the Push/Pull numbers. Again, nothing broken but my pride. These lessons do slowly sink in.
.

What you should do is Commit your changes, then Fetch, if there are new commits that need to be Pulled, then you Pull with Rebase. That will pull down the new commits (my changes), and then add your changes on top of that. If you just Pull them down, then it adds the pulled commits on top of your changes. The pulled commits were written without your changes though, so they won't know anything about them. This can cause merge conflicts.

In this case though, we have not modified the same files, so it has all ended up in the same place.

I must say, I was mighty confused when I looked at that collision scenario. I didn't know what it all meant, but then the particles collided and it grew into an expanding double helix. Looks pretty cool.

.
Test 07 is intended as an accuracy indicator - I like it. One may show how closely post collision neutrons follow those lines or protons deviate from them. I'm working on another collision accuracy demonstration if I can get to it. Your changes are a constant feature.

Review mode. Help.

The Help UI is very nice. A professional class improvement. Better and better, this may lead to a salary yet.

I think the Key guide is essential. I should mention, now when I start a sim, I also press enter. I tend to use enter and the left arrow a lot, instead of the reset button.

Here’s a quick review of the Help text.
1. Options. Boundary. Sticky. Typo - Change “Actuall” to Actually.
2. Portal definition is wishy washy. Consider changing to - The Portal operates like the old arcade 'wraparound' space; particles exiting the boundary in one direction will return in the same direction from the the opposite side of the boundary universe.  
3. Options. Boundary. Destroy. "Any particle that touches the boundary will be removed from existence." Sounds a bit much, consider changing to "Any particle that touches the boundary is removed from the simulation.
4. Options. Precision. Typo, - Overdirve.
5. Options. Graphics. Charge Profile. Please delete "Although these are not used much anymore.", things change all the time around here.

Separate subject. The particle mesh is too dense.

I Commit whenever I make a change, before any Fetches, Pulls and Pushes. The terminal commands apply to the Commit line I'm on (as shown by the Sourcetree interface ). I'll keep at it. Your patience is appreciated.
.

Fixed up those issues.

I also made it set the marked state to the initial state at the start of the simulation. Now you can just press the left arrow and it will reset to the start if you have not recorded a mark yet.

.
Thanks for defaulting a loop preset.

Ok, I made collision test 08. Two particle streams aligned and traveling in opposing x directions meet in a series of offset collisions. Each particles has slight random Y and Z offsets. If the hard boundary is selected (best at 100 or 200 unit radius), most of the particles will collide again and again.


Getting ready for particle spins, another Collision test I'm trying to set up is a recreation from Antonio Doménech's paper, A classical experiment revisited: The bounce of balls and superballs in three dimensions.
.

.
Before I can set up the spin bounce diagrammed, we would need a surface. Given our previous discussion, I believe we can use the internal surface of the hard spherical boundary as our experimental surface. If so, we may reduce the boundary curvature by expanding the boundary radius to ‘maximum’; alternatively, you indicated we might be able to define a flat surface somewhere(?).


Here I have a particle and a 2x2x2 grid centered at the south pole of the 100 unit radius universe. Unfortunately, I have an immediate problem, the camera is always centered on (0,0,0). I do not know how to get the camera to orbit about (0,-100,0) instead of (0,0,0). I see you provided lookAt code lines - camera.lookAt( new THREE.Vector3( 0, 200, 0 ) ) - in a few locations in the scenarios, but is that code actually doing anything? I tried camera.lookAt without success. The following may explain why.

ThreeJS camera.lookAt() has no effect, is there something I'm doing wrong?
https://stackoverflow.com/questions/10325095/threejs-camera-lookat-has-no-effect-is-there-something-im-doing-wrong

Andrea wrote. I figured it out. To prevent THREE.TrackballControls or THREE.OrbitControls from overriding camera.lookAt upon initialization, you need to change the line that sets the control's target property to equal the sum of the camera.position vector and the camera.getWorldDirection() vector, instead of how it's currently implemented using a new THREE.Vector3() (which defaults to (0, 0, 0)).

Of course, I'll differ to your opinion.
.

I am a bit dubious of anything that requires a surface. While we have introduced the idea of a universe boundary, which can act as a surface, it is not the same thing as a surface in the universe. I don't think this app is the right place for that because it is focused on particles and their interactions with each other. The only surfaces that exist are on the particles themselves. You might have to find a different way to accomplish the same thing. I'm not sure what you are trying to accomplish, so I can't help in that regard.

I have had issues with camera.lookAt before, but I have also got it working. I haven't used it much in this app (that I can remember), so I'm not sure if it is working if it is being used. The THREE.OrbitControls can be a bit of a pain at times, but they do provide an easy way to get some controls happening.

Maybe you would like to spend some time looking for an alternative. THREE has some other options, but there also might be some created by other developers out there, that work with THREE. I'd focus on those supplied by THREE first (they are in the examples, not the core THREE code), and look for external ones later, if they don't pan out. Maybe we could offer different ways to controls the camera through menu items. Then the user can choose whatever they want to use. Maybe we need the scenarios to choose the control mechanism. Once we know what other types are available, we can make such choices.

I see that you have pushed those changes, so I will have a look at it and see if there is anything obviously wrong, or something that is missing, but it sounds like a common problem. We are running THREE version r88, maybe it has been updated in a later release. If you find out that it has, we could look into updating the THREE version we are using.

To get the camera to orbit around a different location, set the target property of the camera object. It is a THREE.Vector3, so do something like: camera.target.set( x, y, z );

The only time I can remember discussing flat surfaces was in relation to using a cubic universe boundary. However, that would not suit your purposes here, as you actually need a gravity force pulling down towards the surface and our gravity would not do that.

However, could we introduce another form of gravity that acts like a planet? A very large mass causing a definite direction to gravity, in addition to the existing gravity between particles. We are getting into declaring different types of universes. I am hesitant to go down that path, but it might be worth some investigation. Maybe we create a 2nd HTML page for Earth-like simulations.

.

The only surfaces that exist are on the particles themselves. You might have to find a different way to accomplish the same thing.

Agreed, we only have particles. We can demonstrate spin collisions perfectly well with particles only. We can set up both particles with mirrored positions and velocities resulting in oblique spin collisions at (0,0,0). We can control the spin axis and spin rate for one of the mirror particles - something one cannot do with a surface - while observing the resulting spin changes to the other particle.

To get the camera to orbit around a different location, set the target property of the camera object. It is a THREE.Vector3, so do something like: camera.target. set( x, y, z );

Thanks, I Pushed the rough draft so you could see what I'd tried, it didn’t include camera.target. set( x, y, z );. I’ll try that next. Knowing I probably won’t use lookAt, I didn’t look at it yet.

Maybe you would like to spend some time looking for an alternative. … . We are running THREE version r88, maybe it has been updated in a later release. If you find out that it has, we could look into updating the THREE version we are using.

You’re asking me? My opinions on the subject are rather weak. Let’s see, r88 was released in Nov ’17, since then there have been: 89,90,91,92,93,94,95,96, and 97. I didn’t finish looking. I have no idea of the relative importance or major/minor changes associated with any of those releases. It seems the great complaint about Three.js is the lack of documentation. Many people reuse old examples without knowing whether those examples depended on an old release.

I haven’t looked into third party vendors offering three.js products, I didn’t imagine that such support existed. The following Three.js review indicates that they may be few.
//////////////////////////////////////////////
What are the best open source JavaScript 3D engines?
https://www.slant.co/topics/3777/~best-open-source-javascript-3d-engines

TOP PRO
•••
Feature rich
Effects: Anaglyph, cross-eyed and parallax barrier. Scenes: add and remove objects at run-time; fog Cameras: perspective and orthographic; controllers: trackball, FPS, path and more Animation: armatures, forward kinematics, inverse kinematics, morph and keyframe Lights: ambient, direction, point and spot lights; shadows: cast and receive Materials: Lambert, Phong, Standard, smooth shading, textures, PBR and more Shaders: access to full OpenGL Shading Language (GLSL) capabilities: lens flare, depth pass and extensive post-processing library Objects: meshes, particles, sprites, lines, ribbons, bones and more - all with Level of detail Geometry: plane, cube, sphere, torus, 3D text and more; modifiers: lathe, extrude and tube Data loaders: binary, image, JSON and scene Utilities: full set of time and 3D math functions including frustum, matrix, quaternion, UVs and more Export and import: utilities to create Three.js-compatible JSON files from within: Blender, openCTM, FBX, Max, and OBJ Support: API documentation, public forum Examples: Over 150 files of coding examples plus fonts, models, textures, sounds and other support files

TOP CON
•••
Lack of versioning system means that the API changes frequently
Three.js releases a new revision about once a month, and the API can change at any time. This means that a lot of third party help found online is out of date.

//////////////////////////////////////////

The only time I can remember discussing flat surfaces was in relation to using a cubic universe boundary. However, that would not suit your purposes here, as you actually need a gravity force pulling down towards the surface and our gravity would not do that

Correct, we discussed the possible flat surface for a boundary.

I’ll try sticking to the agreement – there are only particles. On the other hand, I was hoping we might have a selection of sizes by now; but I don’t understand the obstacles to that. Will we get around to creating particles with stacked spins?

But now I’m confused, we aren’t looking at bounces yet; why would gravity be necessary for testing spin collisions?

However, could we introduce another form of gravity that acts like a planet? A very large mass causing a definite direction to gravity, in addition to the existing gravity between particles.

Simulating the particle field due to large gravity/charge sources should be a matter of adjusting the model’s local ambient conditions and not “declaring different types of universes”.
.

Airman wrote:You’re asking me? My opinions on the subject are rather weak. Let’s see, r88 was released in Nov ’17, since then there have been: 89,90,91,92,93,94,95,96, and 97. I didn’t finish looking. I have no idea of the relative importance or major/minor changes associated with any of those releases. It seems the great complaint about Three.js is the lack of documentation. Many people reuse old examples without knowing whether those examples depended on an old release.

I only meant that if you find some info, while searching about your problem, that indicates a later version has fixed the issue, then we could see if it is worth updating the whole app.

I tend to pick a version at the start of a project and keep it until I find a reason not to. As the API can change quite quickly, it can be a pain finding the problems and getting things working again.

Airman wrote:I’ll try sticking to the agreement – there are only particles. On the other hand, I was hoping we might have a selection of sizes by now; but I don’t understand the obstacles to that. Will we get around to creating particles with stacked spins?

Introducing electrons requires the math to work with different radii and mass values. I think most of that is good at the moment, but it needs checking. The main problems at the moment are other visualizations, like the charge points, particle meshes, etc, need to be reworked a bit to handle multiple sizes. How does precision effect things? Does an electron have the same number of charge points as a proton? We need to make some decisions around that type of stuff too.

I don't see any need for stacked spins in this app. We are treating particles as rigid bodies. It is a simplification, but the app is about force interactions rather than accurately modeling quantum particles. If we were to use stacked spins, most of what we currently have would be thrown out. A stacked spin model needs to be built from the ground up to understand stacked spins and how things collide, receive charge, etc.

We could think about trying to determine if a given collision would spin-up and spin-down the particles involved, and change the particle type to the new version. Seems like a lot of effort though. Not sure if it is worth it at this point. I think that would be better spent on a new model for stacked spins.

Airman wrote:But now I’m confused, we aren’t looking at bounces yet; why would gravity be necessary for testing spin collisions?

Because the surface would not act like you want it to, without gravity pulling the particles towards the surface and keeping them there as they roll along it. They would just bounce off without that downward force towards the surface.

Airman wrote:Simulating the particle field due to large gravity/charge sources should be a matter of adjusting the model’s local ambient conditions and not “declaring different types of universes”.

It is a fundamental difference. To simulate the environment on the surface of a planet, we need some notion of a surface and a large gravity force pulling straight towards that surface. We need the collision code to know about that surface and how particles will collide with it. We also need to provide a visual reference of the surface. That differs from 'some particles in space' that we currently have. As a matter of programming, they are closely related, and will use a lot of the same code. I think it better to have separate pages to handle each case so the user doesn't get confused about what they are looking at. Besides, two pages looks like twice the work for only 20% of the cost!

But now I’m confused, we aren’t looking at bounces yet; why would gravity be necessary for testing spin collisions?

Because the surface would not act like you want it to, without gravity pulling the particles towards the surface and keeping them there as they roll along it. They would just bounce off without that downward force towards the surface.

Thanks, but that answer doesn’t make sense to me either. I imagine spin collisions – with 2 particles, or a particle and a surface - as a single bounce. I do not imagine any rolling, other than during an ideal brief contact phase during an extended (very flat or oblique) collision – and certainly not for this scenario. Also, we do not depend on gravity to give any particles their velocities in any of the collision tests, why would the spin test be different? Please describe what you think of as a spin collision test.

We’ve discussed the fact that I shouldn’t treat the boundary as a physical body, and I understand and agree. I violated that rule - before agreeing to it - by recommending that the user runs Collision test 08 with a radius 200 hard boundary surface. The particles bounce off the boundary causing repeat collisions at the center stage – 0,0,0. For spin test 01 I intend to comply with 'there are only particles' rule, by colliding two particles with complementary positions and velocities – and varied spin axes and rates - at (0,0,0).


If you hold the image just right, you can see the orbital view of a particle and 2x2x2 grid centered at the south boundary pole.

Today I made some progress. Now if you decide we can use the hard boundary for collisions, I can now show collisions there. The image shows another particle and 2x2x2 grid centered at the south boundary pole. lookAt isn’t needed.  

camera.position.x = 1;
camera.position.y = -100;
camera.position.z = 5;
controls.target = new THREE.Vector3(0, -100, 0);
controls.update();

////////////////////////

I just read a fantasy book, Wizard’s Bane by Rick Cook. It’s about a computer geek (written in 1989) who must save a magical world. A light read you might find entertaining. I couldn’t let it go without mention.
.

Maybe I was wrong about what you were trying to achieve with a surface. When you mentioned it, I thought you needed the balls to roll along the surface before colliding with each other.

As for using the boundary for collision testing, it really depends on what you are testing. If you are trying to test the boundary itself, then that is fine, but if you are relying on the boundary to test something else, then you have to realise that the user can change the boundary or even turn it off. I imagine that will destroy that scenario.

We need to start thinking about our scenarios a bit more. What I mean is, we need to think about what sort of scenarios we want to keep for the final application, and which ones we only want for testing. We need a goal, a target to aim for, so we can start working towards an end point. Well, maybe not exactly an end point, but some point where we can release it to the world. What does the user get out of it? Why would they want to look at it? Can we make it more configurable so that users can create their own scenarios?

We've created something good, but I'm not seeing where it is going from a user perspective. That's not usually a problem for me, as I develop things for my own understanding, but that hasn't always worked out. Take Atomic Viewer as an example. I had a great time building it, and learnt many things from it, but it doesn't really work as anything more than a viewer. It works well when connected to the Periodic Table page, but not so well if a user just jumps right into it. It lacks direction, or I failed to follow it. It was meant to be an editor where the user could create versions of elements for themselves, and it does support that but not in a nice way.

We need to determine what we want this app to be so that we can focus on that and make it work the way it needs to to accomplish that. On the one hand, we have created a good physics engine, but on the other, we don't really know what we want to do with it. We can think bigger than just a single web page too. This is an engine, so it can be the driver for multiple pages if we want it to be. We might remove the ability to select a scenario and just create individual pages for each scenario. Then I add a page to my site that contains the links to them all. Or we might leave in the scenario selection, but limit them to a certain area of study. So we might have a Gravity page that contains gravity based scenarios and another page for Charge Interactions, for example.

I will probably have to change the HTML pages into PHP scripts when I put them on my site. That is because I will want to define the pages in a database and have a common template for them all. I don't want to have to update a lot of individual pages in the same way all the time. That won't effect this project, which will remain as it is.

There are still things to do inside of the engine. Forces to finish, different particles to create, etc. However, I want to start thinking about actually publishing this thing. Even if only in a limited capacity at first.

.
Seeing as how I failed so miserably at conveying an idea of spin collisions last time, I felt I must try again. Before last Saturday, I first posted a garbled up version of this spin collision diagram a year ago. Even this diagram is still a draft concept. The sphere is the middle represents the particle at the moment of collision. The vector diagrams to the left and right show pre- and post-collision velocities. How do you show someone whether a particle’s spin collision is ‘correct’ or not?

I’m grateful for having concentrated on this problem, I came up with a great old idea that I believe will add quality and accuracy to the collision group and our model – the Armillary *. An armillary can show a location on Earth – its longitude and latitude, its horizon in space, and its daily and yearly orbits about the sun in the celestial sphere.


The particle armillary is slightly larger than the particle radius. It shows the particle's orientation with respect to the boundary universe - XYZ frame/celestial sphere, along with the particle’s velocity, orientation, collision location, spin axis and spin rate. It's way more sophisticated than the target grids - I would replace those target grids with armillaries. I should output a similar post collision armillary that we can compare to the model’s spin collisions. When colliding two particles, four armillaries – 2 each, before and after the spin collision - may be output, a function is needed.

I feel certain this is a good idea, still, I'd appreciate comments. The diagram is autocad, and the inset is from spin 01. Remaining lines that need doing include: 1. a small circle centered on the collision point, 2. the center of the particle to the collision point, and 3. the collision latitude circle.

How do I covey numerical information - should I make marker graduations? Would it be feasible to output text on the screen? If so, how? More important, I need to figure out how to calculate an output. I would like to parent/child this thing, such that I could rotate the particle (spin axis, rate, particle orientation, and forward velocity) within the XYZ frame; I’ll be delayed while I figure out or beg help (hint, hint) on some of this stuff.

* Armillary sphere. https://en.wikipedia.org/wiki/Armillary_sphere
.

So, basically, you want to show the linear and spin velocities, as well as some orientation markers. I'm not sure if the orientation markers will get in the way a bit or not. It feels like they will to me, but you never know until you try and even if they do, there might be something that can be done to help fix it.

However, our little Particles are not setup to handle that. You need to be able to place all of these markers in such a way that they do not rotate with the particle, but they still move with it. That can be done, but it is going to require a lot of the code to be updated. The problem is that we will need to alter the scene graph under each Particle so that we can separate the rotation from the linear velocity. They are currently both applied to the same object.

I'll make some changes to the Particle class, and alter any code that uses Particle to handle the new changes. Then you can use it to implement your markers. If you want me to, then I will also create a function that will generate a THREE.BufferedGeometry to represent an Axis Angle. That will be a bit tricky and I'm still not sure how to go about it, but I have some ideas. The main thing that gets in my way is that there is no top spin speed, no maximum value for it. Where-as a linear velocity vector can just get longer to represent the speed, a rotational marker can not.

A concern with these velocity markers is that they will need to be kept up-to-date. They need to be rebuilt on every frame and that is expensive.

Marking the collision point is also not so easy because there can be multiple points and you don't want them to only show for 1 frame, you need some sort of timer so that they fade away.

But let's worry about that once we are in a position to deal with it. I'll let you know when I have made the changes to Particle to support this stuff.

Ok. I have changed the Particles scene graph to allow 2 different marker groups. One will move with the particle and the other will move and rotate with it. Anything placed under these groups will do so as well.

You can use the Particle.addLinearMarker method to add a marker that will only move with the particle and not rotate. Use Particle.addRotationalMarker to add one that also rotates with it. You can also use the Particle.addMarker( node, rotate ) method, which allows you to pass in a boolean (rotate) that will determine which marker group it gets added to.

If you ever need to get the position of a Particle, then you should use the Particle.getPosition method. There is a corresponding setPosition method. Both of these methods take in a THREE.Vector3 to receive or pass in the position value.

More importantly, there are getOrientation and setOrientation methods that take THREE.Quaternion objects. This is more important because the orientation, and spin, are now applied to a different object.

.
Woah Nevyn! A new dynamic particle graphic is more than I had considered. My imagination/suggestion extended to static armillaries, 3D diagrams in the particle’s path in both pre and post collision locations so that way the user could compare them to the model particle’s pre and post collision states. Displaying measurements, angles and rotation velocities will involve effort.

Now that I’m thinking about it a new dynamic particle graphic might not be a bad thing.  

I take it you approve of the armillary idea?

Oh no, too late. I must see for myself. Thanks Nevyn.
.

.

I think I see one mistake, from the bottom left hand front corner of Lattice 03, the spatial index is now fixed and it erroneously rotates with the particle.

I’ll work with your instructions and report back later.
.

I fixed up the spatial index.

You won't be able to display text. Well, you can, but it is really expensive and not worth it. At least if you show the text as 3D objects. There may be other ways to do it that are cheap.

I don't see how you can show this stuff in a static way. It has to be dynamic or it will only work for a set scenario. The armillaries will be static, in that they do not rotate with the particle, but they must move with it.

I'm not completely sold on the idea, but it is worth seeing if it can help. I do like showing the velocities, we just need a good way to show a rotational velocity. I'm thinking of showing a line that curves around the particle (with a slightly larger radius than the particle) to show the angle of the spin. It will be oriented such that it goes around the axis of the spin. In your image above, you show the spin axis and equator, I imagine taking that equator and reducing it to reflect the angle of the spin. That is, the angle per second or traditional angular velocity.

The problem is that the angle of the spin can be larger than 360°. So we need a way to visualize that. We could use color to determine how many times it wraps around the particle. The hotter the color the more it wraps. Or we could show it by actually rotating the line around the particle a number of times. We just need a way to adjust the plane of the equator up and down so that the lines don't overlap each other. So if it wrapped around 3 times, then it would have a spiral from just above the equator to just below the equator. That sounds expensive though.

.
I like velocity and spin vectors too. A growing multi-color spiral around the equator to indicate a high spin velocity is a scary thought. Rather than have you dwell on that for a day or two, I thought I'd use a straight-line magnitude vector beginning at a tangent point some where on the particle's equator - in the direction of the forward spin - anywhere on the circle.

I believe the the straight line length of a forward velocity of 8 per some unit time should equal the straight like length of one particle rotation – 8 over that same length of time. Does that sound OK to you?  
.

Sure, that'll do for now, but I think it will get too confusing with both the linear and spin vectors pointing straight. Maybe create 4 vectors for the spin velocity, one at each quadrant. Then you should be able to see at least one of them no matter where you are looking at the particle from.

You don't need to worry about the 8:1 ratio for velocity. That has nothing to do with what you are doing now. Just show the velocity vectors and scale it by some constant. Adjust the constant until the velocity vectors are at a reasonable length most of the time. Don't judge it in the collision scenarios. Use one of the gravity scenarios where there are more random velocities set by forces and not by hand.

You'll want to create the velocity visualizations in the Particle.createNode method. This is the current implementation and a couple of other methods to show you what needs to be done.

Code:


 module.Particle.prototype.createNode = function( grp, geom, mat )
 {
  if( typeof geom !== 'object' )
  {
    geom = GEOM_SPHERE;
  }
  if( typeof mat !== 'object' )
  {
    mat = new THREE.MeshBasicMaterial();
  }
  // add base geometry
  var node = new THREE.Mesh( geom, mat );
  grp.add( node );
  // add mesh over base
  this.meshNode = this.createParticleOverlay();
  http://this.meshNode = new THREE.Mesh( GEOM_WIRE_SPHERE, MAT_WIRE_BLACK );
  this.meshNode.visible = module.SHOW_PARTICLE_MESH;
  grp.add( this.meshNode );
  // add the XYZ axis markers
  this.axesNode = new THREE.Group();
  var xLine = new THREE.Line( GEOM_LINE, MAT_LINE_X );
  this.axesNode.add( xLine );
  var yLine = new THREE.Line( GEOM_LINE, MAT_LINE_Y );
  yLine.rotation.z = Math.PI/2;
  this.axesNode.add( yLine );
  var zLine = new THREE.Line( GEOM_LINE, MAT_LINE_Z );
  zLine.rotation.y = Math.PI/2;
  this.axesNode.add( zLine );
  grp.add( this.axesNode );
  this.axesNode.visible = module.SHOW_PARTICLE_AXES;
 };
 
 module.Particle.prototype.createParticleOverlay = function()
 {
  //var g = module.createParticleOverlayGeometry( this.radius * 1.03, 20, 20 );
  var m = this.createParticleOverlayMaterial();
  var ob = new THREE.LineSegments( GEOM_WIRE_SPHERE, m );
  return ob;
 };
 
 module.Particle.prototype.createParticleOverlayMaterial = function()
 {
  return MAT_LINE_BLACK;
  //return new THREE.LineBasicMaterial( { color: '#000000' } );
  //return new THREE.LineBasicMaterial( { color: '#ffffff' } );
 };


Create a methods called createLinearVelocityOverlay and createSpinVelocityOverlay and corresponding createLinearVelocityMaterial and createSpinVelocityMaterial methods. The create*Material methods are called in the create*Overlay methods. The create*Overlay methods are called in the createNode method. We will need access to these object, so save them into variables on the Particle, just like the current mesh: this.meshNode = this.createParticleOverlay();

By doing it this way, the methods can be overridden in a sub-class if we want them to do something different.

Now, the problem is updating them. You do this in the update method.

Code:


 module.Particle.prototype.update = function( time )
 {
  // scale by time since last frame
  // and update particle properties
  if( this.moveable )
  {
    v.copy( this.velocity ).multiplyScalar( time.delta );
    this.object3D.position.add( v );
  }
  if( this.spinable )
  {
    q.setFromAxisAngle( AXIS_Y, 0 ).slerp( this.spin, time.delta );
    this.rotation.quaternion.multiply( q );
    this.rotation.quaternion.normalize();
  }

  // TODO add vector updates here

  this.meshNode.visible = module.SHOW_PARTICLE_MESH;
  this.axesNode.visible = module.SHOW_PARTICLE_AXES;
 };


In order to update the geometry, you are going to have to use THREE.BufferGeometry objects. You can find some examples in the existing code on how to use them, although they might be a bit more complicated than you want. Just ignore the vertex creation and look at the end of the functions where it actually creates the BufferGeometry. Your vertices will be much easier to create and you don't need normal, color or index data, just position.

In the update method, you access the geometry vertices through a THREE.BufferAttribute which you must retrieve from the BufferGeometry like this:

Code:


var attr = this.linearVelocityNode.geometry.getAttribute( 'position' );
// find the vector representing the point on the surface of the particle that the velocity vector starts at
var p1 = new THREE.Vector3().copy( this.velocity ).normalize().multiplyScalar( this.radius );
attr.array[0] = p1.x;
attr.array[1] = p1.y;
attr.array[2] = p1.z;
// set the point away from the surface of the particle that the velocity vector ends at
// scale by some constant
attr.array[3] = p1.x + this.velocity.x * VELOCITY_SCALE;
attr.array[4] = p1.y + this.velocity.y * VELOCITY_SCALE;
attr.array[5] = p1.z + this.velocity.z * VELOCITY_SCALE;
// mark the data for updating to the GPU
attr.needsUpdate = true;


Actually, put that code into its own method called updateLinearVelocityOverlay and call it from the update method so that it can be overridden as well.

.
I haven’t tried coding anything yet. It’s been a big family day here, and we’ve just finished straightening things up. I’ll recover in a bit, then get started.

I imagined the dynamic particle armillary as a marker ('node'(?)) with just one rotational element - the particle spin velocity vector - (OK, split into quarters, four straight line magnitudes will be rotating about the particle. Or not, just for starters.); all other elements will be linear.  

In order to make a new dynamic particle graphic I figured I would be working in cdm.js. I would have attempted to replicate the Particle Axes marker.

How do the static lines I’ve begun creating in Spin 01 relate to cdm? I suppose that Spin 01 will contain both static and dynamic armillaries for a good comparison check. What other js docs do I need to change – maybe the dat.gui?

Thanks for the additional information, you’ve confirmed my expectation about working in cdm, and that it’s more complicated than I realized.  
.

Yes, cdm.js is a bit of a mess. I've tried cleaning it up at various times, but some of that code really needs to be put into its own JS file(s).

You should only need to alter the Particle class, which is near the top of the file.

After you are done, or at least have something working, I'll make it so that you can turn on/off the velocity markers on a per Particle basis (may be helpful in some scenarios). You can probably see how to do that since it will mimic the existing application of velocity and spin. I will also make it a user selectable option to globally turn them on/off.

Don't rotate the spin velocity vectors around the particle. As cool as that sounds, it will not be so cool once the particles are moving themselves. The idea here is that they do not spin so that we can see them easily.

This is a bit different to the particle axis markers, as they are static, you just set'em and forget'em. That will be fine for the armillaries, which are also static, but not for the velocity vectors, so I thought it was worth showing you what needs to be done in the correct places. You can create the armillaries in the same way as the existing particle overlay. You won't need any code in the update method for those. Get it working first, then see if you can figure out how to share the armillary geometry and material, since they will be the same for all particles. Again, the overlays are already doing that so if you copy them you should be fine.

Don't worry about UI related controls for these yet. Definitely do not touch dat.gui, as that is the DAT.GUI library itself, not our usage of it. Just make them always on. Feel free to have a go at the UI, if you can see other controls that are similar. We can always fix it if it doesn't work (or just don't commit it).

No rush for this. I've got my cowboy hat and boots on playing Red Dead Redemption 2 (and loving it). So I doubt I will be doing much work on it unless needed.

.
Status Update. No joy, I haven't solved it yet. Worse, even though I haven't gotten very far, I made so many troubleshooting draft mode changes I had to Push them. I feel like I've turned the main into a branch.

You can use the Particle.addLinearMarker method to add a marker that will only move with the particle and not rotate.

I added a set of x,y and z circles to the Particle.addLinearMarker function - section, armillaryNode2, but I don’t see any evidence of the new Linear Marker. I added another set of circles – armillaryNode1 – just after axesNode in that createNode section that works well, but then of course the Universe axes are spinning as we know they shouldn’t. I go into some detail in cdm.js beginning on line 767. I didn't see any outcome until I added the additional Graphics to test.html, SHOW_PARTICLE_ARMILLARY1 and 2 choices.

Your help is always appreciated.
.