Virtual Scattering Application
4 posters
Page 4 of 4
Page 4 of 4 • 
1, 2, 3, 4
Re: Virtual Scattering Application
by LongtimeAirman Sun Jul 28, 2019 6:56 pm
.
Many thanks for the corrections Nevyn, much better then the distortions, alignment errors and overall odd firing pattern I’d almost grown to love. Congratulations on very nice control options. The image above shows a highly narrow and accurate beam – at a very low firing rate. From this position, one may shift the browser view slightly to see that all the photon beams are on shared planes. All the emission points (muzzle barrel ends) and beams are in perfect alignment. Any photon outside the beams was involved in a collision, photons that do not collide with the central target photon will eventually pass through the center of the opposing gun. Or one may reduce the firing accuracy by increasing the beam width. Increasing the firing rate will then flood most of the central space with un-collided photons as is shown below. I took the opportunity to check for the non-coincident cylinder geometry problem. I added eight new bands2 meshes to the scene graph you created for Simple gun.
In this image, the Simple gun sphere is 10 times smaller. As you can see from either image, your spatial corrections had no effect. I don’t believe it indicates bad math, or a bad scene graph, just a lack of understanding. I’ll keep it in mind.
.
Many thanks for the corrections Nevyn, much better then the distortions, alignment errors and overall odd firing pattern I’d almost grown to love. Congratulations on very nice control options. The image above shows a highly narrow and accurate beam – at a very low firing rate. From this position, one may shift the browser view slightly to see that all the photon beams are on shared planes. All the emission points (muzzle barrel ends) and beams are in perfect alignment. Any photon outside the beams was involved in a collision, photons that do not collide with the central target photon will eventually pass through the center of the opposing gun. Or one may reduce the firing accuracy by increasing the beam width. Increasing the firing rate will then flood most of the central space with un-collided photons as is shown below. I took the opportunity to check for the non-coincident cylinder geometry problem. I added eight new bands2 meshes to the scene graph you created for Simple gun.
In this image, the Simple gun sphere is 10 times smaller. As you can see from either image, your spatial corrections had no effect. I don’t believe it indicates bad math, or a bad scene graph, just a lack of understanding. I’ll keep it in mind.
There’s too little to go. Are you concerned with the timescale given a stacked spin level? The photons move at light speed. I suppose that if one can vary the target dimensions then the speed of the photons across the target zone should vary. We should be given the radius of the target zone - or how long it takes for a photon to cross it.I also think that it needs some sort of time scale for the user, but I'm not sure how to show it yet.
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by Nevyn Sun Jul 28, 2019 8:25 pm
I didn't expect those changes to fix your problem. I had a look at it, but didn't see anything obvious.
What I meant about a time scale was a way for the user to know how time is passing in the model, as opposed to real-time. For example, if we wanted to know how many collisions occur in 1s of model time, then there is no way to do that at the moment. It can easily be calculated, but I want a way to show it in the app and I am just not seeing any way to do that yet.
I might end up handling that in the detectors. Maybe a detector could record many results. For example, the user might tell the app that it wants to record 1s worth of results and then it will zero them out and record another set. So you end up with a series of images where each image shows 1s worth of data.
One thing that is very noticeable now that we can expand the firing angles and rate is that most photons do not collide. Collisions are fairly rare. It is too early to be making conclusions from this, but it does fit with the theory so far.
What I meant about a time scale was a way for the user to know how time is passing in the model, as opposed to real-time. For example, if we wanted to know how many collisions occur in 1s of model time, then there is no way to do that at the moment. It can easily be calculated, but I want a way to show it in the app and I am just not seeing any way to do that yet.
I might end up handling that in the detectors. Maybe a detector could record many results. For example, the user might tell the app that it wants to record 1s worth of results and then it will zero them out and record another set. So you end up with a series of images where each image shows 1s worth of data.
One thing that is very noticeable now that we can expand the firing angles and rate is that most photons do not collide. Collisions are fairly rare. It is too early to be making conclusions from this, but it does fit with the theory so far.
Nevyn- Admin
- Posts : 1887
Join date : 2014-09-11
Location : Australia -
Re: Virtual Scattering Application
by LongtimeAirman Mon Jul 29, 2019 5:17 pm
.
Here is 50 percent accuracy and 50% firing rate. It appears to me that the accuracy is nowhere near 50% - maybe less than 1%. The aperture angle and Accuracy are strongly related, an exponential notation may be more appropriate. The firing rate is also a bit ambiguous, all one can see is flooding. An absolute value or count may be appropriate. Note that a small section of decking is visible along the bottom left edge, easily obscured by the firing action.
One cannot view any ‘hits’ until they emerge from the cloud of un-collided photons. How about a dashboard output, with three, x y and z axis viewports showing the locations of all the currently detected (red) hits. Or just a tally-board with 'real time' output results including a time conversion.
.
Here is 50 percent accuracy and 50% firing rate. It appears to me that the accuracy is nowhere near 50% - maybe less than 1%. The aperture angle and Accuracy are strongly related, an exponential notation may be more appropriate. The firing rate is also a bit ambiguous, all one can see is flooding. An absolute value or count may be appropriate. Note that a small section of decking is visible along the bottom left edge, easily obscured by the firing action.
One cannot view any ‘hits’ until they emerge from the cloud of un-collided photons. How about a dashboard output, with three, x y and z axis viewports showing the locations of all the currently detected (red) hits. Or just a tally-board with 'real time' output results including a time conversion.
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by Nevyn Mon Jul 29, 2019 6:52 pm
Yeah, it is easy to create a complete mess and not be able to see anything, but that is needed to get quick results. I am thinking about adding a transparency control for the charge photons that have not collided. You would be able to drop that all the way to invisible. Then you would only see the photons once they have collided.
The accuracy is an inverted percentage of the maximum angle allowed (i.e. 100 - %). I don't see how using scientific notation will help. What would the value represent? Maybe the term accuracy is not the right one to use. It is just a way to expand the firing angle so that you can get each gun to cover the target region. I still have to figure out how to do it, but I want a way for the user to be able to set the number of stacked spins on the target particle. The problem is that they grow in size so quickly. The current chamber can accommodate 2 full spin-sets (e.g. AXYZAXYZ), but anymore and it is too large. Eventually I would like to be able to specify the particle with an SPL expression(Stacked Spin Language).
I have also been thinking about a slider to move the guns in and out. That might help with the target particle sizes too.
I just added a path to show where the target particle is moving so that you can determine where the equator and poles are. I found myself using the chamber to do this, which is completely misleading.
The accuracy is an inverted percentage of the maximum angle allowed (i.e. 100 - %). I don't see how using scientific notation will help. What would the value represent? Maybe the term accuracy is not the right one to use. It is just a way to expand the firing angle so that you can get each gun to cover the target region. I still have to figure out how to do it, but I want a way for the user to be able to set the number of stacked spins on the target particle. The problem is that they grow in size so quickly. The current chamber can accommodate 2 full spin-sets (e.g. AXYZAXYZ), but anymore and it is too large. Eventually I would like to be able to specify the particle with an SPL expression(Stacked Spin Language).
I have also been thinking about a slider to move the guns in and out. That might help with the target particle sizes too.
I just added a path to show where the target particle is moving so that you can determine where the equator and poles are. I found myself using the chamber to do this, which is completely misleading.
Nevyn- Admin
- Posts : 1887
Join date : 2014-09-11
Location : Australia -
Nevyn- Admin
- Posts : 1887
Join date : 2014-09-11
Location : Australia -
Re: Virtual Scattering Application
by LongtimeAirman Tue Jul 30, 2019 6:04 pm
.
A star is born indeed. Glad to see the stacked-spinning b-photon arrive, quite the showcase. Scattering Application interference patterns. Mighty nice.
Bullet opacity is a great solution. Without it, your previous set and my above image would be dominated by un-collided photon streams. In close, one can clearly see the green b-photon stackspinning about the target zone – its previous path is identified by the length of the yellow line. The b-photon is creating red (post-collided) photons in its wake.
You mentioned radial gun motion, in order to accommodate a user request for a specific stacked spin level. Have you considered allowing the photon/b-photon collisions to add or subtract spins? I sure hope so.
The more I think about the Control panel word choice – accuracy, the more I don’t like it. It’s confusing and misleading. Please consider changing ‘Accuracy’ into ‘Beamwidth’. Instead of increasing/decreasing accuracy one narrows/widens the Beamwidth. Beamwidth is measured in degrees, let the perfect collimated beam be zero and the widest aperture as you like.
P.S. Excuse me for adding, these interference patterns are really very nice. Your images don't suffer from a lack of opacity the lines do obscure a bit. Good to have the choice.
.
A star is born indeed. Glad to see the stacked-spinning b-photon arrive, quite the showcase. Scattering Application interference patterns. Mighty nice.
Bullet opacity is a great solution. Without it, your previous set and my above image would be dominated by un-collided photon streams. In close, one can clearly see the green b-photon stackspinning about the target zone – its previous path is identified by the length of the yellow line. The b-photon is creating red (post-collided) photons in its wake.
You mentioned radial gun motion, in order to accommodate a user request for a specific stacked spin level. Have you considered allowing the photon/b-photon collisions to add or subtract spins? I sure hope so.
The more I think about the Control panel word choice – accuracy, the more I don’t like it. It’s confusing and misleading. Please consider changing ‘Accuracy’ into ‘Beamwidth’. Instead of increasing/decreasing accuracy one narrows/widens the Beamwidth. Beamwidth is measured in degrees, let the perfect collimated beam be zero and the widest aperture as you like.
P.S. Excuse me for adding, these interference patterns are really very nice. Your images don't suffer from a lack of opacity the lines do obscure a bit. Good to have the choice.
.
Last edited by LongtimeAirman on Tue Jul 30, 2019 7:44 pm; edited 1 time in total (Reason for editing : Added P.S.)
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by Nevyn Tue Jul 30, 2019 9:25 pm
No, I don't want spin-ups or spin-downs for this app. The idea is to see how a given particle reacts to a, some-what, random charge field. The output is a charge profile of that particle. Ideally, we will see the equatorial region being more heavily bombarded than the poles. However, that may require quite large particles. Maybe, once it is complete, I might look into changes in spin (with an option to enable/disable it), but I wouldn't hold my breath.
With respect to the Accuracy title, do you think 'Firing spread' would be better? Width implies, at least to me, that some thing is always that wide. Here's the first paragraph from a wiki article about shot grouping:
So it seems 'Precision' is the correct term to use. A gun is precise, but the shooter is accurate.
Please note that those interference patterns are just rendering artifacts from the transparency. There is no wave interference going on at all. I think you are aware of that, but thought it worth explicitly stating in case readers get confused.
With respect to the Accuracy title, do you think 'Firing spread' would be better? Width implies, at least to me, that some thing is always that wide. Here's the first paragraph from a wiki article about shot grouping:
Wikipedia wrote:In shooting sports, a shot grouping, or simply group, is the pattern of projectile impacts on a target from multiple shots taken in one shooting session. The tightness of the grouping (the proximity of all the shots to each other) is a measure of the precision of a weapon, and a measure of the shooter's consistency and skill.[1][2] On the other hand, the grouping displacement (the distance between the calculated group center and the intended point of aim) is a measure of accuracy.
So it seems 'Precision' is the correct term to use. A gun is precise, but the shooter is accurate.
Please note that those interference patterns are just rendering artifacts from the transparency. There is no wave interference going on at all. I think you are aware of that, but thought it worth explicitly stating in case readers get confused.
Nevyn- Admin
- Posts : 1887
Join date : 2014-09-11
Location : Australia -
Re: Virtual Scattering Application
by LongtimeAirman Wed Jul 31, 2019 6:57 pm
.
Paraphrasing wiki.
1. The tightness of the grouping (the proximity of all the shots to each other) is a measure of the precision of a weapon.
2. The grouping displacement (the distance between the calculated group center and the intended point of aim) is a measure of accuracy.
With respect to wiki, I don’t believe it serves our purpose to be lumping a zero grouping/displacement performance deviation into a perfect accuracy percentage.
Firing spread is close but spread sounds like a drift or inaccuracy to me, we are trying to set the gun's aperture angle. How about - Beam Angle?
By interference patterns I don't mean wave patterns, we have 'virtual' actual collisions.
.
Our gun is an absolutely accurate shooter, which can pierce (0,0,0) every time. But (0,0,0) is not the target, we are trying to hit a moving b-photon, not usually colliding with the gun’s photon beam at any given moment. In my mind claiming 100% accuracy is wrong and contrary to the Virtual Scattering Application concept. It may turn out that a slight firing angle will yield increased b-photon collisions.With respect to the Accuracy title, do you think 'Firing spread' would be better? Width implies, at least to me, that some thing is always that wide. Here's the first paragraph from a wiki article about shot grouping:
…
A gun is precise, but the shooter is accurate.
Paraphrasing wiki.
1. The tightness of the grouping (the proximity of all the shots to each other) is a measure of the precision of a weapon.
2. The grouping displacement (the distance between the calculated group center and the intended point of aim) is a measure of accuracy.
With respect to wiki, I don’t believe it serves our purpose to be lumping a zero grouping/displacement performance deviation into a perfect accuracy percentage.
Firing spread is close but spread sounds like a drift or inaccuracy to me, we are trying to set the gun's aperture angle. How about - Beam Angle?
By interference patterns I don't mean wave patterns, we have 'virtual' actual collisions.
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by Nevyn Wed Jul 31, 2019 8:51 pm
Initially, I had the idea that each gun would have its own direction. Allowing them to be off-center and individually configured. The code can still handle that, but creating a UI for the user to do it is difficult, and will probably end up too complicated for most. So every gun is pointed at the same point, (0, 0, 0), and the precision/beam angle allows the gun to fire bullets over a wider area so that all guns together can create some thing like a random field. You aren't really supposed to have 100% precision, but it can be useful for debugging.
I have changed Accuracy to Precision and I think that is close enough. It just has to give the user an idea of what it will control. Actually changing its value will immediately show them what it does. While Beam angle is pretty good, I don't actually want the value that the user sets to be an angle. I just want to setup min and max values in the code and then the user just selects a value between 0 and 100. That keeps it simple for the user while allowing me to change how it actually works in the code, should I need to.
Just added the slider control to set the radius of the guns.
I have changed Accuracy to Precision and I think that is close enough. It just has to give the user an idea of what it will control. Actually changing its value will immediately show them what it does. While Beam angle is pretty good, I don't actually want the value that the user sets to be an angle. I just want to setup min and max values in the code and then the user just selects a value between 0 and 100. That keeps it simple for the user while allowing me to change how it actually works in the code, should I need to.
Just added the slider control to set the radius of the guns.
Nevyn- Admin
- Posts : 1887
Join date : 2014-09-11
Location : Australia -
Re: Virtual Scattering Application
by LongtimeAirman Thu Aug 01, 2019 6:37 pm
.
Outside the Range.
Oh No! I wasn’t able to recreate a “Star is Born” collision detection interference pattern. Apparently the target zone b-photon particle radius (and spin level?) is too large(?). I assume they’ll be restored by (letting the user) select a smaller, lower stacked spin level(?). Please don't wait that long.
I would have started coding/conforming the oversize gun types back to smaller sizes, but the appearance of new buttons comes first.
Control panel buttons.
Guns. The Guns button is gone. The default is the Simple gun. I keep showing different gun types and range textures, the User should also have those choices. Now I feel guilty, was I supposed to wire that up?
Gun radius. 0-100. Nice action/ease repositioning all the configuration’s equi-distant guns radially outward/inward from the center of the target zone. Forgive me, the limits are somewhat disconcerting.
At zero radius, Simple guns are shoulder-to shoulder having almost completely penetrated into the target zone where the b-photon might be ‘behind’ any particular gun’s emission point at a given moment. Sperm/egg image not included, sorry, please consider adding the gun’s length to the zero limit radius.
At distance 100 the guns have almost completely penetrated the Scattering gun range’s internal surface texture boundary. If you haven’t exited the range before, now's your chance. We are able to see beyond the range, image above. The distant streaks of photons reflect previous 100% Precision or high Firing rate settings/changes. I found it - odd. Now I know the arrow keys can add to the confusion. Please consider lowering the outer Gun radius or expanding the scene to allow us who choose to remain inside to do so.
Please consider changing Gun radius to Firing radius. A side benefit is better agreement with Firing Precision and Firing Rate. Or just Radius, Rate and Precision.
Precision. 0-100. Why can I can accept 100% Precision but not 100% Accuracy? Don’t tell me.
Firing rate. 0-100. Ok. One complaint, all guns are synchronized - pulsating. They are all firing at the same rate and time. All gun photons passing through the center should be slightly time offset from all other gun photonsm so they don't colide with one another. It's one thing to say that the gun photons do not interact, it is another to say that the n photons of n guns all pass through (0,0,0) simultaneously. Please consider adding a 360/tot#guns*firing rate etc. sequential phase differential to each sequential. Such a change may even improve target zone 'coverage'.
Bullet opacity. 0.02 - 1. Once again, Gute stoff.
Time. 0-100. I recall you mentioning having a time scale problem, wondering how best to convey time scale. I suggested add-ons that would have complicated things enormously. Your solution, slowing or speeding all the photon forward motions, works extremely well. It is immediately obvious to the user, allowing a very large time scale differential - better to see than explain.
.
Outside the Range.
Oh No! I wasn’t able to recreate a “Star is Born” collision detection interference pattern. Apparently the target zone b-photon particle radius (and spin level?) is too large(?). I assume they’ll be restored by (letting the user) select a smaller, lower stacked spin level(?). Please don't wait that long.
I would have started coding/conforming the oversize gun types back to smaller sizes, but the appearance of new buttons comes first.
Control panel buttons.
Guns. The Guns button is gone. The default is the Simple gun. I keep showing different gun types and range textures, the User should also have those choices. Now I feel guilty, was I supposed to wire that up?
Gun radius. 0-100. Nice action/ease repositioning all the configuration’s equi-distant guns radially outward/inward from the center of the target zone. Forgive me, the limits are somewhat disconcerting.
At zero radius, Simple guns are shoulder-to shoulder having almost completely penetrated into the target zone where the b-photon might be ‘behind’ any particular gun’s emission point at a given moment. Sperm/egg image not included, sorry, please consider adding the gun’s length to the zero limit radius.
At distance 100 the guns have almost completely penetrated the Scattering gun range’s internal surface texture boundary. If you haven’t exited the range before, now's your chance. We are able to see beyond the range, image above. The distant streaks of photons reflect previous 100% Precision or high Firing rate settings/changes. I found it - odd. Now I know the arrow keys can add to the confusion. Please consider lowering the outer Gun radius or expanding the scene to allow us who choose to remain inside to do so.
Please consider changing Gun radius to Firing radius. A side benefit is better agreement with Firing Precision and Firing Rate. Or just Radius, Rate and Precision.
Precision. 0-100. Why can I can accept 100% Precision but not 100% Accuracy? Don’t tell me.
Firing rate. 0-100. Ok. One complaint, all guns are synchronized - pulsating. They are all firing at the same rate and time. All gun photons passing through the center should be slightly time offset from all other gun photonsm so they don't colide with one another. It's one thing to say that the gun photons do not interact, it is another to say that the n photons of n guns all pass through (0,0,0) simultaneously. Please consider adding a 360/tot#guns*firing rate etc. sequential phase differential to each sequential. Such a change may even improve target zone 'coverage'.
Bullet opacity. 0.02 - 1. Once again, Gute stoff.
Time. 0-100. I recall you mentioning having a time scale problem, wondering how best to convey time scale. I suggested add-ons that would have complicated things enormously. Your solution, slowing or speeding all the photon forward motions, works extremely well. It is immediately obvious to the user, allowing a very large time scale differential - better to see than explain.
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by Nevyn Thu Aug 01, 2019 7:26 pm
LongtimeAirman wrote:
Outside the Range.
I had to extend the zoom range to see outside of the firing range so that I could make sure that the bullets made it that far. When you adjust the time scale, it effects the distance that a bullet can travel before it is re-used for a new bullet. If I add more bullets (there is a fixed number of rounds) then performance suffers.
LongtimeAirman wrote:
Oh No! I wasn’t able to recreate a “Star is Born” collision detection interference pattern. Apparently the target zone b-photon particle radius (and spin level?) is too large(?). I assume they’ll be restored by (letting the user) select a smaller, lower stacked spin level(?). Please don't wait that long.
The target particle now has 8 stacked spin levels, so it is larger. I might need to do a page refresh to alter the particle size/spins, etc. Too many things need to know the size to set themselves up in the initialisation phase.
LongtimeAirman wrote:
I would have started coding/conforming the oversize gun types back to smaller sizes, but the appearance of new buttons comes first.
It has now become obvious, but, that would be a good idea.
LongtimeAirman wrote:
Guns. The Guns button is gone. The default is the Simple gun. I keep showing different gun types and range textures, the User should also have those choices. Now I feel guilty, was I supposed to wire that up?
No, you weren't supposed to do anything with that. That was meant to bring up a dialog box that allowed the user to select guns, maybe position them, etc. However, I could not get it to show the dialog box over the rendering canvas. I have done it before in AV, but it just wasn't working so I moved on and got the rest of the system up and running. I haven't looked at that since the first few days of coding this app, so I got rid of the control.
LongtimeAirman wrote:
Gun radius. 0-100. Nice action/ease repositioning all the configuration’s equi-distant guns radially outward/inward from the center of the target zone. Forgive me, the limits are somewhat disconcerting.
At zero radius, Simple guns are shoulder-to shoulder having almost completely penetrated into the target zone where the b-photon might be ‘behind’ any particular gun’s emission point at a given moment. Sperm/egg image not included, sorry, please consider adding the gun’s length to the zero limit radius.
At distance 100 the guns have almost completely penetrated the Scattering gun range’s internal surface texture boundary. If you haven’t exited the range before, now's your chance. We are able to see beyond the range, image above. The distant streaks of photons reflect previous 100% Precision or high Firing rate settings/changes. I found it - odd. Now I know the arrow keys can add to the confusion. Please consider lowering the outer Gun radius or expanding the scene to allow us who choose to remain inside to do so.
The limits do need tweaking, but I actually really like the way they extend outside of the range surface, basically hiding the guns. Works well with SimpleGun, as a small part of the barrel still shows through the surface, but I haven't tried any others.
The inside limit will be the size of the target particle. The transparent sphere that you see around it.
LongtimeAirman wrote:
Please consider changing Gun radius to Firing radius. A side benefit is better agreement with Firing Precision and Firing Rate. Or just Radius, Rate and Precision.
Fair enough.
LongtimeAirman wrote:
Precision. 0-100. Why can I can accept 100% Precision but not 100% Accuracy? Don’t tell me.
I will sign a petition to have it entered into the list of great mysteries of the cosmos.
LongtimeAirman wrote:
Firing rate. 0-100. Ok. One complaint, all guns are synchronized - pulsating. They are all firing at the same rate and time. All gun photons passing through the center should be slightly time offset from all other gun photonsm so they don't colide with one another. It's one thing to say that the gun photons do not interact, it is another to say that the n photons of n guns all pass through (0,0,0) simultaneously. Please consider adding a 360/tot#guns*firing rate etc. sequential phase differential to each sequential. Such a change may even improve target zone 'coverage'.
This one is a little tricky because of the way it is implemented, and a mangling of the metaphor. You see, bullets are collected into an object of type Scattering.Round. Each Round stores all bullets fired at the same time, which is 1 from every gun. The Scattering.Range object keeps a fixed number of Rounds (about 1500 at the moment). This allows an arbitrary number of guns to be used while not effecting the bullets.
I might be able to add a slight positional offset to each bullet as it is fired, creating an arrival time difference at the target. That would break the idea of a firing rate though. While they are still fired at the set rate, it will appear that the rate is varying.
Which reminds me of some movie where they created guns that had a randomizing factor because their enemies could predict the firing and avoid the bullet. Can't remember what it was though? Oh, yeah, it was a TV show: Fringe. Loved that show. Brilliant acting by John Noble as Walter (and Walternate). If you want to see 2 great, but different, portrayals of crazy by the same actor, check out Walter in Fringe and Denethor in Lord of the Rings (2nd movie, I think). Both are excellent.
LongtimeAirman wrote:
Time. 0-100. I recall you mentioning having a time scale problem, wondering how best to convey time scale. I suggested add-ons that would have complicated things enormously. Your solution, slowing or speeding all the photon forward motions, works extremely well. It is immediately obvious to the user, allowing a very large time scale differential - better to see than explain.
.
I wasn't actually talking about a time slider (although that is exactly what time scale should make you think, my bad). I just wanted a way to show the user how time is passing in the model. A way to know that 1s of time had passed or something to that effect. I'm still not sure about that. It could be as simple as printing the time on screen.
Nevyn- Admin
- Posts : 1887
Join date : 2014-09-11
Location : Australia -
Re: Virtual Scattering Application
by LongtimeAirman Fri Aug 02, 2019 6:14 pm
.
Rumor has it that the b-photon’s path sometimes reveals an alien.
It’s remarkable that previous rate and precision changes are clearly visible deep in world space for long periods of time. Most of the photons present were launched long ago. It’s like looking back in time. My Chrome fps reads about 30. All things considered, it seems to me the performance hit isn’t that bad.
Are you saying we can only fire at (0,0,0)?
All guns firing simultaneously, at a target b-photon at (0,0,0) briefly provides the highest density of photons, and highest detection confidence of photon/antiphoton collisions – when the b-photon is at (0,0,0). In our target zone, I believe the b-photon is always centered on (0,0,0). We know, that the larger b-photon is usually further removed from the center. For larger b-photons the creation of “Star is Born” (Sib) patterns becomes impossible.
Please consider allowing the guns to aim anywhere in the b-photon target zone.
For example, let’s say the range has been operating so well they decided to convert it into a real ion detector – i.e. not detecting ions already at (0,0,0). Let a small number of ions transit the detection zone at some small velocity for some period of time. Let the guns find, then focus fire on the b-photon in order to create the Sib pattern for each ion before it exits the detector.
Allow the guns to coordinate their aiming and firing rate in order to maximize Sib creation. Between Sibs, perhaps the best way for the guns to detect the location of the next b-photon would be by through a maximum beam dispersion at maximum diffusion or lowest Precision beams. Staggering emissions to create a more uniform volume coverage makes good sense when trying to find b-photons. Varying modes and targets can make a much livelier scene.
With respect to time, a clock in coordination with the time slider sounds worth a try.
Your latest changes have greatly improved Scattering Aps' performance.
Thanks for the John Noble, Fringe recommendation. I was weened on Science Fiction, the Twilight Zone and Outer Limits. I just so happen to be finishing a Neal Stephenson novel today, “Fall”. Like the last novel I’d mentioned, I would put it in the Programmer genre where guys like you create or destroy worlds. That and this dialogue put me off coding this week – I’ll get to it next.
.
Rumor has it that the b-photon’s path sometimes reveals an alien.
My estimation of the number of photons shown in the image ‘Outside the Range’ is about 2-3 thousand. Pardon me for not actually counting. The front is in view – about equal to the number ‘in back’ – behind the viewer). In order to estimate the total number of photons present in world space I would multiply that front estimate by top/bottom, left/right views, or four. I’d say 10,000 photons have made it beyond the Range.Nevyn wrote. I had to extend the zoom range to see outside of the firing range so that I could make sure that the bullets made it that far. When you adjust the time scale, it effects the distance that a bullet can travel before it is re-used for a new bullet. If I add more bullets (there is a fixed number of rounds) then performance suffers.
It’s remarkable that previous rate and precision changes are clearly visible deep in world space for long periods of time. Most of the photons present were launched long ago. It’s like looking back in time. My Chrome fps reads about 30. All things considered, it seems to me the performance hit isn’t that bad.
On the contrary, I like the way Spiral gun recessed into the ‘walls’. I would have better appreciated and made mention of that had I not been overwhelmed by the zoom change giving me the opportunity to view the backside of the guns and the world beyond.Nevyn wrote. The limits do need tweaking, but I actually really like the way they extend outside of the range surface, basically hiding the guns. Works well with SimpleGun, as a small part of the barrel still shows through the surface, but I haven't tried any others.
The inside limit will be the size of the target particle. The transparent sphere that you see around it.
LongtimeAirman wrote: Please consider adding a 360/tot#guns*firing rate etc. sequential phase differential to each sequential. Such a change may even improve target zone 'coverage'.
Nevyn wrote. This one is a little tricky because of the way it is implemented, and a mangling of the metaphor. You see, bullets are collected into an object of type Scattering.Round. Each Round stores all bullets fired at the same time, which is 1 from every gun. The Scattering.Range object keeps a fixed number of Rounds (about 1500 at the moment). This allows an arbitrary number of guns to be used while not effecting the bullets.
I might be able to add a slight positional offset to each bullet as it is fired, creating an arrival time difference at the target. That would break the idea of a firing rate though. While they are still fired at the set rate, it will appear that the rate is varying.
Are you saying we can only fire at (0,0,0)?
All guns firing simultaneously, at a target b-photon at (0,0,0) briefly provides the highest density of photons, and highest detection confidence of photon/antiphoton collisions – when the b-photon is at (0,0,0). In our target zone, I believe the b-photon is always centered on (0,0,0). We know, that the larger b-photon is usually further removed from the center. For larger b-photons the creation of “Star is Born” (Sib) patterns becomes impossible.
Please consider allowing the guns to aim anywhere in the b-photon target zone.
For example, let’s say the range has been operating so well they decided to convert it into a real ion detector – i.e. not detecting ions already at (0,0,0). Let a small number of ions transit the detection zone at some small velocity for some period of time. Let the guns find, then focus fire on the b-photon in order to create the Sib pattern for each ion before it exits the detector.
Allow the guns to coordinate their aiming and firing rate in order to maximize Sib creation. Between Sibs, perhaps the best way for the guns to detect the location of the next b-photon would be by through a maximum beam dispersion at maximum diffusion or lowest Precision beams. Staggering emissions to create a more uniform volume coverage makes good sense when trying to find b-photons. Varying modes and targets can make a much livelier scene.
With respect to time, a clock in coordination with the time slider sounds worth a try.
Your latest changes have greatly improved Scattering Aps' performance.
Thanks for the John Noble, Fringe recommendation. I was weened on Science Fiction, the Twilight Zone and Outer Limits. I just so happen to be finishing a Neal Stephenson novel today, “Fall”. Like the last novel I’d mentioned, I would put it in the Programmer genre where guys like you create or destroy worlds. That and this dialogue put me off coding this week – I’ll get to it next.
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by Nevyn Fri Aug 02, 2019 8:03 pm
LongtimeAirman wrote:
It’s remarkable that previous rate and precision changes are clearly visible deep in world space for long periods of time. Most of the photons present were launched long ago. It’s like looking back in time. My Chrome fps reads about 30. All things considered, it seems to me the performance hit isn’t that bad.
Bullets will fly on forever, once you stop firing. There is a set number of rounds (and each round holds a bullet from each gun in use) and they are re-used when required. So once you stop firing, the current set of bullets just keep on going.
If I set the total number of rounds to about 1700, then I start to see a performance drop. I'm currently running it at 60fps @ 4K, so I'm happy with the performance. Although it is the CPU that is the bottleneck, so 4K doesn't really have much to do with it, other than more pixels to process in the shaders.
LongtimeAirman wrote:
Are you saying we can only fire at (0,0,0)?
Yes, and no. The perfect firing line is always at (0,0,0), but the Precision setting allows the bullets to spread out, so few of them are actually aimed at (0,0,0).
LongtimeAirman wrote:
All guns firing simultaneously, at a target b-photon at (0,0,0) briefly provides the highest density of photons, and highest detection confidence of photon/antiphoton collisions – when the b-photon is at (0,0,0). In our target zone, I believe the b-photon is always centered on (0,0,0). We know, that the larger b-photon is usually further removed from the center. For larger b-photons the creation of “Star is Born” (Sib) patterns becomes impossible.
Photon density is a real problem at the moment. I am working on a slider to set the number of spin levels on the target particle, and the higher you go, the less collisions because the bullet density drops in relation to the size of the particle. You have to adjust the Precision to cover the volume of the particle, but that drops the density. I can't add more Rounds because it impacts performance. More guns is the only real answer at the moment.
LongtimeAirman wrote:
Please consider allowing the guns to aim anywhere in the b-photon target zone.
The code supports that, but the problem is creating a UI to let the user do it.
LongtimeAirman wrote:
For example, let’s say the range has been operating so well they decided to convert it into a real ion detector – i.e. not detecting ions already at (0,0,0). Let a small number of ions transit the detection zone at some small velocity for some period of time. Let the guns find, then focus fire on the b-photon in order to create the Sib pattern for each ion before it exits the detector.
Allow the guns to coordinate their aiming and firing rate in order to maximize Sib creation. Between Sibs, perhaps the best way for the guns to detect the location of the next b-photon would be by through a maximum beam dispersion at maximum diffusion or lowest Precision beams. Staggering emissions to create a more uniform volume coverage makes good sense when trying to find b-photons. Varying modes and targets can make a much livelier scene.
While this is an interesting idea, it isn't what this app is designed for. My aim for this app is to model a scattering experiment. In such experiments, the target is kept still and things are thrown at it to see where they bounce. Usually they would only have a single gun, I assume, since you want to relate firing angle to bounce angle, etc. But I'm really wanting to see the charge profile of the particle, so I want a more random charge field interacting with it. Basically, I am using this to test the idea that charged particles create the equatorial charge emission.
LongtimeAirman wrote:
With respect to time, a clock in coordination with the time slider sounds worth a try.
Yeah, I just need to print the model time on screen somewhere, but that has its own problems to deal with. It is too expensive to do in the 3D scene. Browsers don't let you render in 2D once you have rendered in 3D, so I can't just draw it over the top of the final render for each frame (I could but it would require using 2 off-screen canvases and then rendering them into the on-screen canvas). I will try to do it in HTML with an element that sits on top of the 3D canvas. I think that is the best approach.
LongtimeAirman wrote:
Your latest changes have greatly improved Scattering Aps' performance.
Hmmm. Not sure what did that because I had to make some calculation changes that should have been a little bit more expensive in order to have a varying time scale. I have fixed a few little things I found along the way, so maybe they are making a difference.
I had a quick look over the commits I have made and I think it is the reduction in the total number of rounds. It was 1700 a few days ago, but is now 1500. On my CPU (i5), that is about the switching point. I had to reduce the firing rate a little bit to accommodate. There is a balance that needs to be maintained between them so that bullets make it to the walls.
LongtimeAirman wrote:
Thanks for the John Noble, Fringe recommendation. I was weened on Science Fiction, the Twilight Zone and Outer Limits. I just so happen to be finishing a Neal Stephenson novel today, “Fall”. Like the last novel I’d mentioned, I would put it in the Programmer genre where guys like you create or destroy worlds. That and this dialogue put me off coding this week – I’ll get to it next.
I have always been a sucker for good Scifi. Raised on Star Trek movies (and even though I like the Star Wars movies, I'm not sure I consider them Scifi, but more of an action movie in space (yeah, I said it!)). However, I can't ever remember reading a Scifi book. I am usually more into fantasy novels, but have been making my way through the Jack Reacher series this year. I just looked over at my library and there is 1 series I read a long time ago that might be Scifi. It is called Otherland, by Tad Williams. So I guess I have read some (1 series, 4 books).
I thought for a second that I had read some Neal Stephenson, but turns out that was Donald Stephenson, and definitely fantasy not scifi.
Nevyn- Admin
- Posts : 1887
Join date : 2014-09-11
Location : Australia -
Re: Virtual Scattering Application
by Nevyn Fri Aug 02, 2019 8:10 pm
Oh, and if you like the Star is Born type collisions, check out how a single X spin particle reacts!
Nevyn- Admin
- Posts : 1887
Join date : 2014-09-11
Location : Australia -
Re: Virtual Scattering Application
by Nevyn Sat Aug 03, 2019 2:58 am
I have put a demo up for everyone to play with.
https://www.nevyns-lab.com/mathis/app/Scattering/scattering.html
I'm seeing slower performance in firefox. Chrome seems to stay at 60fps, but firefox will drop to 30. Probably a faster javascript interpreter in chrome. All bullet calculations are in JS, so that will matter a lot.
https://www.nevyns-lab.com/mathis/app/Scattering/scattering.html
I'm seeing slower performance in firefox. Chrome seems to stay at 60fps, but firefox will drop to 30. Probably a faster javascript interpreter in chrome. All bullet calculations are in JS, so that will matter a lot.
Nevyn- Admin
- Posts : 1887
Join date : 2014-09-11
Location : Australia -
Re: Virtual Scattering Application
by LongtimeAirman Sat Aug 03, 2019 4:25 pm
.
Affirmative, I like it. Here’s another view of that same object- ‘X1’.
You’re having photon density problems eh? Care to describe it? Yet – more guns! Looking at the above, I heartily agree. Note the Sib patterns are confined to the planes in which guns reside. Why is that? Near misses? Must be an artifact of the collision rules.
Side. What are the collision rules? How is spin handled?
Ok, what’s wrong with this idea? A new configuration –100 or more guns in a ring. Let the user select the ring’s axis orientation: X, Y, or Z or enter a quaternion. You might allow the user be able to select a ‘spin axis’ to let the ring configuration rotate around the b-photon.
Please consider bringing the transparent sphere back, or at least including it as a control panel option – on/off switchable. True, the b-photon path shows the viewer the b-photon’s ‘exact’ location and previous path. How that’s even possible, given that we are trying to infer the location of the b-photon via collisions requires some stretch of the imagination (please consider making Path on/off switchable); one must wait for the path to build up. The transparent sphere or target zone shows at a glance the extent of the b-photon particle.
Let me make this perfectly clear, you should try Neal Stephenson. I especially liked the Baroque Cycle. It wasn’t so much science fiction as much as historical fiction - the birth of science.
.
Affirmative, I like it. Here’s another view of that same object- ‘X1’.
You’re having photon density problems eh? Care to describe it? Yet – more guns! Looking at the above, I heartily agree. Note the Sib patterns are confined to the planes in which guns reside. Why is that? Near misses? Must be an artifact of the collision rules.
Side. What are the collision rules? How is spin handled?
Ok, what’s wrong with this idea? A new configuration –100 or more guns in a ring. Let the user select the ring’s axis orientation: X, Y, or Z or enter a quaternion. You might allow the user be able to select a ‘spin axis’ to let the ring configuration rotate around the b-photon.
Please consider bringing the transparent sphere back, or at least including it as a control panel option – on/off switchable. True, the b-photon path shows the viewer the b-photon’s ‘exact’ location and previous path. How that’s even possible, given that we are trying to infer the location of the b-photon via collisions requires some stretch of the imagination (please consider making Path on/off switchable); one must wait for the path to build up. The transparent sphere or target zone shows at a glance the extent of the b-photon particle.
Let me make this perfectly clear, you should try Neal Stephenson. I especially liked the Baroque Cycle. It wasn’t so much science fiction as much as historical fiction - the birth of science.
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by Nevyn Sat Aug 03, 2019 6:03 pm
I also thought there was a problem with the collision code when I saw that perfect line of emission. Especially when you know that it is on a world axis. Math problems often visualize as something being stuck to an axis. However, after a little bit of thought, I realised it is doing exactly what it should be. That line is where the bullets collide with the edge of the particle. A perfect edge, so they radiate away in the same plane (not the same direction they came in on, although that is possible). Basically, the rotation axis is 90° from that perspective.
A collision is handled by taking the current position of the target particle, and the next position of that particle, and subtracting them to get the actual movement during that frame change. The direction of that vector is used to calculate the collision with the incoming charge photons. So the spin is not handled directly, but all of the stacked spins are reduced to a single motion over that time. The length of that vector is ignored. The collision calculation only wants the direction change and the charge photons always move at the same speed.
The density problem is caused by the need to process bullets in JS, rather than on the GPU. This means that every bullet, up to 1500 * number of guns, is processed sequentially. I might need to see if I can reduce those calculations somehow. With small particles, you can focus the guns on that area and get a reasonable density, but as you make the particle larger, you have to spread that same amount of charge over a larger area so you lose density.
A collision is handled by taking the current position of the target particle, and the next position of that particle, and subtracting them to get the actual movement during that frame change. The direction of that vector is used to calculate the collision with the incoming charge photons. So the spin is not handled directly, but all of the stacked spins are reduced to a single motion over that time. The length of that vector is ignored. The collision calculation only wants the direction change and the charge photons always move at the same speed.
The density problem is caused by the need to process bullets in JS, rather than on the GPU. This means that every bullet, up to 1500 * number of guns, is processed sequentially. I might need to see if I can reduce those calculations somehow. With small particles, you can focus the guns on that area and get a reasonable density, but as you make the particle larger, you have to spread that same amount of charge over a larger area so you lose density.
Nevyn- Admin
- Posts : 1887
Join date : 2014-09-11
Location : Australia -
Re: Virtual Scattering Application
by Nevyn Sat Aug 03, 2019 11:25 pm
I had to juggle a few things around, but I managed to create a rotating battery. You can choose the rotation axis and the speed, which defaults to 0. I'm not sure how useful it is, but it works!
Restructured the menu, adding folders for some things, and new controls to enable/disable the particle path and bounds.
Restructured the menu, adding folders for some things, and new controls to enable/disable the particle path and bounds.
Nevyn- Admin
- Posts : 1887
Join date : 2014-09-11
Location : Australia -
Re: Virtual Scattering Application
by LongtimeAirman Mon Aug 05, 2019 5:10 pm
.
In this image, the 58 gun Hosohedron configuration is spinning counter-clockwise. The green bullseye in the center is the south pole of the gun battery’s x-spin rotation.
Looking good, Nevyn, you’re on a roll. When I said you increased performance of the Virtual Scattering App you interpreted that to mean fps wise, switching from 1700 rounds per gun to 1500. What I meant to say was - you’ve increased the application’s scope/performance. Then, ‘Star is Born’ (Sib) patterns put it in a class of its own.
Gun Battery rotations. In battery rotation mode, the hosohedron’s main axis (top/bottom) corresponds with the battery’s Y axis rotation, for which the equator consists of eight guns and the poles consist of two 9 gun clusters. In the image above, the hoso gun battery is rotating around the x-axis, one of the hoso’s four azimuthal angles containing 16 gun equators.
The Control panel is filling out very nicely, capable of creating vertigo inducing displays. Sure, I understand what’s causing the effects – particle collisions and motions; rotating the hoso gun battery during firing is an awesome ability that greatly increases the action – gouts of red (post-collided) photons show many collisions are taking place, but with few clear discernable Sib patterns, the lack of focus is overwhelming at times.
I usually kept the rotation under 10, noting 100 seemed over-the-top. The puritanical streak in me would demand that guns travel no faster than photons. I’m still trying to recover from time dilation effects. My point is, with its four main gun axii and polar gun clustering, rotating the hoso gun battery doesn’t do much good. I'd say it causes more confusion than information.
1. Ring battery configuration. Circular firing squad. Between you and me, I believe a ring configuration/battery - containing all the guns - may provide the most focused results and clearest viewing angle. Understanding that the larger the b-photon is, the further removed from the center it is, a single ring at some orientation/angle may occasionally ‘focus’ the b-photon well removed from (0,0,0) at any given moment. Note, can we stop action with a pause? As I believe you indicated above, the best viewing angle of the resulting collisions should be orthogonal to it, along that spin axis, (indicated by the bullseye).
2. Please consider adding Battery orientation controls: x, y, and z for consistency; or azimuth and elevation for a challenge, each a 2PI radian or 360 degree angle slider that changes the configurations’ orientation in space. Separate from battery rotation, turn off rotation to discuss orientation. Battery orientation is a fine control that allows you to change the battery/configuration such as the starting angles before rotation begins.
Giving the user control of the gun battery’s orientation and motion – to the degree you’ve shown possible with this panel - seems like a perfectly good user interface to me.
.
In this image, the 58 gun Hosohedron configuration is spinning counter-clockwise. The green bullseye in the center is the south pole of the gun battery’s x-spin rotation.
Looking good, Nevyn, you’re on a roll. When I said you increased performance of the Virtual Scattering App you interpreted that to mean fps wise, switching from 1700 rounds per gun to 1500. What I meant to say was - you’ve increased the application’s scope/performance. Then, ‘Star is Born’ (Sib) patterns put it in a class of its own.
Gun Battery rotations. In battery rotation mode, the hosohedron’s main axis (top/bottom) corresponds with the battery’s Y axis rotation, for which the equator consists of eight guns and the poles consist of two 9 gun clusters. In the image above, the hoso gun battery is rotating around the x-axis, one of the hoso’s four azimuthal angles containing 16 gun equators.
The Control panel is filling out very nicely, capable of creating vertigo inducing displays. Sure, I understand what’s causing the effects – particle collisions and motions; rotating the hoso gun battery during firing is an awesome ability that greatly increases the action – gouts of red (post-collided) photons show many collisions are taking place, but with few clear discernable Sib patterns, the lack of focus is overwhelming at times.
I usually kept the rotation under 10, noting 100 seemed over-the-top. The puritanical streak in me would demand that guns travel no faster than photons. I’m still trying to recover from time dilation effects. My point is, with its four main gun axii and polar gun clustering, rotating the hoso gun battery doesn’t do much good. I'd say it causes more confusion than information.
1. Ring battery configuration. Circular firing squad. Between you and me, I believe a ring configuration/battery - containing all the guns - may provide the most focused results and clearest viewing angle. Understanding that the larger the b-photon is, the further removed from the center it is, a single ring at some orientation/angle may occasionally ‘focus’ the b-photon well removed from (0,0,0) at any given moment. Note, can we stop action with a pause? As I believe you indicated above, the best viewing angle of the resulting collisions should be orthogonal to it, along that spin axis, (indicated by the bullseye).
2. Please consider adding Battery orientation controls: x, y, and z for consistency; or azimuth and elevation for a challenge, each a 2PI radian or 360 degree angle slider that changes the configurations’ orientation in space. Separate from battery rotation, turn off rotation to discuss orientation. Battery orientation is a fine control that allows you to change the battery/configuration such as the starting angles before rotation begins.
Giving the user control of the gun battery’s orientation and motion – to the degree you’ve shown possible with this panel - seems like a perfectly good user interface to me.
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by Nevyn Mon Aug 05, 2019 11:27 pm
I agree that the hosohedron configuration causes issues at the poles, and rotating guns certainly add to the confusion. However, the reason for using a rotation is to create more randomness. It allows the guns, or at least most of them, to shoot from various directions. Using a ring of guns would be no different than the hosohedron configuration once you start spinning it. It would just take more time to get results because of the loss of density. It would make it easier to see, however.
The hosohedron algorithm can be replaced with another, such as the EQS algorithm. I haven't tried any others yet, but I used the same classes from the Particle Interaction Model we worked on, so they can be used interchangeably.
Note that even when rotating, all guns are still aimed at (0,0,0), ignoring precision. The rotation just changes what direction they are coming in from.
I should be able to use the same pause and step functionality from PIM.
I see the need for an orientation on the battery, but I think I will try some other arrangements before going there.
The hosohedron algorithm can be replaced with another, such as the EQS algorithm. I haven't tried any others yet, but I used the same classes from the Particle Interaction Model we worked on, so they can be used interchangeably.
Note that even when rotating, all guns are still aimed at (0,0,0), ignoring precision. The rotation just changes what direction they are coming in from.
I should be able to use the same pause and step functionality from PIM.
I see the need for an orientation on the battery, but I think I will try some other arrangements before going there.
Nevyn- Admin
- Posts : 1887
Join date : 2014-09-11
Location : Australia -
Re: Virtual Scattering Application
by LongtimeAirman Tue Aug 06, 2019 6:58 pm
.
Sorry, that last image of the Hosohedron gun battery’s counterclockwise x rotation/South pole bullseye I posted was actually the North pole. Here’s the South pole bullseye (with clockwise rotation). Plenty of collisions with no discernable pattern.
I don’t see much to disagree with. How to achieve random is a challenge. Some rotations might surprise you. With all due respect, changing a battery’s orientation or rotation is fun to play with when it’s presented in a simple and immediately interactive way. Who knows what someone will find when they try playing with this thing? No matter what you have planned, I would always think of the user – myself – and try to make it easy/fun to play with or at least more interesting.
We’ve discussed the Hosohedron several times. It’s like one of the family, with a unique equi-partitioning geometry originally intended for mapmaking. I don't agree with "issues over the poles", with respect to the gun battery configuration, the Hosohedron consists of four separate azimuthal planes containing 16 equatorial guns – separated by 45 degrees. The four rings are always creating output patterns in planes that are superimposed and indistinguishable when viewed from any single viewpoints; i.e. even if you are looking straight toward (0,0,0) down along or parallel to one emission plane, all four planes are still intersecting along the y-axis.
Cardinal rings. Yesterday I asked for one ring, today I'm asking for three. Please consider creating (or direct me to do so) a new default gun battery configuration. It will consist of 3 orthogonal, ring battery configurations, x, y, and z. If the number of guns in each ring is divisible by four, and the 3 rings arranged orthogonaly, then a total of six guns – in the cardinal positions, may be said to occupy either of two intersecting rings. The three rings together may be said to complete coverage most effectively, allowing a good output display - from any angle(???).
I make so many mistakes, I’m sure you notice. It’s difficult to be of service, but I’ll keep trying.
.
Sorry, that last image of the Hosohedron gun battery’s counterclockwise x rotation/South pole bullseye I posted was actually the North pole. Here’s the South pole bullseye (with clockwise rotation). Plenty of collisions with no discernable pattern.
Nevyn wrote. I agree that the hosohedron configuration causes issues at the poles, and rotating guns certainly add to the confusion. However, the reason for using a rotation is to create more randomness. It allows the guns, or at least most of them, to shoot from various directions. Using a ring of guns would be no different than the hosohedron configuration once you start spinning it. It would just take more time to get results because of the loss of density.
I don’t see much to disagree with. How to achieve random is a challenge. Some rotations might surprise you. With all due respect, changing a battery’s orientation or rotation is fun to play with when it’s presented in a simple and immediately interactive way. Who knows what someone will find when they try playing with this thing? No matter what you have planned, I would always think of the user – myself – and try to make it easy/fun to play with or at least more interesting.
We’ve discussed the Hosohedron several times. It’s like one of the family, with a unique equi-partitioning geometry originally intended for mapmaking. I don't agree with "issues over the poles", with respect to the gun battery configuration, the Hosohedron consists of four separate azimuthal planes containing 16 equatorial guns – separated by 45 degrees. The four rings are always creating output patterns in planes that are superimposed and indistinguishable when viewed from any single viewpoints; i.e. even if you are looking straight toward (0,0,0) down along or parallel to one emission plane, all four planes are still intersecting along the y-axis.
That sounds like agreement. One ring would likely make collisions easy to view - best from one direction. Logically then, if you haven’t already considered it yourself, my latest request/suggestion will probably not surprise you in the least.Nevyn wrote, It would make it easier to see, however.
Cardinal rings. Yesterday I asked for one ring, today I'm asking for three. Please consider creating (or direct me to do so) a new default gun battery configuration. It will consist of 3 orthogonal, ring battery configurations, x, y, and z. If the number of guns in each ring is divisible by four, and the 3 rings arranged orthogonaly, then a total of six guns – in the cardinal positions, may be said to occupy either of two intersecting rings. The three rings together may be said to complete coverage most effectively, allowing a good output display - from any angle(???).
I make so many mistakes, I’m sure you notice. It’s difficult to be of service, but I’ll keep trying.
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by Nevyn Tue Aug 06, 2019 7:58 pm
I'm thinking of independent rings. Each rotating differently. We create a ring of guns around each axis, and then spin them about a different axis, making sure that no 2 axes are the same. They share the rotation speed so that they are coordinated. Each ring could even rotate about its own axis as well, basically just spinning the circle. This should be able to create charge from all directions.
This would mean that some guns will start in the same position (from different rings), and they will overlap each other at various stages of the rotations. I don't think that is too much of a problem though.
Why do we like to complicate things?
| Ring | Rotation Axis |
| X | Y |
| Y | Z |
| Z | X |
This would mean that some guns will start in the same position (from different rings), and they will overlap each other at various stages of the rotations. I don't think that is too much of a problem though.
Why do we like to complicate things?
Nevyn- Admin
- Posts : 1887
Join date : 2014-09-11
Location : Australia -
Re: Virtual Scattering Application
by LongtimeAirman Wed Aug 07, 2019 10:13 pm
.
Independent rings sounds good. I'd decided to push the cardinal rings idea before asking for independent rings myself. I’m still working on my rationale.
The hoso battery configuration is firing photons which illuminate the b-photon centered at (0,0,0). Generally speaking, larger b-photons are too large to be well detected since the larger the b-photon the further removed from (0,0,0) it becomes, the photon density drops off too quickly. Unless I'm mistaken, you see independent rings as a means of improving incoming charge density by providing a more uniform or even a random distribution of incoming charge photons.
You mentioned that the configuration has a re-targeting capability. Does changing the gun configuration from a 4 ring hoso to 3 independent orthogonal ring set make it easier to re-target - by simple translation or re-centering?
If so, please consider adding battery ring position controls that allow the user to center any or all of the 3 cardinal x, y and z ring planes anywhere in the target zone. That would allow the user to re-center the ring - training the ring's emission on some section of the target b-photon, bringing a larger number of photons to the area under study. Target mode as opposed to your Random mode.
.
Independent rings sounds good. I'd decided to push the cardinal rings idea before asking for independent rings myself. I’m still working on my rationale.
The hoso battery configuration is firing photons which illuminate the b-photon centered at (0,0,0). Generally speaking, larger b-photons are too large to be well detected since the larger the b-photon the further removed from (0,0,0) it becomes, the photon density drops off too quickly. Unless I'm mistaken, you see independent rings as a means of improving incoming charge density by providing a more uniform or even a random distribution of incoming charge photons.
You mentioned that the configuration has a re-targeting capability. Does changing the gun configuration from a 4 ring hoso to 3 independent orthogonal ring set make it easier to re-target - by simple translation or re-centering?
If so, please consider adding battery ring position controls that allow the user to center any or all of the 3 cardinal x, y and z ring planes anywhere in the target zone. That would allow the user to re-center the ring - training the ring's emission on some section of the target b-photon, bringing a larger number of photons to the area under study. Target mode as opposed to your Random mode.
Heck if I know boss, that sounds like a management question to me.Why do we like to complicate things?
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by Nevyn Thu Aug 08, 2019 1:08 am
In order to accommodate a rotating battery, I had to change the way the guns fired bullets. Previously, each gun had a position and a direction that it would fire. Which was fine while they were sitting still. However, once they started to move, that just didn't work. I tried to recalculate the direction, but it didn't work very well. So I just made all guns fire at (0,0,0), there-by ignoring the direction and its problems. I didn't really like doing that, because I like it to be independent of such limitations, but there is no need to fire at any other position (this is all ignoring the precision setting, which will change the exact location it fires at).
So there isn't really any re-targeting, well, I guess you could call it that. It now takes its own scene hierarchy into account (remember that world matrix we discussed earlier?) when determining the position of each gun, and the bullet direction is found by subtracting that position from (0,0,0). I guess we could make that (0,0,0) into a configurable vector, allowing the user to fire at some off-center target.
So there isn't really any re-targeting, well, I guess you could call it that. It now takes its own scene hierarchy into account (remember that world matrix we discussed earlier?) when determining the position of each gun, and the bullet direction is found by subtracting that position from (0,0,0). I guess we could make that (0,0,0) into a configurable vector, allowing the user to fire at some off-center target.
Nevyn- Admin
- Posts : 1887
Join date : 2014-09-11
Location : Australia -
Re: Virtual Scattering Application
by LongtimeAirman Fri Aug 09, 2019 6:46 pm
.
Back to reviewing and cleanup.
.
Back to reviewing and cleanup.
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by LongtimeAirman Sun Aug 11, 2019 6:46 pm
.
Proof of life.
Let me clarify, that is, reviewing and cleaning up what I’ve done. Currently reviewing each scene graph, making sure the animations work, making sure that all guns just poke their barrels through the range wall at r=100, etc. Here, the spirals within a given Spiral ring gun are now random, but all the guns are the same; incremental progress sometimes, plenty to do.
.
Proof of life.
Let me clarify, that is, reviewing and cleaning up what I’ve done. Currently reviewing each scene graph, making sure the animations work, making sure that all guns just poke their barrels through the range wall at r=100, etc. Here, the spirals within a given Spiral ring gun are now random, but all the guns are the same; incremental progress sometimes, plenty to do.
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by LongtimeAirman Tue Aug 13, 2019 6:59 pm
.
When you changed to Hoso, you indicated that Simple gun was the only gun properly sized. I thought my job was to come up with some acceptable guns. I suppose the only way to correct that situation would be to scale all guns to the Simple gun size. Here are some results. Please feel free to indicate otherwise.
Type (scale.x, scale.y, scale.z) left to right, top to bottom.
Simple, the standard scale ( 1, 1, 1 ); SpiralRing (0.85, 0.85, 0.85 ); Ring ( 0.7, 0.7, 0.7 );
HelixRing ( 0.3, 0.3, 0.3 ); Revolving ( 0.333, 0.333, 0.333 ); Cube ( 0.3, 0.3, 0.3 );
Some additional corrections. On the basis of scale, I'll just toss Simple Array - it's too big.
.
When you changed to Hoso, you indicated that Simple gun was the only gun properly sized. I thought my job was to come up with some acceptable guns. I suppose the only way to correct that situation would be to scale all guns to the Simple gun size. Here are some results. Please feel free to indicate otherwise.
Type (scale.x, scale.y, scale.z) left to right, top to bottom.
Simple, the standard scale ( 1, 1, 1 ); SpiralRing (0.85, 0.85, 0.85 ); Ring ( 0.7, 0.7, 0.7 );
HelixRing ( 0.3, 0.3, 0.3 ); Revolving ( 0.333, 0.333, 0.333 ); Cube ( 0.3, 0.3, 0.3 );
Some additional corrections. On the basis of scale, I'll just toss Simple Array - it's too big.
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by LongtimeAirman Thu Aug 15, 2019 4:23 pm
.
Above at left, not shown in the last group due to its extra length, is the Spiral gun, scale (1,1,1). Given the current hoso configuration, as with Simple gun and all the others, adjacent Spiral guns are overlapping a bit at ‘r=the target zone boundary’, I don’t see that as any problem whatsoever.
On the top right, also at scale one, is a recent addition - a barrel topped with two equilateral triangle wings separated by 60 degrees, a tetrahedral dihedral. One can join two such tet-dihedrals together to form a closed tetrahedron. Each side – both inside and outside faces – are of different materials. The more open 2 sided dihedral – as opposed to a closed tetrahedron - shows more interesting motion with minimal obscuration of target scattering. I started by duplicating Simple gun, then swapping out the sphere, bands and endcap with the two tetrahedron faces, - making it simpler than Simple gun. The alternate rotation and pulse color animations work well, including different starting angles and color phase differentials.
The idea came from recalling Alexander Graham Bell’s https://en.wikipedia.org/wiki/Tetrahedral_kite tetrahedral kite. In which case I’m obliged to join a minimum of four such dihedrals to see how it looks. I might have tried it by now but for once the paperwork came first. If it’s OK with you I’d like to keep the dihedral version shown. Oh, and work a kite array version separately.
.
Above at left, not shown in the last group due to its extra length, is the Spiral gun, scale (1,1,1). Given the current hoso configuration, as with Simple gun and all the others, adjacent Spiral guns are overlapping a bit at ‘r=the target zone boundary’, I don’t see that as any problem whatsoever.
On the top right, also at scale one, is a recent addition - a barrel topped with two equilateral triangle wings separated by 60 degrees, a tetrahedral dihedral. One can join two such tet-dihedrals together to form a closed tetrahedron. Each side – both inside and outside faces – are of different materials. The more open 2 sided dihedral – as opposed to a closed tetrahedron - shows more interesting motion with minimal obscuration of target scattering. I started by duplicating Simple gun, then swapping out the sphere, bands and endcap with the two tetrahedron faces, - making it simpler than Simple gun. The alternate rotation and pulse color animations work well, including different starting angles and color phase differentials.
The idea came from recalling Alexander Graham Bell’s https://en.wikipedia.org/wiki/Tetrahedral_kite tetrahedral kite. In which case I’m obliged to join a minimum of four such dihedrals to see how it looks. I might have tried it by now but for once the paperwork came first. If it’s OK with you I’d like to keep the dihedral version shown. Oh, and work a kite array version separately.
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by LongtimeAirman Fri Aug 16, 2019 5:45 pm
.
Today’s four tetrahedron-dihedrals compares closely in position and colors with yesterday’s single tet-dihedral. The single looked good; I think the four array looks better. Don't make me do sixteen. Agreed?
.
Today’s four tetrahedron-dihedrals compares closely in position and colors with yesterday’s single tet-dihedral. The single looked good; I think the four array looks better. Don't make me do sixteen. Agreed?
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by Nevyn Fri Aug 16, 2019 9:28 pm
I think you should get rid of the barrel and just have them shoot out of the point of the pyramid.
Nevyn- Admin
- Posts : 1887
Join date : 2014-09-11
Location : Australia -
Re: Virtual Scattering Application
by LongtimeAirman Sat Aug 17, 2019 9:40 pm
.
Done; the barrel is removed and the dihedrals now 'point' toward the target. Reorienting the dihedrals sounded innocuous enough, doing it turned into a series of challenging problems, the result is worth it, definitely an improvement. I'll scale it down a bit - then cleanup again.
.
Done; the barrel is removed and the dihedrals now 'point' toward the target. Reorienting the dihedrals sounded innocuous enough, doing it turned into a series of challenging problems, the result is worth it, definitely an improvement. I'll scale it down a bit - then cleanup again.
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by LongtimeAirman Mon Aug 19, 2019 12:01 am
.
The 4th spin level target b-photon Trefoil knot (?).
I noticed a problem after my last post. The emissions weren’t coming directly from the top of the three sided pyramid - they were a little off, about half a barrel radius off. Specifying the muzzle position didn’t work. It seemed to be a bounding box problem. I went and created the first dihedral’s (triangles 1 and 2) anti-dihedral (triangles 3 and 4). Together they create a closed tetrahedron but together they didn’t correct the problem. I did eventually find and eliminate 3 grp position x y and z settings at line 638 which did fix the emission problem.
Then I noticed the b-photon appears to be a https://en.wikipedia.org/wiki/Trefoil_knot Trefoil knot. Am I imagining things?
.
The 4th spin level target b-photon Trefoil knot (?).
I noticed a problem after my last post. The emissions weren’t coming directly from the top of the three sided pyramid - they were a little off, about half a barrel radius off. Specifying the muzzle position didn’t work. It seemed to be a bounding box problem. I went and created the first dihedral’s (triangles 1 and 2) anti-dihedral (triangles 3 and 4). Together they create a closed tetrahedron but together they didn’t correct the problem. I did eventually find and eliminate 3 grp position x y and z settings at line 638 which did fix the emission problem.
Then I noticed the b-photon appears to be a https://en.wikipedia.org/wiki/Trefoil_knot Trefoil knot. Am I imagining things?
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by Nevyn Mon Aug 19, 2019 10:44 pm
I have noticed that path, and don't believe I have seen it in any of my other spin apps. I am a bit worried that something is wrong, but most of it looks good.
An AXY spin will look like a trefoil knot. The actual path is not perfect, so it kind of rotates the shape around, over and over. It actually generates a torus, but not by its motion. well, it is by its motion, but it is not a torus type of motion.
However, that path just doesn't look right, but I haven't spent much time looking into it. When I did, I couldn't see anything obvious (and the details are all in matrix math, so hard to see).
An AXY spin will look like a trefoil knot. The actual path is not perfect, so it kind of rotates the shape around, over and over. It actually generates a torus, but not by its motion. well, it is by its motion, but it is not a torus type of motion.
However, that path just doesn't look right, but I haven't spent much time looking into it. When I did, I couldn't see anything obvious (and the details are all in matrix math, so hard to see).
Nevyn- Admin
- Posts : 1887
Join date : 2014-09-11
Location : Australia -
Re: Virtual Scattering Application
by LongtimeAirman Tue Aug 20, 2019 12:50 am
.
I thought the path was unusual. It would be amazing if knot theory is related to stacked spins.
And of course I'm sure it's no surprise to you that I had to see what the sixteen dihedral array looks like. A Sierpinski triangle https://en.wikipedia.org/wiki/Sierpiński_triangle comes close.
Can we keep it? Please?
.
I thought the path was unusual. It would be amazing if knot theory is related to stacked spins.
And of course I'm sure it's no surprise to you that I had to see what the sixteen dihedral array looks like. A Sierpinski triangle https://en.wikipedia.org/wiki/Sierpiński_triangle comes close.
Can we keep it? Please?
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by Nevyn Tue Aug 20, 2019 1:22 am
I'm not sure about them. It's the see-through bits that bug me. They look like pyramids, but then you get close and there are sides missing.
At this stage, I don't really know how these guns are going to be used. I imagine some sort of user control to choose them, but haven't put any effort into setting that up. So at this stage, I don't mind having options.
At this stage, I don't really know how these guns are going to be used. I imagine some sort of user control to choose them, but haven't put any effort into setting that up. So at this stage, I don't mind having options.
Nevyn- Admin
- Posts : 1887
Join date : 2014-09-11
Location : Australia -
Re: Virtual Scattering Application
by LongtimeAirman Tue Aug 20, 2019 6:05 pm
.
The two-sided dihedrals are now changed to four-sided tetrahedrons.
Less see-through, more solid - done. The dihedrals are now tetrahedrons. I've made a few more corrections getting it into its current form making sure all the faces are covered, so to speak. Unless you suggest otherwise, I’ll also change the name to Tetra Array gun. But please bear witness, with all due respect, Alexander Graham Bell’s basic tetrahedral kite is in the code – just eliminate triangles 3 and 4. Of course any code I write is in initial final, there are many ways it can be better written. Such as with fewer group calls, i.e. coming up with a single ‘this.geometry.tetrahedron’ instead of a separate call for every inside and outside triangle. I'll try to improve it some more before moving on.
.
The two-sided dihedrals are now changed to four-sided tetrahedrons.
Less see-through, more solid - done. The dihedrals are now tetrahedrons. I've made a few more corrections getting it into its current form making sure all the faces are covered, so to speak. Unless you suggest otherwise, I’ll also change the name to Tetra Array gun. But please bear witness, with all due respect, Alexander Graham Bell’s basic tetrahedral kite is in the code – just eliminate triangles 3 and 4. Of course any code I write is in initial final, there are many ways it can be better written. Such as with fewer group calls, i.e. coming up with a single ‘this.geometry.tetrahedron’ instead of a separate call for every inside and outside triangle. I'll try to improve it some more before moving on.
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by LongtimeAirman Sun Aug 25, 2019 11:44 pm
.
Update. I haven’t posted for a few days because I’ve been stymied. I’ve switched away from triangles in order to use new THREE tetrahedron geometry – but I must reorient the default polyhedron properly. That doesn't sound too difficult. This autocad image shows the problem/solution. Rotate the new tet geometry 109 degrees clockwise about a spin axis defined by a line from 0,0,0 to 1,0,1. Unfortunately, this solution doesn’t appear to work on the Tetrix gun itself, it’s quite a bit off. I found a close working approximation, off maybe a degree or two, but I haven’t found a working single rotation set or formula yet. I may try to change the default vertices next - that is, when I figure out how.
.
Update. I haven’t posted for a few days because I’ve been stymied. I’ve switched away from triangles in order to use new THREE tetrahedron geometry – but I must reorient the default polyhedron properly. That doesn't sound too difficult. This autocad image shows the problem/solution. Rotate the new tet geometry 109 degrees clockwise about a spin axis defined by a line from 0,0,0 to 1,0,1. Unfortunately, this solution doesn’t appear to work on the Tetrix gun itself, it’s quite a bit off. I found a close working approximation, off maybe a degree or two, but I haven’t found a working single rotation set or formula yet. I may try to change the default vertices next - that is, when I figure out how.
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by Nevyn Mon Aug 26, 2019 1:24 am
The problem may be that the center point of the tetrahedron is in the middle of it. Maybe translate the geometry so that the origin is in a known position of that geometry. You could move the tet down and put the top point at the origin, or you could move it up and put the base at the origin. When you rotate it, the point that is at the origin will not move from it.
I would probably put the top point at the origin and then rotate and translate accordingly.
Another potential problem is how you are doing the rotations and translations. If you are doing those on the Object3D object (most likely a Mesh), then you have to be aware of what order the operations are applied it. Does it rotate and then translate, or does it translate before rotating? Order matters a lot. If in doubt, you can use a Group per operation and then you know that they are applied from the bottom up. That is, the geometry is applied first, then the Object3D operations, then the Group that that Object3D is in, etc, etc.
I would probably put the top point at the origin and then rotate and translate accordingly.
Another potential problem is how you are doing the rotations and translations. If you are doing those on the Object3D object (most likely a Mesh), then you have to be aware of what order the operations are applied it. Does it rotate and then translate, or does it translate before rotating? Order matters a lot. If in doubt, you can use a Group per operation and then you know that they are applied from the bottom up. That is, the geometry is applied first, then the Object3D operations, then the Group that that Object3D is in, etc, etc.
Nevyn- Admin
- Posts : 1887
Join date : 2014-09-11
Location : Australia -
Re: Virtual Scattering Application
by LongtimeAirman Mon Aug 26, 2019 11:20 pm
.
Tetrix gun. We have aligned tetrahedrons. It sure looks prettier when the numbers are correct, thanks for the helpful suggestions. I’m embarrassed to report that my main problem was entering degrees instead of radians. My first clue should have been when my attempted half degree incremental changes resulted in approx. 10 degree rotations. Now, the tetrahedron geometry is almost - except for a final 15deg rotation about y – completed in the init function. The alternate rotations and color pulsing animations are also working.
.
Tetrix gun. We have aligned tetrahedrons. It sure looks prettier when the numbers are correct, thanks for the helpful suggestions. I’m embarrassed to report that my main problem was entering degrees instead of radians. My first clue should have been when my attempted half degree incremental changes resulted in approx. 10 degree rotations. Now, the tetrahedron geometry is almost - except for a final 15deg rotation about y – completed in the init function. The alternate rotations and color pulsing animations are also working.
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by Nevyn Mon Aug 26, 2019 11:37 pm
Ahh, yes, always assume radians.
Nevyn- Admin
- Posts : 1887
Join date : 2014-09-11
Location : Australia -
Re: Virtual Scattering Application
by LongtimeAirman Wed Aug 28, 2019 6:59 pm
.
Forgive the quick in and out, believe it or not, I’m well occupied with Tetrix gun. I keep hoping for more progress till I run out of time. I understand the rotation problem I described earlier mush better; I only gave a partial solution to a problem with several solutions.
Currently, I’m converting the tetrahedrons’ material to a texture that can be animated. Not nearly well yet, I thought I was trying to randomize the colors within a 16 tetrahedron tetrix array. Instead, if you look closely enough, you’ll notice the result is that each tetrix in the image is a different color.
Thanks for your understanding.
.
Forgive the quick in and out, believe it or not, I’m well occupied with Tetrix gun. I keep hoping for more progress till I run out of time. I understand the rotation problem I described earlier mush better; I only gave a partial solution to a problem with several solutions.
Currently, I’m converting the tetrahedrons’ material to a texture that can be animated. Not nearly well yet, I thought I was trying to randomize the colors within a 16 tetrahedron tetrix array. Instead, if you look closely enough, you’ll notice the result is that each tetrix in the image is a different color.
Thanks for your understanding.
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by LongtimeAirman Thu Aug 29, 2019 6:19 pm
.
Better progress today. Previously, when I said the Tetrix gun’s color animation ‘worked’, I meant the entire tetrix changed color as a single unit. All tetrixes sharing the same color, or even sharing a color cycle wasn’t very appealing. That color problem is corrected, my latest changes addresses each of the 16 individual tetrahedrons within each tetrix separately. The color animation – including the alternate color sets you set up long ago, is now a lot nicer.
I’ll try extending the alternate rotation animation next to see what a tetrix with spinning tets looks like.
.
Better progress today. Previously, when I said the Tetrix gun’s color animation ‘worked’, I meant the entire tetrix changed color as a single unit. All tetrixes sharing the same color, or even sharing a color cycle wasn’t very appealing. That color problem is corrected, my latest changes addresses each of the 16 individual tetrahedrons within each tetrix separately. The color animation – including the alternate color sets you set up long ago, is now a lot nicer.
I’ll try extending the alternate rotation animation next to see what a tetrix with spinning tets looks like.
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by LongtimeAirman Sat Aug 31, 2019 6:37 pm
.
Mixed progress this time. The 58 Tetrix guns in the Hosohedron configuration shown indicates that the color animation’ color cycling is working properly. I improved that code by eliminating/relocating the previous invocation to within the tetrix’s 4x4 tetrahedron loop. In addition, I corrected a firing error I inadvertently created last time.
Adding a rotation animation for each individual tetrahedron is turning out to be more difficult. The rotation I added resulted in a new ‘single’ tetrahedron orbiting each tetrix base. The orbit soon develops into a complicated cyclical function, growing then shrinking back to the center, over and over expanding further each time until the 58 tets exceed the model space and are gone.
I should describe a correction to that latest autocad diagram of mine, I said that the green tet is the result of rotating the red tet 109 degrees about the 0,0,0 to 1,0,1 axis. I failed to diagram that. The green angle dimension line was attached to the green tet alone. Instead, rotate the red tet 54.76 degrees (=109.52/2) about the 0,0,0 to (-1,0,1) axis.
I believe I’m spending the time and effort necessary – eventually - in order to learn animations. I apologize to you and any readers for being a slow learner, and for making so many mistakes. I do enjoy trying, thanks again for the opportunity.
.
Mixed progress this time. The 58 Tetrix guns in the Hosohedron configuration shown indicates that the color animation’ color cycling is working properly. I improved that code by eliminating/relocating the previous invocation to within the tetrix’s 4x4 tetrahedron loop. In addition, I corrected a firing error I inadvertently created last time.
Adding a rotation animation for each individual tetrahedron is turning out to be more difficult. The rotation I added resulted in a new ‘single’ tetrahedron orbiting each tetrix base. The orbit soon develops into a complicated cyclical function, growing then shrinking back to the center, over and over expanding further each time until the 58 tets exceed the model space and are gone.
I should describe a correction to that latest autocad diagram of mine, I said that the green tet is the result of rotating the red tet 109 degrees about the 0,0,0 to 1,0,1 axis. I failed to diagram that. The green angle dimension line was attached to the green tet alone. Instead, rotate the red tet 54.76 degrees (=109.52/2) about the 0,0,0 to (-1,0,1) axis.
I believe I’m spending the time and effort necessary – eventually - in order to learn animations. I apologize to you and any readers for being a slow learner, and for making so many mistakes. I do enjoy trying, thanks again for the opportunity.
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by LongtimeAirman Tue Sep 03, 2019 6:39 pm
.
Continued slow progress. In this image, we are looking through the b-photon's stacked spins and target zone down on each Tetrix - close to the target’s perspective. Each tetrix has an animation to alternately rotate about the tetrix’s central y axis - clockwise or counterclockwise in this view. I wish to show all sixteen tetrahedrons of each Tetrix rotating about their own central y axii. Last time my efforts resulted in 58 dangerous looking tets gyrating out into world space. Today, each tetrix contains only one properly spinning tetrahedron, the top back corner 60 degrees different then the other 15 tets. I’m sure that’s a clue; the first tet created is the centermost, closest to the target, brown colored tet, the last tetrahedron created the blue flat top back corner.
I guess I’m not indexing things properly. Using the console, I show vars q, r and count looking for 16. I see 1859 error messages. Ok, 58 hosohedron positions * 16 * 2 = 1854, close except for the doubling. Here's some of the console output.
I'll keep going over everything hoping to improve things, and so far it has. Your patience is appreciated. Friendly suggestions are always welcome.
.
Continued slow progress. In this image, we are looking through the b-photon's stacked spins and target zone down on each Tetrix - close to the target’s perspective. Each tetrix has an animation to alternately rotate about the tetrix’s central y axis - clockwise or counterclockwise in this view. I wish to show all sixteen tetrahedrons of each Tetrix rotating about their own central y axii. Last time my efforts resulted in 58 dangerous looking tets gyrating out into world space. Today, each tetrix contains only one properly spinning tetrahedron, the top back corner 60 degrees different then the other 15 tets. I’m sure that’s a clue; the first tet created is the centermost, closest to the target, brown colored tet, the last tetrahedron created the blue flat top back corner.
I guess I’m not indexing things properly. Using the console, I show vars q, r and count looking for 16. I see 1859 error messages. Ok, 58 hosohedron positions * 16 * 2 = 1854, close except for the doubling. Here's some of the console output.
- Code:
module.TetrixGunGenerator.createModel @ scattering-gun-gen.js:628
module.GeneratedGun.install @ scattering-guns.js:92
module.Battery.addGun @ scattering.js:674
setupSimpleBattery @ scattering.html:278
init @ scattering.html:361
(anonymous) @ scattering.html:183
scattering-gun-gen.js:624 r = 2, q = 3, count = 14
three.min.js:529 THREE.Object3D.add: object can't be added as a child of itself. qa {uuid: "86AACB6D-E33F-409E-8B69-D67609AA05ED", name: "", type: "Mesh", parent: null, children: Array(0), …}
add @ three.min.js:529
module.TetrixGunGenerator.createModel @ scattering-gun-gen.js:628
I'll keep going over everything hoping to improve things, and so far it has. Your patience is appreciated. Friendly suggestions are always welcome.
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by Nevyn Tue Sep 03, 2019 7:21 pm
That error says that you are adding a THREE.Object3D (or a sub-class of it) to itself. Check your variables and what they are pointing to. Something is not what it should be.
With respect to the tets spiraling away, I would assume that is because you were rotating a top level group, which is being used by the system to create the motion and/or aiming direction of all guns. To fix that, if it is the issue, you need to create an intermediate group that you rotate (or whatever you want to do with it) and add that to the top level group. The Model class, which GunModel is a sub-class of, contains a property called object3D which is used to contain the visual representation of the gun. You must not animate that object. You just add things to it and those things can be animated.
I think this would be complicated, but it would look awesome if the individual tets would rotate in such a way that the whole tet reforms. Essentially moving in and out of shape. Each tet doesn't need to move from its position, just rotate until a different point is in the forward direction.
With respect to the tets spiraling away, I would assume that is because you were rotating a top level group, which is being used by the system to create the motion and/or aiming direction of all guns. To fix that, if it is the issue, you need to create an intermediate group that you rotate (or whatever you want to do with it) and add that to the top level group. The Model class, which GunModel is a sub-class of, contains a property called object3D which is used to contain the visual representation of the gun. You must not animate that object. You just add things to it and those things can be animated.
I think this would be complicated, but it would look awesome if the individual tets would rotate in such a way that the whole tet reforms. Essentially moving in and out of shape. Each tet doesn't need to move from its position, just rotate until a different point is in the forward direction.
Nevyn- Admin
- Posts : 1887
Join date : 2014-09-11
Location : Australia -
Re: Virtual Scattering Application
by LongtimeAirman Thu Sep 05, 2019 11:02 pm
.
What NOT to do. var axis = new THREE.Vector3( xPos, 1, zPos ); // be-Czar animation comfortably fitting in the scene.
No progress toward the goal of - Rotating each of the 16 individual tetrahedrons within a tetrix about its own y axis. The color animation works great, a ‘tet’ 60 degree alt-rotation is in motion, but the result is the entire tetrix is alt-rotating as a single object.
Frustration has slowed me some, but I’ve been working at it. I think I understand the subject better.
The THREE.Object3D (or a sub-class of it) error occurs when I try adding meshTet to model.parts.tets as in commented out line 618 // model.parts.tets[(q+1)+'tet'+(r+1)].add( meshTet ); I think that makes sense – don’t add what’s already there.
I added a new THREE Group, model.parts.tets. I add it to model.parts.body, then add model.parts.body to grp. Or I can add model.parts.tets to grp. No apparent difference.
I didn’t expect to post here today. I commited a change to sourcetree but am having network difficulties. I’ll try Fetching and Pushing my latest again later this evening or waiting till tomorrow.
.
What NOT to do. var axis = new THREE.Vector3( xPos, 1, zPos ); // be-Czar animation comfortably fitting in the scene.
No progress toward the goal of - Rotating each of the 16 individual tetrahedrons within a tetrix about its own y axis. The color animation works great, a ‘tet’ 60 degree alt-rotation is in motion, but the result is the entire tetrix is alt-rotating as a single object.
Frustration has slowed me some, but I’ve been working at it. I think I understand the subject better.
I am creating 16 iterations of a single mesh, var meshTet = new THREE.Mesh (this.geometry[(q+1)+’tet’+(r+)], this.material[(q+1)+’tet’+(r+1)]).That error says that you are adding a THREE.Object3D (or a sub-class of it) to itself. Check your variables and what they are pointing to. Something is not what it should be.
The THREE.Object3D (or a sub-class of it) error occurs when I try adding meshTet to model.parts.tets as in commented out line 618 // model.parts.tets[(q+1)+'tet'+(r+1)].add( meshTet ); I think that makes sense – don’t add what’s already there.
Gyrating tets really aren’t a problem, I can still do strange enough as is. For an example of what we should NOT do, I offer today’s image. A sort of tetrahedron/tetrix/Hosohedron target nesting distortion, just 60 degrees from normal.With respect to the tets spiraling away, I would assume that is because you were rotating a top level group, which is being used by the system to create the motion and/or aiming direction of all guns. To fix that, if iI t is the issue, you need to create an intermediate group that you rotate (or whatever you want to do with it) and add that to the top level group. The Model class, which GunModel is a sub-class of, contains a property called object3D which is used to contain the visual representation of the gun. You must not animate that object. You just add things to it and those things can be animated.
I added a new THREE Group, model.parts.tets. I add it to model.parts.body, then add model.parts.body to grp. Or I can add model.parts.tets to grp. No apparent difference.
I agree - that's a next next logical step. Once each tet is individually addressable, there are any number of ways to perform rotations, including: simultaneous, phased, or random. Same goes for the spin axis: about y, or some other axis, or random, or place the point of rotation on the edge, vertex, or outside the individually spinning tetrahedron. I'm anxious to get to that next step. After many hours of effort I’m close to begging for your further assistance.I think this would be complicated, but it would look awesome if the individual tets would rotate in such a way that the whole tet reforms. Essentially moving in and out of shape. Each tet doesn't need to move from its position, just rotate until a different point is in the forward direction.
I didn’t expect to post here today. I commited a change to sourcetree but am having network difficulties. I’ll try Fetching and Pushing my latest again later this evening or waiting till tomorrow.
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Re: Virtual Scattering Application
by Cr6 Fri Sep 06, 2019 1:21 am
Very cool stuff guys! Amazing actually considering it all: 
Cr6- Admin
- Posts : 1178
Join date : 2014-08-09 -
Re: Virtual Scattering Application
by LongtimeAirman Sat Sep 07, 2019 11:04 pm
.
Hey Cr6. I agree, it’s amazing all right. Nevyn can speak for himself, but it occurs to me that someone viewing this thread might conclude this app is sim-pretty mathematical hooey. On-the-contrary, the Virtual Scattering app is well made, perfectly valid, cutting-edge, charge field subject of interest – the charged particle.
Furthermore, as an ongoing working project, Virtual Scattering is certainly capable of developing in unexpected and surprising ways. That’s generally a good thing, a reward for making the effort. I personally see Virtual Scattering as a sandbox/training ground resource by which I can learn coding skills necessary to make cool stuff. if I live long enough. Thank you Nevyn. As such, we are not alone, I would argue this application - a real on-line, on-going project approach may be a model/means for making real developments and in boosting public awareness in the charge field.
If you can work with others, I would invite anyone with similar interests to join in.
.
Hey Cr6. I agree, it’s amazing all right. Nevyn can speak for himself, but it occurs to me that someone viewing this thread might conclude this app is sim-pretty mathematical hooey. On-the-contrary, the Virtual Scattering app is well made, perfectly valid, cutting-edge, charge field subject of interest – the charged particle.
Furthermore, as an ongoing working project, Virtual Scattering is certainly capable of developing in unexpected and surprising ways. That’s generally a good thing, a reward for making the effort. I personally see Virtual Scattering as a sandbox/training ground resource by which I can learn coding skills necessary to make cool stuff. if I live long enough. Thank you Nevyn. As such, we are not alone, I would argue this application - a real on-line, on-going project approach may be a model/means for making real developments and in boosting public awareness in the charge field.
If you can work with others, I would invite anyone with similar interests to join in.
.
LongtimeAirman- Admin
- Posts : 2078
Join date : 2014-08-10
Page 4 of 4 • 1, 2, 3, 4
Page 4 of 4
Permissions in this forum:
You cannot reply to topics in this forum