Possible Charged Particle Field

Page 18 of 23 Previous  1 ... 10 ... 17, 18, 19 ... 23  Next

Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Sat Oct 20, 2018 12:17 am

.

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


How the position lines and lengths are calculated.

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

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

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Sat Oct 20, 2018 7:10 am

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

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

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

Posts : 1360
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 Sat Oct 20, 2018 1:42 pm

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

Review mode. Help.

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

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

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

Separate subject. The particle mesh is too dense.

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

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Sat Oct 20, 2018 4:32 pm

Fixed up those issues.

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

Posts : 1360
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 Oct 21, 2018 12:24 am

.
Thanks for defaulting a loop preset.

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


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

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Sun Oct 21, 2018 11:09 pm

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


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

ThreeJS camera.lookAt() has no effect, is there something I'm doing wrong?
https://stackoverflow.com/questions/10325095/threejs-camera-lookat-has-no-effect-is-there-something-im-doing-wrong
Andrea wrote. I figured it out. To prevent THREE.TrackballControls or THREE.OrbitControls from overriding camera.lookAt upon initialization, you need to change the line that sets the control's target property to equal the sum of the camera.position vector and the camera.getWorldDirection() vector, instead of how it's currently implemented using a new THREE.Vector3() (which defaults to (0, 0, 0)).

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

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Mon Oct 22, 2018 12:04 am

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

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

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

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

Posts : 1360
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 Oct 22, 2018 3:39 am

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

Posts : 1360
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 Oct 22, 2018 6:00 pm

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

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

Posts : 1360
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 Oct 22, 2018 11:26 pm

.
The only surfaces that exist are on the particles themselves. You might have to find a different way to accomplish the same thing.
Agreed, we only have particles. We can demonstrate spin collisions perfectly well with particles only. We can set up both particles with mirrored positions and velocities resulting in oblique spin collisions at (0,0,0). We can control the spin axis and spin rate for one of the mirror particles - something one cannot do with a surface - while observing the resulting spin changes to the other particle.

To get the camera to orbit around a different location, set the target property of the camera object. It is a THREE.Vector3, so do something like: camera.target. set( x, y, z );
Thanks, I Pushed the rough draft so you could see what I'd tried, it didn’t include camera.target. set( x, y, z );. I’ll try that next. Knowing I probably won’t use lookAt, I didn’t look at it yet.

Maybe you would like to spend some time looking for an alternative. … . We are running THREE version r88, maybe it has been updated in a later release. If you find out that it has, we could look into updating the THREE version we are using.
You’re asking me? My opinions on the subject are rather weak. Let’s see, r88 was released in Nov ’17, since then there have been: 89,90,91,92,93,94,95,96, and 97. I didn’t finish looking. I have no idea of the relative importance or major/minor changes associated with any of those releases. It seems the great complaint about Three.js is the lack of documentation. Many people reuse old examples without knowing whether those examples depended on an old release.

I haven’t looked into third party vendors offering three.js products, I didn’t imagine that such support existed. The following Three.js review indicates that they may be few.
//////////////////////////////////////////////
What are the best open source JavaScript 3D engines?
https://www.slant.co/topics/3777/~best-open-source-javascript-3d-engines
TOP PRO
•••
Feature rich
Effects: Anaglyph, cross-eyed and parallax barrier. Scenes: add and remove objects at run-time; fog Cameras: perspective and orthographic; controllers: trackball, FPS, path and more Animation: armatures, forward kinematics, inverse kinematics, morph and keyframe Lights: ambient, direction, point and spot lights; shadows: cast and receive Materials: Lambert, Phong, Standard, smooth shading, textures, PBR and more Shaders: access to full OpenGL Shading Language (GLSL) capabilities: lens flare, depth pass and extensive post-processing library Objects: meshes, particles, sprites, lines, ribbons, bones and more - all with Level of detail Geometry: plane, cube, sphere, torus, 3D text and more; modifiers: lathe, extrude and tube Data loaders: binary, image, JSON and scene Utilities: full set of time and 3D math functions including frustum, matrix, quaternion, UVs and more Export and import: utilities to create Three.js-compatible JSON files from within: Blender, openCTM, FBX, Max, and OBJ Support: API documentation, public forum Examples: Over 150 files of coding examples plus fonts, models, textures, sounds and other support files

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

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

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

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

However, could we introduce another form of gravity that acts like a planet? A very large mass causing a definite direction to gravity, in addition to the existing gravity between particles.
Simulating the particle field due to large gravity/charge sources should be a matter of adjusting the model’s local ambient conditions and not “declaring different types of universes”.
.

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Tue Oct 23, 2018 12:14 am

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

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

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

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

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

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

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

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

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

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

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

Posts : 1360
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 Oct 23, 2018 9:21 pm

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

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

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


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

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

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

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

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

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Tue Oct 23, 2018 11:10 pm

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

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

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

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

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

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

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

Posts : 1360
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 Oct 25, 2018 11:13 pm

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

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


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

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

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

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

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Sat Oct 27, 2018 3:52 pm

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

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

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

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

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

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

Posts : 1360
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 Sat Oct 27, 2018 4:50 pm

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

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

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

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

Posts : 1360
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 Sat Oct 27, 2018 4:54 pm

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

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

I take it you approve of the armillary idea?

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

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Sat Oct 27, 2018 5:47 pm

.

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

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

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Sat Oct 27, 2018 7:22 pm

I fixed up the spatial index.

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

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

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

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

Posts : 1360
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 Sat Oct 27, 2018 10:41 pm

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

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

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Sun Oct 28, 2018 5:01 pm

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

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

Posts : 1360
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 Oct 28, 2018 5:27 pm

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

Code:

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

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

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

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

Code:

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

  // TODO add vector updates here

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

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

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

Code:

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

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

Posts : 1360
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 Oct 28, 2018 8:42 pm

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

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

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

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

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

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Sun Oct 28, 2018 9:33 pm

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

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

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

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

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

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

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

Posts : 1360
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 Oct 29, 2018 5:51 pm

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

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

Your help is always appreciated.
.

LongtimeAirman
Admin

Posts : 1044
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 18 of 23 Previous  1 ... 10 ... 17, 18, 19 ... 23  Next

Back to top


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