Possible Charged Particle Field

Page 13 of 14 Previous  1 ... 8 ... 12, 13, 14  Next

Go down

Re: Possible Charged Particle Field

Post by Nevyn on Sun Sep 16, 2018 12:42 am

To see the new branch do a Fetch and check the fetch all tags option.
avatar
Nevyn
Admin

Posts : 1233
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Sun Sep 16, 2018 10:39 am

.
I fetched all tags, and see your new scenarios and ambient-charge branches.

An AmbientChargeForce that creates an attraction to other particles that block the ambient field.
Push gravity! Added realism and complexity, especially given our limited particle emission ranges.

If you wish, I’ll checkout and review the new branches more carefully.

Feel free to merge your branches back into the main whenever you see fit. I have no outstanding changes needing to be committed. Besides reviewing your changes, my next planned working task was to figure out how to rotate polyhedra and add to the spherical configurations. Of course I noticed that each of them are fat - involving more than their fair share of code - I’ll try to simplify them further - I certainly appreciate the need to reorganize.

If I do wish to make changes later today, I'll let you know. I'd be sure to be on the main, and fetch first.
.

LongtimeAirman
Admin

Posts : 937
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Sun Sep 16, 2018 4:53 pm

The scenario branch has been merged with master, but I have kept the ambient-charge branch separate for now. I don't know how to feel about the new ambient charge force. It looks cool and works well, but I can't see the difference between it and gravity. I have set the radius for ambient interactions about twice as large as the charge emission radius and have been playing with the strength of it. Too large and everything clumps together. Too low and it doesn't make much difference.

I have also created a Spatial Index to help. It takes the interacting particles and determines which ones block each other so that the outer particle will not receive any charge from the current emitter. It also looks back in towards the central particle to see which ones block the ambient field.

I may have fixed the collision problems, but I think it would still be possible to get them to happen again. The whole model now runs as if it had a constant frame rate of 120 frames per second. It ignores real time and just tells the code that only 1/120 of a second has passed since the last frame. This should make things more consistent since it removes any outside interference by other programs using the CPU. I ran one of the collision tests and it did not have any problems. However, I think I also reduced the amount of velocity that it creates before that and haven't gone back to test it at the original value again.

One consequence of using a constant frame rate of 120 is that it means all motion is effectively halved. Actually, it can be worse than halved as it depends on how many frames per second the system is running at. Let's say you are getting 60 fps, then the motion is effected by 60/120 = 1/2. If you only get 30 fps, then it will be 30/120 = 1/4.

That is what I wanted though. By setting such a high virtual frame rate, it means every velocity jump is smaller so it can avoid the overlapping problems. Of course, there is some point where it comes back again, but that may be larger than we really need.

See if you can break the collisions again.
avatar
Nevyn
Admin

Posts : 1233
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Sun Sep 16, 2018 11:47 pm

Airman, one problem I had when refactoring the scenarios, is that the gridLattice function was shared between the Lattice group and the Colliding group. If you look at those 2 files (js/scenario/lattice.js and js/scenario/colliding.js) you will see how I solved that. I had to expose a module from the Lattice scenarios that contained the gridLattice function which the Colliding group them picked up for it to use. None of the other scenario groups had to do anything like that, and it is not a big deal, I just wanted you to be aware of it and why they differ from the others.
avatar
Nevyn
Admin

Posts : 1233
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Mon Sep 17, 2018 8:53 am

I have fixed a few bugs and rebased the ambient-charge branch on top of master again. This led to a forced push, so make sure you do a Fetch before you do any work.

I've had the charge shaders turned off and didn't realise that I had broken them when I changed the way time is handled.
avatar
Nevyn
Admin

Posts : 1233
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Mon Sep 17, 2018 11:17 am

.
I’ve fetched and pulled your latest changes. The first thing I noticed was that the charge emissions are more visible, moving slower than they did before. I can clearly see that the action is about half the speed. Using collision test 03 as a benchmark, just 6 of the 16 incoming neutrons are colliding with the protons on the left surface. By doubling the neutrons’ initial velocity I can increase the number of proton/neutron collisions to 12 out of 16, about where they were yesterday.

I believe the apparent acceleration rate of a neutron into a proton pole is more accurate now. The reason you're seeing less collision errors is due strictly to the current speed reduction, the collision overlap errors are still there.

If you’re happy with the 120 timing, (I am), it’ll be necessary to increase most of the scenarios’ initial forward and spin velocities. If you agree, I'll go ahead and do that.
.

LongtimeAirman
Admin

Posts : 937
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Mon Sep 17, 2018 12:45 pm

.
the charge profile is a true representation of the charge emission calculations, at some specified radius from the emitter.
I have a possible scenario idea. Not knowing how the charge sampler/profiler or charge blocking works yet, my idea may not be reasonable. What do you think?

Can neutrons cast shadows? Probably not, but it might be an easy change. Test your success at obscuring - blocking - the charge field. In the Unmoveables scenarios, extend the proton's charge sampler/profiler out beyond the neutrons surrounding the protons. I'm curious what if any shadows are cast. A separate comment - it seems the program is behaving correctly in that the proton's charge emissions don't ever seem to "penetrate" neutrons.

I've spent time within protons to get an inside-out perspective. The scenario might begin from inside a proton, observing the neutrons and the surrounding sampler from that central position -seeing how things line up. One can then move away from that central position to see the 'actual' shadows cast on the system sampler.
.

LongtimeAirman
Admin

Posts : 937
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Mon Sep 17, 2018 7:18 pm

LongtimeAirman wrote:I’ve fetched and pulled your latest changes. The first thing I noticed was that the charge emissions are more visible, moving slower than they did before. I can clearly see that the action is about half the speed. Using collision test 03 as a benchmark, just 6 of the 16 incoming neutrons are colliding with the protons on the left surface. By doubling the neutrons’ initial velocity I can increase the number of proton/neutron collisions to 12 out of 16, about where they were yesterday.

There is a second effect of setting a constant frame rate that is larger than we had before. Every time a velocity (or spin) is added to the position (or orientation) of a particle, it is now half (or there-about) the distance that it was before. This means that the particle is half as close as it would have been before. Therefore, the forces applied to that particle now occur twice as often as before. There is an inverse relationship between velocity applied and force applied. If the velocity is changed by 1/n, then the force is changed by n, just because it is applied more often.

LongtimeAirman wrote:I believe the apparent acceleration rate of a neutron into a proton pole is more accurate now. The reason you're seeing less collision errors is due strictly to the current speed reduction, the collision overlap errors are still there.

Yeah, I thought as much. There is a limit to the top speed that can be applied to the model. Ideally, you want a max velocity that causes a change in distance that is smaller than the size of the things it is moving. About 1/10th to 1/100th. This is why you don't see many overlapping issues when it is just the forces applying velocities. The charge force is about 0.1 at maximum compared to the radius of the particle which is 1. That makes it about 1/20 of the size of the particle (using diameter, not radius). However, that is in real world units, so the velocity is divided by the time between frames when it is applied to the position of a particle. Therefore, a velocity of 0.1 would become a change in distance, per frame, of 0.1/120 = 1/1200. That gives us plenty of room to build that velocity before it causes troubles.

The trouble begins when the velocity can cause a change in distance that is larger than the radius of the particle. That allows 2 particles to actually cross each other during a frame transition, but still be considered to be in a collision. Let's figure out what that velocity is.

Let:
r = radius of particle = 1
d = change in distance caused by velocity = r (really we want something smaller than this)
fr = frame rate = 120
t = 1/fr = 1/120
v = max velocity

v = d/t
d = vt

Then:
d = v / fr
v = d * fr
v = 120

Now we need to include the radius. We can see that increasing the radius will allow a larger velocity because each particle takes up more space.

v = r * 120
v = r * fr

Therefore, the maximum velocity is equal to the number of frames per second (when the radius is 1).

See if you can verify that math. Maybe create a vertical line of neutrons that are moving horizontally towards another line of stationary neutrons. Much like the existing collision scenarios, but just a single line to collide with instead of many in a row. Increase the velocity of the moving neutrons from top to bottom in set amounts up to and over the frame rate. You could increase the velocities, from top to bottom, by 20 (with the first one at 20) and have 7 rows so the last row is 140. I predict that the troubles should start in the 2nd last row and definitely in the last row.

LongtimeAirman wrote:If you’re happy with the 120 timing, (I am), it’ll be necessary to increase most of the scenarios’ initial forward and spin velocities. If you agree, I'll go ahead and do that.
.

I'm not so sure I want to keep the 120 timing. I would prefer a value closer to the actual frame rate (so 60ish). Ideally, we would actually calculate the strength of forces based on the target frame rate. This would allow us to choose a frame rate to set the precision of the model without that changing all of the interactions. If we set all forces based on a frame rate of 60, then set the target frame rate of 120, it would calculate all of the forces to be 1/2 as strong (60/120). Since all forces would be applied twice as often, that equates to equal forces independent of the frame rate. The interactions would still be different, but the differences would be because of the increased precision.

The problem with that approach is that our scenarios would need to be changed along the same lines. We would need a way to calculate the velocity we want for the scenario. Currently we are just setting arbitrary values, but we would need to get a bit more formal in how we do that to allow an arbitrary frame rate. That might not be as bad as it sounds though. When the model begins, I could re-calculate all of the initial velocities and spins to make them fit the specified frame rate. We would choose the velocities we set based on 60 frames per second and the model will adjust them to suite the actual frame rate used.

I think this is worth looking into. It will create a much better framework. I like being able to set the precision in as many ways as possible. I have recently provided ways to set the precision of the ChargePoints (by using more of them) and of the charge emission (by having more values in the CHARGE_DENSITY array). Adding the ability to set the precision of motion would be great. I'll have a look to see how feasible that is.

So if you want to rectify the current scenarios, I would suggest that you change the target frame rate from 120 to 60 and then set the scenario velocities based on what works. You can set that frame rate in test.html, near the bottom of the file where it creates the modelTime variable (in the latest code).
avatar
Nevyn
Admin

Posts : 1233
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Mon Sep 17, 2018 8:13 pm

LongtimeAirman wrote:.
the charge profile is a true representation of the charge emission calculations, at some specified radius from the emitter.
I have a possible scenario idea. Not knowing how the charge sampler/profiler or charge blocking works yet, my idea may not be reasonable. What do you think?

Can neutrons cast shadows? Probably not, but it might be an easy change. Test your success at obscuring - blocking - the charge field. In the Unmoveables scenarios, extend the proton's charge sampler/profiler out beyond the neutrons surrounding the protons. I'm curious what if any shadows are cast. A separate comment - it seems the program is behaving correctly in that the proton's charge emissions don't ever seem to "penetrate" neutrons.

I've spent time within protons to get an inside-out perspective. The scenario might begin from inside a proton, observing the neutrons and the surrounding sampler from that central position -seeing how things line up. One can then move away from that central position to see the 'actual' shadows cast on the system sampler.
.

I feel like you just disarmed me and are now pointing my own weapon at me! Very Happy

Yes, it would be good to visualize that code so that we know that it is working correctly. I am confident that it is, because I can see the results of it in various scenarios, but confirmation is always good.

I'm not sure how to go about that at the moment. I'll give it some thought and see what I can come up with.
avatar
Nevyn
Admin

Posts : 1233
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Tue Sep 18, 2018 5:40 am

I have created a visualizer for the spatial index.



This was a bit trickier than the charge field sampler, because the charge field is the same for all protons. I could create one geometry to represent it and share it among all of the protons. Simple and efficient. This even allowed me to use more precision than I thought I would. However, every particle has its own spatial index (conceptually, the code is written such that one spatial index is used for all particles but only represents one of them at any given time). Every one of those indexes is rebuilt on every frame. That meant that I had to find a way to visualize all of them, without using up too much time.

I solved it by creating a cone for every blocking particle of some target particle. The cone is rotated such that it points towards the center of the target particle, from the direction of the blocking particle. This creates a small circular geometry poking out of the target particle. I was originally going to have it black and transparent, to mimic a shadow, and that does look awesome, but it is very inefficient and not worth that cost.

They look pretty cool as they dance around the surface of a particle. Following the particles around it. There is a new menu item in the Graphics menu to turn them on/off.

I have updated my site with the latest code on the ambient-charge branch. This includes some important bug fixes too. I made a small change to the spin math that seems to be helping a lot.

https://www.nevyns-lab.com/mathis/app/cpim/test.html
avatar
Nevyn
Admin

Posts : 1233
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Tue Sep 18, 2018 6:07 am

I added spin to the collision code, but it doesn't work correctly some of the time.
avatar
Nevyn
Admin

Posts : 1233
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Tue Sep 18, 2018 6:51 pm

.
Et Touché to you Sir. I ask for a simple single surface system charge sampler showing the proton charge blockage by all the other particles inside the sampler radius (or something like that); and you go and display the ambient charge system received by each particle, showing on its surface where all other particles block the ambient field. Wonderful. You solution is far superior, and extremely thought provoking. For example, linear repulsion due to charge emission should occur primarily in the yellow areas.


The ‘Blockages’ – you showed us the four Body configuration in your previous post. Here we see another configuration close-up, outside of the Unmoveable - arrange about Y. All the particles are wearing their shades. On the nearest neutron’s surface we can clearly see the tips of the yellow cones you described above, slightly taller than the neutron diameter pointing diametrically opposite to the ambient charge blocking particles. By the way, Blockage sounds like a painful ailment, please consider changing to Ambient Umbra, Particle Image, just not Blockage. At first I thought your charge profile effect was comparable to an incandescent light bulb surface. Now I must interpret both cone ends as a particle image system. This new Blockage is a primitive eye; not only can it see in any direction, we are able to see all the images of the nearby particles it sees. Please consider, a proton should register as a charge source, a hotter color than ambient blocked yellow.  


And then there’s gravity. Where’s this so called gravity you speak of? Well here we see an example. These 9 neutrons began at the vertices of the distant pentagonal dodecahedron – above and right of the image center, driven away from that location by a proton which went in another direction. This group of neutrons is slowly milling about, actually getting closer together as the group travels further afield, by the attraction due to the blocking of ambient charge.

And collisions with exchange of angular momentum! This program you’ve created is amazing. It's taking on a life of its own. Yeah, I’m more like the sorcerer’s apprentice.

I haven’t gotten to the possible new collision configuration or timing task yet. On timing, I noticed your latest merge correction involved the timing section in test.html that you directed me to. I believe I found some discussion on the issue. I believe the following expands your description. 
https://gafferongames.com/post/fix_your_timestep/
Fix Your Timestep!
How to step your physics simulation forward
Posted by Glenn Fiedler on Thursday, June 10, 2004
.

LongtimeAirman
Admin

Posts : 937
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Tue Sep 18, 2018 8:17 pm

For most scenarios, the spatial index visualizer works fine. However, if there are many particles, especially if they are close to each other, then the processing time becomes a problem. You will see slow down. Since we are working on a constant frame rate, this will not effect the interactions, but it will look bad.

To combat that, I am thinking about creating another visualizer that is less time consuming to process. This will mean it won't be able to use large constructs like the cones that the current version does. It will need to use something simpler, like lines. I don't really want to use lines, because we have used them for 2 purposes already, 1 to show the particle axes and another to show the charge point locations, but they are the most efficient geometry for the problem. I will have to use color to differentiate them.

The beauty of using lines is that it becomes just one object to represent all blocking locations for a given particle. The cones require one object (mesh) per cone, since the cone is the object. With lines I only have to update the geometry of the line to change the locations and one object then renders all of those lines. Given the name, you are probably thinking that a line object only represents a single line, but it doesn't have to. You can render lines in a number of ways and the way I will render them is for each pair of vertices in the geometry to be rendered as an individual line. This allows me to have many lines in the geometry, but only a single Line object to render them.

Lines do have some limitations, but they aren't difficult to handle. Mostly, the problem is that it will need some idea of a maximum number of lines to handle, per particle. While I can change the points that create the lines, it is not ideal to be changing the number of lines in a given geometry. That is because you want to avoid creating new data every frame. That is expensive, or at least it can add up to expensive. So I will set some maximum number of lines and any that I don't need will be set to 0 length, so they are not visible. If I need more, then I might try adjusting the size and see if it works ok, if it is only something that happens every now and again (probably just on the first frame usually) then it might be fine, or I might just not render those blockages. I should be able to have a setting to switch between the two easily. Not a user setting, just a choice you make in the code.

Now that I have the math figured out, it is easy to create different visualizers. I didn't go into the details of the spatial index before but it is probably worth it.

Firstly, what is a spatial index and why do I want one?

Let's back up a bit and just look at what an index is. Think of a technical book. It contains 1000 pages of dense data and even knowing that something you want is in there, it is difficult to find it. So you go to the front of the book and look at the Table of Contents, which will be a list of chapters specifying their names and pages. That is an index. It is a quick way to find data. You don't need to sift through 1000 pages, you just look through 10 or so chapters, find the one that gets you close and go there for a closer look for the specific information you want. You have reduced your search from 1000 pages to 100 or so. A 10 times reduction in effort. If you are lucky, each chapter might have its own index so you can quickly get to the exact content that you want with only a few pages to search through. If that reduced it to 10 pages, then that is a 100 times reduction in effort just from 2 indexes.

Indexes are how databases can search large datasets quickly. Say we had a database containing every street in a country. I have worked with such datasets and even in a small country, there are a lot of them. However, each street record specifies the suburb, city and state that it is in, so we create indexes on each of those fields (or we could create an index on all 3 at once, but that is another story). Given a query to find all streets in a given state, city and suburb, the database will use all of those indexes to quickly find the records that you asked for. It will use the state index to reduce the data to only records with a matching state. The city to find matching cities and finally the suburb to find the exact records to return. Each index reduced the number of records to handle and got us closer to the data we want.

A spatial index is used for the same purpose, but it represents spatial information. Spatial just means space, or distance, related data. Think geometry and geography, although they are not really the same exact thing, just closely related. When working with spatial data, we might be asking questions like 'what streets are inside this circle' or 'what streets intersect this other street'. As you can imagine, checking whether every single street touches a circle is an extremely expensive operation. So, before we run any queries, we create a spatial index that will allow us to narrow down the records that might touch that circle. The index doesn't know anything about the circle, it just gathers up information about the geometry that it is given. So it might record the bounding box of every street so that you can just check the bounding boxes first, and then only check the real geometry with the results from that. Real spatial indexes will do that over several size ranges. It will take the actual bounding box (the min and max of every vertex in the geometry in all dimensions of interest), add that to a larger box, add that to a larger box, etc, etc.

A typical 2D spatial index is called a Grid Tree Index, and it works by taking the largest bounds, say the size of the country, and a depth. It then splits the bounds into 4 rectangles, then it splits each of those 4 into 4 more until we reach the specified depth. Now we can take our search criteria, say a circle, and for each layer (of depth in the index) we find only those rectangles that it intersects. Then we dig down to the next layer and find what it intersects there, and so on and so on, until we reach the real data and the actual geometry is tested (if you even want it to test the geometry). See how each layer reduces the data to what is close to the circle of interest? If the data was spread out evenly over that index (usually not the case), then each layer will reduce the number of items by 4. If the index is 4 layers deep, then it will reduce the number of records by 4*4*4*4.

That is a normal spatial index, but there can be others that might target a specific problem. Which is what I have created for this app. Firstly, it does work like the index above, in that it only records particles that are within a certain distance, but I am mostly using it to find the particles that are in a line from the perspective of the target particle. That is, if you were the particle and looking outwards, then what other particles block each other from view.

To accomplish that, I converted the Cartesian coordinates into Polar coordinates (thanks Airman, you gave me that idea by mentioning them recently). Polar coordinates do not use X, Y and Z values, but use Length, Inclination and Azimuth. The length is the distance to the point, the inclination is an angle from the Y dimension and the azimuth is an angle from the Z dimension. By using angles, it becomes very easy to find particles that are in line with each other because their angles will be close to each other. Then we use the distance (or length) to determine which one is in front of the other. Fairly simple once you have the data in the correct coordinate system to handle it.

I will be adding to the spatial index, over time. It becomes a central place to make calculations that might be used in multiple places, but those places are quite separate in the code. That is, I don't want the Charge Field to know anything about Gravity, but they both might want to know the distance from one particle to the other. So I calculate that in the index and share it with both, or all, forces. Now we only calculate that distance once, no matter how many forces require it. Unfortunately, creating a spatial index is a bit expensive itself, so we do lose some performance just by using one, but we can gain some things back by sharing data.
avatar
Nevyn
Admin

Posts : 1233
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Tue Sep 18, 2018 8:47 pm

Ahhh! I knew those little tips should be poking out the other side, but I couldn't see them (and didn't look too hard). I'll deal with that.

I'm happy to rename it from Blockages, I couldn't think of anything last night and just went with that.

I don't think it needs to differentiate between charged particles and non-charge particles. It isn't being used to deal with charge emission or reception, only the ambient field. Well, it actually is used for charge reception since it will only accept charge from the closest particles and ignore blocked ones, but the index doesn't care what is blocking, just that something is. Strictly speaking, it should not register a charged particle as blocking, since it will supply charge, but it is still blocking the ambient field and that is what I am trying to show. However, I might give it a go and see how it looks. Maybe knowing that it is blocked by a charged particle will be beneficial. It has the data to work it out, and it only requires the changing of a Material to render it a different color.

While the ambient charge field does resemble gravity, I have turned down the ambient charge field strength so that it is too weak to be gravity. Having a high ambient field strength broke most scenarios. Even the current strength breaks a few since they were not built with it in mind. For example, my new Unmoveable scenarios did not make the central proton unmoveable, because there weren't any forces to move it, but now there is so I had to change them.

The first time I tested the ambient field, it had a large field strength, and did indeed resemble gravity. Protons started to move towards and then around each other. I was impressed and a bit startled at the same time. I didn't want gravity, but seemed to have it anyway.
avatar
Nevyn
Admin

Posts : 1233
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Tue Sep 18, 2018 9:44 pm

Later, much later, we could create an ambient charge field force that is directional, which would represent a common source of the ambient field such as the surface of the Earth. Another implementations could be from a point source, which would represent the Sun in a solar system scenario. Not sure if we want that or not, but it might be useful.

Essentially, the ambient field works much like a light source in a 3D model. They are quite different in the specifics, but quite the same in the generalities. If you look over the ThreeJS documentation for Lights, you will find ones that resemble our needs for the ambient field. We currently have what is called an AmbientLight because it doesn't have a source, it just represents light coming from everywhere. DirectionalLights have a direction, but not a point of source, so they just always point in that direction irrespective of where they are in the world. PointLights are what we commonly think of as lights, as they have a definite position in the world and a direction that they are pointing.

I'm not sure if we can get this model to work at larger scales. It seems feasible at the moment, but I haven't been too concerned with that up to this point. I mainly think about the quantum world, not the macro.
avatar
Nevyn
Admin

Posts : 1233
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Wed Sep 19, 2018 8:47 am

I created a second visualizer that uses lines to show the directions that the ambient field is blocked. It is a lot more efficient. You can make the lines a solid color, but I have also implemented per-vertex-colors which fade the line from black to yellow from the outside-in. This gives it a bit of a fade effect.



The online version has been updated. If you watch the blockage lines (I haven't renamed it yet) you may notice that they move when it seems they shouldn't. This is caused by the spatial index being a frame behind the currently rendered particles because it is created based on the current positions and then used to calculate the new positions. However the visualizer renders the index as it is this frame, so it is actually a frame behind visually.
avatar
Nevyn
Admin

Posts : 1233
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Wed Sep 19, 2018 11:05 am

.
Quick review of the latest on-line version.

The new visualizer blockage lines are neat. The only downside I see it that the cones could convey proximity, where a single line cannot. As a compromise, would it be too expensive to show the blocking lines for each of the nearby particle’s Cardinal or charge Points?

The ambient charge attraction has broken collision test 03, the proton lattice particles drift out of position before the incoming neutrons arrive. Even if I made the protons unmoveable, the incoming neutrons are also shifting their positions before they arrive at the lattice. All particles will need to be initially positioned with increased separation.

SixPoint sphere is displaying a new bug – disappearing particles. I suppose the collision velocity is too high, but not that high.
.

LongtimeAirman
Admin

Posts : 937
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Wed Sep 19, 2018 3:01 pm

v = r * fr  
...  
See if you can verify that math

A tasking! Involving program timing. An important subject of which I was woefully ignorant. I had to make the time to read some additional sources on the subject. You explained the frame rate velocity limit very well. It makes perfect sense that in order to avoid the possibility of objects - of a given size - moving fast enough to pass through each other in between frames, a given simulation would have a velocity 'limit' (object radius equal to one) based on the frame rate.  v = r * fr . Let me say, I don't see any of our sim's velocities anywhere near that limit.

So if you want to rectify the current scenarios, I would suggest that you change the target frame rate from 120 to 60 and then set the scenario velocities based on what works. You can set that frame rate in test.html, near the bottom of the file where it creates the modelTime variable (in the latest code).

Having understood and completed the first tasking, I'll proceed with the second. I'll change the frame rate to 60, and start organizing the initial velocities as you've suggested. I'll only delay the change to the main until I've set up the next collision configuration demonstrating the fps limit.

P.S. Oops. Demonstrating the frame rate velocity limit.
.


Last edited by LongtimeAirman on Wed Sep 19, 2018 3:58 pm; edited 1 time in total (Reason for editing : Added P.S.)

LongtimeAirman
Admin

Posts : 937
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Wed Sep 19, 2018 6:36 pm

LongtimeAirman wrote:The new visualizer blockage lines are neat. The only downside I see it that the cones could convey proximity, where a single line cannot. As a compromise, would it be too expensive to show the blocking lines for each of the nearby particle’s Cardinal or charge Points?

The cones didn't convey proximity. They could, by having a larger base that had the same angle as that made with the blocking particle, but they didn't, and that would be too expensive. Even more expensive than they already were because it would mean creating the geometry for every cone on every frame. I toyed with the idea of using color shading to convey distance to the blocking particle on the line visualizer, but I liked the fade effect more. There is a setting on the new line visualizer that will render the lines all the way to the blocking particle. It creates some interesting patterns.

LongtimeAirman wrote:The ambient charge attraction has broken collision test 03, the proton lattice particles drift out of position before the incoming neutrons arrive. Even if I made the protons unmoveable, the incoming neutrons are also shifting their positions before they arrive at the lattice. All particles will  need to be initially positioned with increased separation.

Yeah, that is a problem and I want to start fixing it in a more developer friendly manner. The issue is that we have created all of these scenarios using absolute coordinates based on how it works at the time of creation. We then change something and it breaks them because the underlying assumptions are different. We can't always fix those sorts of problems before they arrive, but we can make things a little easier in some regards.

The first one to handle is positioning of particles. If we want to avoid protons interacting via their charge fields, then we place them 10 units apart because we know that that is the min distance before interactions take place. What we should be doing is using some variable to set that number. And the value is already available through some recent changes that I made when I refactored the scenarios. If you look at cdm.js, you will see the creation of the module at the top of the file. That contains a lot of variables, some of which are constants and some of them are changeable. You will notice that the first 7, under the comment '// particle settings', specify things like the RADIUS and MASS, more importantly, it specifies the EMISSION_RADIUS and AMBIENT_RADIUS which tell you the distance from a particles center that emission and the ambient field can cause interactions.

If you want to use them in the test.html file, then you reference them like this:

Code:
PIM.EMISSION_RADIUS

So you could set a particles position like this:

Code:
particle.object3D.position.set( PIM.EMISSION_RADIUS, 0, 0 );

If we do that for all scenarios, then we can easily change the value of EMISSION_RADIUS and everything will remain intact.

LongtimeAirman wrote:SixPoint sphere is displaying a new bug – disappearing particles. I suppose the collision velocity is too high, but not that high.

Yes, I noticed that on a few scenarios. Some of the scenarios with 3 particles that group together will eventually disappear. I haven't looked into it, but I am assuming it is related to the addition of spin to the collision code. Something is getting a value that is NaN (Not a Number) and the math explodes.
avatar
Nevyn
Admin

Posts : 1233
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Wed Sep 19, 2018 6:44 pm

LongtimeAirman wrote:I don't see any of our sim's velocities anywhere near that limit.

The limit is 120 now, but it was around 60 before I made it use a constant frame rate. The scenarios in the Colliding group were creating velocities that high because they would start at 20 and then multiply the loop counter by some value to add to it. This could easily create velocities over 60 which is why they showed the collision problems (which is what they were meant to do). Having said that, I remember even the slowest line would show collision errors, although not as often, and that didn't look like it had a velocity that high.
avatar
Nevyn
Admin

Posts : 1233
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Thu Sep 20, 2018 4:09 am

I added the ability to show whether it is a charged particle blocking the ambient field by using a different color. It works on the old cone based visualizer as well as the line visualizer, but I did have to create a new line visualizer for it. You can't change the color if it uses a solid color for the lines. However, when it uses the per-vertex colors, it can. So I made a new class that extends the old one and changes things to use per-vertex colors.

I have changed the ChargedParticleMotionEngine class so that you can enable/disable gravity and/or the ambient charge field. If both are disabled, then it will create a ChargeProfile for the charged particles that will contain an attraction at the poles. This changes the model so that it runs as it did before I added the ambient field code.

Then I merged the ambient-charge branch back onto master.

Finally, I created a first cut of gravity. It is a bit rough and unbalanced, but functional.
avatar
Nevyn
Admin

Posts : 1233
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Thu Sep 20, 2018 1:43 pm

.
The frame rate of the main has been set to 60. I corrected my typos in sixPointSpere and added collisionTest04.

You suggested the new collision configuration be a single row of stationary neutrons and a second row of moving neutrons that will collide with the first. I thought two long parallel lines involve distortion, with difficulty approaching the close-up views of the ends, so I substituted a stationary ring instead of a stationary row - like the Unmoveable - arrange about Y. It also forced me to study initSpinTest.

15 incoming neutrons in a long spiral configuration colliding with a stationary ring of 15 stationary neutrons below. The velocities are variables instead of arbitrary values. The velocities shown are 10, 20, 30, … , 150. Collision errors occur at around 120.

I was anxious to make my three changes. Couldn’t help but notice your 21 changes ‘overnight’ – you’re a monster. I’ll work a bit more on collisionTest04, trying to figure out how to stagger the incoming neutrons better and how to push line segments showing where the deviations from the ideal final stationary positions occur.

I’ll also be reviewing each scenario to ensure their compatibility with the 60 frame rate.
.

LongtimeAirman
Admin

Posts : 937
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Thu Sep 20, 2018 6:26 pm

You should make use of the new ChargePointMotionEngine properties to disable gravity and the ambient field. Then the collisions can be studied in isolation.

In js/engine/charge-point-engine.js, around line 544, you will find the ChargePointMotionEngine constructor:

Code:

 module.ChargePointMotionEngine = function()
 {
   module.MotionEngine.call( this );
   this.applyGravity = false;
   this.applyAmbientChargeField = true;
 };

Change those boolean properties to false. You can do it in test.html where an instance of this class is created. At the end of the init function, you will see these lines:

Code:

 engine = new PIM.ChargePointMotionEngine();
 engine.init();

In between those lines, set the properties like this:

Code:

 engine = new PIM.ChargePointMotionEngine();
 engine.applyGravity = false;
 engine.applyAmbientChargeField = false;
 engine.init();

I will make some changes so that these types of properties can be written into the scenario functions. They should be set on a per scenario basis, not globally like this, but it will do for now. All I need to do is move that engine constructor call to somewhere before the scenario has been setup.

Actually, you can do that if you want. This is a larger piece of that code:

Code:

 initParticles();
 
 initialState = particleArray.getState();
 
 engine = new PIM.ChargePointMotionEngine();
 engine.init();

Change it to:

Code:

 engine = new PIM.ChargePointMotionEngine();

 initParticles();
 
 initialState = particleArray.getState();
 
 engine.init();

The scenarios are setup in the initParticles function, so that should allow the engine to be modified within the scenarios. I hope it doesn't break anything. I can't think of anything that it would break at the moment, but I'm not at home to check or do it myself. Give it a go, and if it fails, then just go to the first suggestion above and I will deal with it when I can.

To access the engine in a scenario JS file, you may need to use its formal name, which is window.engine. The window object is always available and represents the page you are on in the web browser. It contains all sorts of stuff that can be useful, but most importantly, it is the global variable space. If you declare a variable at the top level of a script tag in the HTML, or in a JS file, then it is actually being stored on the window object.

Actually, scratch that, I just looked in one of the scenarios and it is accessing the camera variable just fine without using the window qualifier. You should be able to just access engine in the same way.

Airman wrote:Couldn’t help but notice your 21 changes ‘overnight’ – you’re a monster.

Most of those changes were from the merge of the ambient-charge branch, so they are really a weeks worth of work (or just work over a week, really, not full time effort).

Airman wrote:15 incoming neutrons in a long spiral configuration colliding with a stationary ring of 15 stationary neutrons below. The velocities are variables instead of arbitrary values. The velocities shown are 10, 20, 30, … , 150. Collision errors occur at around 120.

I'm surprised the errors started at 120 if you set the frame rate to 60. Maybe my math is a bit wrong.
avatar
Nevyn
Admin

Posts : 1233
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Fri Sep 21, 2018 1:41 pm

.
I'm surprised the errors started at 120 if you set the frame rate to 60. Maybe my math is a bit wrong
I'm not certain of errors started at 120, we really haven't looked closely enough yet.

Supporting documentaion!


So I added starting lines to Collision Test 04, stretched out the collision events a bit and tied the particle separation positions to the proton emission radius as explained by the diagram – using the ‘global variable’ EMISSION_RADIUS.  

Ok, where's gravity, there’s lots I haven’t seen yet. I wouldn't think of disabling the ambient charge or gravity during any collision test.

I've been thinking about lists and indexes, how one should code with them instead of objects.

Plenty to do, thank you very much.  
.

LongtimeAirman
Admin

Posts : 937
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Fri Sep 21, 2018 11:14 pm

.
Ok, I did see gravity and the ambient charge at play with the other three Colliding Tests Scenarios. I almost wanted to not fix them because they were so interesting. Watching the particles interact like a kid's air driven table-top football arena with miniature player/particles. All colliding and milling about all while remaining on the same plane. Moving targets, upsetting the intended collisions. So I see why one would want to switch off gravity and ambient charge after all.

By the time I saw that you (Nevyn) had installed said gravity and ambient charge switches, I had already increased the particle separations to 2.2*PIM.EMISSION_RADIUS. They are no longer broken, with or without gravity and ambient charge. I probably won't use them there, but I feel better knowing they are there.

I’m currently on Test 03 velocity change. I’ll be getting to the Lattice group next.

Thanks for the pass from a couple of weeks ago, I’ll be offline for the next day or two.
.

LongtimeAirman
Admin

Posts : 937
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Sponsored content


Sponsored content


Back to top Go down

Page 13 of 14 Previous  1 ... 8 ... 12, 13, 14  Next

Back to top


 
Permissions in this forum:
You cannot reply to topics in this forum