Miles Mathis' Charge Field
Would you like to react to this message? Create an account in a few clicks or log in to continue.

Possible Charged Particle Field

4 posters

Page 6 of 15 Previous  1 ... 5, 6, 7 ... 10 ... 15  Next

Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn Thu Sep 13, 2018 12:57 am

What I will do is change the current SimpleChargeProfile class to take in an array of values to use in the constructor, instead of it using the constant CHARGE_DENSITY. The default will still use that constant, but it will allow us to override it if we want to.

I will then create a template, which will be commented out, of the classes that would be needed to create a new version. Then you can copy that template code, paste it outside of the comment and tailor the class names and the code in them for your specific needs. I will thoroughly document it to help you see what needs to be done and why.

The cdm.js file is getting quite large and cumbersome to work in. I think I will create another JS file to store the implementations and leave the abstract classes in cdm.js. This way, we can keep related implementations in the same file so that they are kept separate from all of the other implementations. I might create a template JS file that contains the main structure of a complete implementation to make it easier to create new ones.

I also want to change the name of the CDM module. It is currently called ChargeInteractionModel, which is just too much to type. Lazy? Maybe, but I find it a pain to work with. This will effect the test.html file, not cdm.js even though that is where the change will be made.

It is good to refactor your code once in a while to make it more readable and maintainable.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn Thu Sep 13, 2018 1:06 am

Airman wrote:Two body 03. Two protons with an initial vertical separation of 10, the bottom proton is rotated 90 degrees about the x-axis. I don’t recall the bottom proton also picking up an x-spin before.

I saw this a few version ago. I did not add it in there, and was wondering why you did. When I fixed the spin bug recently, I noticed that it went back to normal behavior. Well, it didn't spin, at least. Not sure what caused that. I'll check it again if you are still seeing it. I thought it had fixed itself.

Airman wrote:Four Body 01-04 are all interesting.

I think these scenarios work better after the spin fixes.

Airman wrote:Proton Stack 03 - three protons in a vertical column, is definitely ‘broken. Involving the overlap collision error.

Yeah, not sure what is going on there. I expected them to bounce off, but it seems the attraction is overriding the bounce.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn Thu Sep 13, 2018 9:03 am

Jared Magneson wrote:I'm curious about the spikes though - they look great and can be a useful tool I'll likely import to my video style if that's okay. But could they be made to match the charge profiles of the proton and neutron? I don't know much about that. It looks like they're pretty uniform currently.

Also, what about transparency in the shaders? Would it be useful or possibly to turn the charge transparency down a bit, say 75% or something, as a visual reference? To emulate the field instead of implying (perhaps) discrete particles?  Just an idea!

I have created a way to visualize the charge profile of a particle. It isn't quite what you mentioned, but it works fairly well. It would be great to render the charge field as a fog, or gas, but that is extremely expensive and could not be done for an arbitrary number of particles. What I have done, is to create a sphere that samples the charge field of a particle and applies a color to each vertex to represent the value at that point. Red indicates repulsion and blue indicates attraction.

Possible Charged Particle Field  - Page 7 Charge11

You can create it at any distance from the particle. I tried to create multiple spheres at different radii, but it didn't work. There is also a problem in the way I have created the geometry that causes a weird problem when you zoom inside of the sphere. It works from the outside though, and that is actually the only way it should render but it seems ThreeJS is not listening to that setting.

There is a new menu called Graphics that contains some switches to enable/disable various parts of a particle. The spikes are disabled by default now and you have to turn them on if you want to see them. None of these settings are saved so if you refresh the page or go to a different scenario then it will revert back to the defaults.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn Thu Sep 13, 2018 6:17 pm

I also updated my site with the new version: https://www.nevyns-lab.com/mathis/app/cpim/test.html
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn Fri Sep 14, 2018 9:36 am

I've made a few improvements to the charge calculations and they seem to work better. Having the ChargeProfile sampler to visualize the charge field is helping a lot. I can see the results of the math and where it breaks down.

I'm trying different ways to generate the CHARGE_DENSITY values so that I can generate larger arrays. The larger the array the smaller the angle from equator to pole that each value in it represents. It sets the precision of the emission. I'm using different equations to calculate the values and trying to get some curves into the way the values increase and decrease in size. For example, I'm using a sine function to generate values between -1 and 1 which provides pretty good accelerating and decelerating slopes.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman Fri Sep 14, 2018 4:49 pm

.
Hey Nevyn, it’s impossible to keep up with you, I haven’t seen your latest changes yet. I’m wrapped up in my current effort of cleaning up the Sphericals group programming, particle placements, vertex radials, and edge lines. I want to change the orientations of each so as to ensure the poly’s top center face, above the center proton will be parallel to the y-plane. Right now, for the three Spherical group configurations (6, 12 and 20), above the central proton’s north pole is either an octahedron vertex, icosa mid-edge or dodeca mid-edge. Plenty of exercises in programming and spatial thinking. I’m still using Cartesian coordinates, but I’ll be more than happy to switch to polar coords, as with initSpinTest.

With respect to your latest post, I know what you’re talking about. Here’s a quote from an old post of mine - a dual lobed charge profile:
LongtimeAirman on Sat Oct 17, 2015 3:49 pm
https://milesmathis.forumotion.com/t128-simple-orbiter-2#976
Possible Charged Particle Field  - Page 7 Dfield10
.

LongtimeAirman
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn Fri Sep 14, 2018 6:17 pm

I have refactored a lot of stuff. This will make it difficult for you to merge your changes in. I suggest you create a branch from wherever you currently are and commit to that. Then we can try to sort it out.

I pulled a lot of the code from cdm.js out into their own JS files. This makes it easier to work on and find things. That shouldn't impact you too much, but the changes to test.html will. All I have changed in there is to rename the module from ChargeInteractionModel to PIM. You could try to make that change on your own code before you commit it. Just replace all occurrences of ChargeInteractionModel with PIM. Oh, it also now imports the new JS files, but that should merge in easy enough.

Let me know if you have any trouble. I should have coordinated this with you to avoid these issues, sorry.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn Fri Sep 14, 2018 6:21 pm

The initSpinTest function doesn't really use polar coordinates, it just uses trigonometry to rotate points around. All coordinates are still cartesian.

Once you have the latest code changes, have a look over the scenarios. I think some of them work better now that the charge field is more precise and accurate. Unfortunately, it didn't fix any of the spin reversals, but it has affected them.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman Fri Sep 14, 2018 8:31 pm

.
The screen goes black - RADIUS is not defined.
Ok, I'm looking. Here's a fat bug. I have the CP (default) precision and ran through the unmoveable set everything looked the same.  Running Unmoveable - ArrangeAboutY configuration. When I switch precision to icosa precision, the screen goes black. My Firefox console reads.

THREE.WebGLRenderer 88 three.js:21191:3
ReferenceError: RADIUS is not defined[Learn More] charge-point-engine.js:416:7
.

LongtimeAirman
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn Fri Sep 14, 2018 8:37 pm

Sorry. Fixed that.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman Fri Sep 14, 2018 11:50 pm

.
Looks good Nevyn. I ran some of the simulations' current and previous versions side by side. The current version always ran at a slightly higher fps number. It’s hard to be certain, but I believe your changes have significantly sped up the action, the action also seems smoother. I can see increased acceleration when approaching proton poles.

By running collision test 03 I can see that the proton emissions are now slightly stronger; previously, maybe one (or none) of the protons on the left surface didn’t experience a collision, now there are five or six protons left stationary after their emissions turned back the approaching neutrons.

The Charge profile graphic effect works nicely, especially when used with Charge emission.

Since the Charge axes graphic effect need not be on, please let the user know which Precision button is currently selected (or in effect).

When one wishes to leave the Charge axes on, it is very inconvenient to have to reset the precision (?), then turn on the charge axes, in that order, whenever one changes the scenario.

Refactoring eh? Given all the changes involved in creating your new break-out documents, I believe your re-launch went very well.
.

LongtimeAirman
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn Sat Sep 15, 2018 5:45 pm

LongtimeAirman wrote:Looks good Nevyn. I ran some of the simulations' current and previous versions side by side. The current version always ran at a slightly higher fps number. It’s hard to be certain, but I believe your changes have significantly sped up the action, the action also seems smoother. I can see increased acceleration when approaching proton poles.

The forces are definitely smoother. Once I could see the charge profile, I saw that it wasn't working quite as well as it did in my head (funny how that happens). Improving the math to control the equator to pole calculation helped immensely. It is also the increased precision of the charge emission. Using the generated values (using sine at the moment) I am generating 100 values. That is 100 division in 90°, so each value represent 0.9°. The best thing about that precision is that it doesn't include an increase in time to process. We could have 1000 values and it would be just the same.

LongtimeAirman wrote:By running collision test 03 I can see that the proton emissions are now slightly stronger; previously, maybe one (or none) of the protons on the left surface didn’t experience a collision, now there are five or six protons left stationary after their emissions turned back the approaching neutrons.

That does work better now. I hadn't looked closely at the collision scenarios because I didn't want to see those ugly collisions. I was only thinking about the first 2 scenarios and forgot that the third was a bit different.

LongtimeAirman wrote:The Charge profile graphic effect works nicely, especially when used with Charge emission.

I love that ChargeProfile sampler! It is helping so much, I wish I had thought of it sooner. It is always good to find a way to visualize the math, if you can.

LongtimeAirman wrote:Since the Charge axes graphic effect need not be on, please let the user know which Precision button is currently selected (or in effect).

Good idea. Not sure how to do that at the moment.

LongtimeAirman wrote:When one wishes to leave the Charge axes on, it is very inconvenient to have to reset the precision (?), then turn on the charge axes, in that order, whenever one changes the scenario.

Yes, that is annoying, so I have fixed it up and it saves it to the URL.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn Sat Sep 15, 2018 6:02 pm

I have changed the way the Precision menu is built and added a * next to the currently active precision.

Updated my site with the latest changes too.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn Sat Sep 15, 2018 6:06 pm

And made it use bold text too.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman Sat Sep 15, 2018 6:21 pm

.
Possible Charged Particle Field  - Page 7 Stat5s10
Sorry Nevyn, I’m getting errors trying to Push or Pull – an incomplete merge (?), after committing the dodecahedron. You can see the neutrons accelerate very smartly (clear curving paths!) at and then away from the central proton in this scenario.

Anyway, the uncommitted errors aren’t mine, I left enough of the change so that you can see that. Is this change a merge product? Please tell me what line to go to and what to Pull/push next, I re-cloned over a problem similar to this previously.
.

LongtimeAirman
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn Sat Sep 15, 2018 6:43 pm

You should be able to pull my changes with rebase turned on on the dialog box. This will get my changes and merge them on top of your changes.

You may need to Abort the previous pull in the Action menu. Unless you only did a Fetch, then you won't have to do anything other than pull with rebase.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman Sat Sep 15, 2018 7:01 pm

.
_You have not concluded your merge (MERGE_HEAD exists).hint_ Please, commit your changes before merging.fatal_ Exiting because of unfinished merge_

I had fetched and pulled.

Neither of us is the author of the uncommitted changes at the top line in the Sourcetree pic.

Abort isn't an alternative (its greyed out), I tried resolve conflict - restart merge; it asked, am I sure, I said Ok, but nothing changed.
.

LongtimeAirman
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman Sat Sep 15, 2018 7:28 pm

.
Possible Charged Particle Field  - Page 7 Stat5s11
I tried rebasing and recceived the error I shared previously. After another thrashing here I am.

True statement, you're the only person I've ever asked directions from.
.


Last edited by LongtimeAirman on Sat Sep 15, 2018 7:44 pm; edited 1 time in total

LongtimeAirman
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn Sat Sep 15, 2018 7:35 pm

If you still have those changes in a separate file, or can pull them out easily enough, then it is probably easier to re-clone the repo.

Try to get into the habit of Fetching before committing. That way, you can see if I have pushed any new commits before you add yours, and can pull them down more easily. I am trying to get into the same habit and still forget at times because I am used to working on my own, either as a project (at home) or as a branch (at work).
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman Sat Sep 15, 2018 8:00 pm

.
Yes Sir.

Ok, I'm back. I'll need to re-enter my latest changes after a bit, I'm a couple of chores behind.

How did you use the charge profiler effect to improve the emission field?
.

LongtimeAirman
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn Sat Sep 15, 2018 8:39 pm

Just by being able to see the charge field as it transitioned from equator to pole. I could see where it didn't look right. There were some strange looking edges at the boundary between repulsion and attraction, so I knew the math wasn't working as I thought it should.

The problem was that previously I was only looking at the Y axis and assuming the equator to pole relationship from that, but that doesn't take the extension into the XZ plane (equator) into account. Now it is using trig functions to calculate the actual angle, dividing that by PI/2 to convert it into a value between 0 and 1, and then using that to find the appropriate charge density value in that array (which is now calculated from a sine function).

Note that it only works out 90°, from equator to one pole, and the upper and lower halves are mirrored.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn Sat Sep 15, 2018 8:41 pm

I'm not sure if I made it clear, but the object used to calculate the charge emission is being used by the sampler, hence why I am calling it a sampler. So the charge profile is a true representation of the charge emission calculations, at some specified radius from the emitter.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman Sat Sep 15, 2018 10:23 pm

.
The charge sampler seems like a light bulb.
 
I added the dodeca init20PointSphere03. I also added for-loops to all the spherical particle placements, vertex radials and surface edge line scenarios/functions to make the programming slightly better.  

I think we have a new bug, a very recent change (like today) has strengthened the proton emission TOO MUCH. Neutrons are accelerating into the proton poles almost faster than we can see. Now, in Collision test 03, none of the neutrons can collide with a proton. The energetic proton has broken initSixPointSphere01.  
.

LongtimeAirman
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman Sat Sep 15, 2018 10:40 pm

.
Gremlins.

Now things are again working as they were earlier today - the super proton bug is gone. Collision test 03 and initSixPointSphere01 are working 'properly'. I'll keep an eye out and let you know if I see it again.
.

LongtimeAirman
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn Sun Sep 16, 2018 12:40 am

I have made some serious changes that are going to effect you because I have totally overhauled the scenario mechanism. The main HTML file was getting way too large and cumbersome to work in. So I have created a more formal idea of a scenario that allows us to use separate JS files for a scenario group. You can have multiple groups per JS file to.

I have created a new branch to house it until you are ready. Let me know when you have all of your changes pushed to GIT and I will try to merge them into the new way of doing things.

Have a look at the branch to get a feel for what I have done. I added a template file that provides the outline of a new scenario file and documentation on what to do inside of it. It is called AddScenarioTemplate.txt and can be found in the new js/scenario folder. This is the folder to put any scenario JS files to keep them together and separate from other files. Makes them easy to find.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

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

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

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman 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 : 2015
Join date : 2014-08-10

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn 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.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn 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.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn 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.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman 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 : 2015
Join date : 2014-08-10

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman 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 : 2015
Join date : 2014-08-10

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn 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).
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn 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.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

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

I have created a visualizer for the spatial index.

Possible Charged Particle Field  - Page 7 Blocka10

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
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

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

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

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman 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.

Possible Charged Particle Field  - Page 7 Nswith10
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.  

Possible Charged Particle Field  - Page 7 Neutro12
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 : 2015
Join date : 2014-08-10

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn 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.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn 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.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn 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.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn 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.

Possible Charged Particle Field  - Page 7 Blocka11

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.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman 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 : 2015
Join date : 2014-08-10

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman 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 : 2015
Join date : 2014-08-10

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn 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.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn 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.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn 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.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman 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 : 2015
Join date : 2014-08-10

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Nevyn 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.
Nevyn
Nevyn
Admin

Posts : 1887
Join date : 2014-09-11
Location : Australia

http://www.nevyns-lab.com

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman 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!
Possible Charged Particle Field  - Page 7 Poslog10

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 : 2015
Join date : 2014-08-10

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman 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 : 2015
Join date : 2014-08-10

Back to top Go down

Possible Charged Particle Field  - Page 7 Empty Re: Possible Charged Particle Field

Post by Sponsored content


Sponsored content


Back to top Go down

Page 6 of 15 Previous  1 ... 5, 6, 7 ... 10 ... 15  Next

Back to top

- Similar topics

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