Atomic Model Editor

Ambient Charge Field

The app now contains a rudimentary ambient charge field system. It is not visible in any way other than how it affects the atoms which will rotate in various ways depending on the charge and anti-charge values. The north axis will spin based on the charge value and the south axis will spin based on the anti-charge value (I think I have those the wrong way around, as far as Miles defines them, but it doesn't really matter). The net spin from the axes is then applied to the core and carousel level.

Defining Elements

There is now a working set of UI controls that allow you to edit an elements proton, neutron and electron counts. I spent some time trying to get all of these controls on the screen but it was a nightmare. So I came up with an idea to show a button per proton stack which would then popup the controls to edit that stack. I think this works a lot better than my previous attempts but is still a little bit clumsy. I did have an idea of arranging the proton stack buttons to mimic the structure of the atom but it is difficult to represent a 3D structure in a 2D hierarchy and I eventually want to do these edits from within the 3D world (ie, double click on a proton stack to edit it) so it is not really worth spending too much time on.

Placing Elements

I have implemented some functions that place the elements in various ways. From lines to grids to rings to spirals. I'm not sure how useful these will be for you guys but they are good for me to test things like level-of-detail and behavior scheduling.

Level of Detail

The 3D structure of the elements can now use level of detail (LOD) nodes. Each LOD node contains a number of child objects but it will only show one of them based on how far away the LOD node is from the camera. Therefore, I use less and less detail, and hence less and less power required to render them, the further away it is. While this works, I am not very happy with how it has been implemented. I fitted it into the structure at the most convenient spot in the code to test it, but this is too low. Therefore, there are too many LOD nodes. Unfortunately, moving the LOD nodes higher up the hierarchy is proving difficult because of other factors.

Element Selection

You can click on an element to select it. Clicking anywhere else or on another element will deselect the current selection (and select the new one). Control+click will add to/remove from the selection. When an element is selected, it will be used in some of the dialog boxes used to define elements such as the 'Define element' and 'Define JSON' dialogs. The 'Define element' dialog can only use 1 element at a time so it will edit the first selected element or create a new one (just the definition, not the viewable atom) if none are selected.

Progress Monitor

I have fixed some bugs in the progress monitor. This allows it to handle many consecutive operations without the progress bar disappearing. When on the 'Select element' dialog, you can quickly press an element button, say 10 times, and it will load them all in with no glitches.

I also fixed some bugs in the loading system that caused some crashes. I created a loading system that only allows 1 action at a time and the tasks of that action are performed in small steps from within the rendering loop. This allows the progress monitor to be updated and show the progress to the user. I previously had 2 streams within the loading system. One for building individual elements and another for rebuilding all elements. The idea was that if 2 requests came it to rebuild the elements, and neither of them had started executing yet, then we can ignore the second request because the first will satisfy it. Unfortunately, the 2 loading streams could collide so I reduced it to 1 stream so the system is much more stable.

Motion Controls

Previous versions of the Atomic Viewer used one of the control schemes in the three.js examples (OrbitControls.js). I didn't like the way this was working. It was fine if you only had 1 or 2 models in the scene but once I added the placement functions, its limitations started to show up. The main problem with the previous control scheme was that it only allowed you to zoom in so far and the closer you got to the 'center' the slower it zoomed. So I have changed that control scheme so that it moves around in the scene rather than being locked to a certain orbit location.

This works much better now but there are some limitations on touch devices. On a PC, the left mouse button will rotate the view while the right mouse button will pan in the X and Y planes. On touch devices, you can mimic the right mouse button with a three fingure gesture. I haven't tried this but the code is there to support it. You can still rotate the view and move in the Z plane (2 finger gesture, bring fingers together to move forward, apart to move backward).

On a PC, you can hold down the shift key to amplify the distance moved in any direction. You can hold down the control key to attenuate the distance so that you have more precise control over motion. If you hold down both at the same time, then it will just move like normal since the amplification and attenuation will offset each other.

Periodic Tables

The system now supports multiple periodic tables. Use the 'Select source' action to choose between the available models. There are currently 3 models: 'Nevyn's periodic table', 'Cr6's periodic table' and 'Test Models'. This last one is some models I made up to test various things. Have a look at the neutron models to see how far you can go with neutron and attachment placement. Then set the neutrons to rotate and watch all of that glorious motion. Its mesmerizing. The attachments model is an illegal structure as far as atoms go, but is there to test the system, not demonstrate good element structure.

Key Bindings

There are some keyboard bindings that can be used for various tasks.

space - will pause/unpause the 3D scene rendering.
h - will hide/show the control panel.
t - will show the 'Select source' dialog.
e - will show the 'Select element' dialog.
d - will show the 'Define element' dialog.
j - will show the 'Define JSON' dialog.
s - will enable/disable the motion controls.
r - will reset the viewing position, orientation and scale to the default settings.
delete - will delete the selected entities.
backspace - will delete all entities.

I just noticed that there is a slight bug in Firefox, but only when using it from the web. If I load it up from my local system, then it displays correctly. However, if I load it through the web site, which should be the exact same source code, the view seems to move up a bit so the top of the page is not quite rendered correctly and the bottom shows a gap. Doesn't do this in Chrome or IE.

Speaking of loading from your local system, this is not really feasible anymore. Unfortunately, when loading textures, it checks for cross-site security issues (on the web, you can't really retrieve resources from different places unless the server says that it is ok to do so) and if you don't have a back-end server, such as loading direct from a file, it will not load the textures. I solve this by using a back-end server so that I can run locally while developing and when I deploy to the web, it already has a back-end server. It isn't really that hard to run a server but it is probably more than most are willing to do.

Nevyn, It’s been a week. I thought you’d be resting on some laurels for a bit, but no, instead, we get Atomic Viewer 0.5, and then, the Stacked Spin Motion Simulator.
 
AV.5 is on as I write. I’m a bit more apt to trip over a word or two. 19 Neutrons 1 reminds me of a fire hydrant, while 21 Attachments 1 works like a well stacked waitress. In any case, the immediate appreciation and understanding one gains from the viewer is amazing.

Charge Field Enabled. Did you happen to come up with your carousal spin rule after first viewing your model? Using the same logic, are you sure you’re not still missing any spins? I would assume that matter, especially an alpha, at the “attachment” locations would de-synch the pillars and hooks, as well as introducing the channel fluctuations you have already noted. I could only say that because of AV 0.5.

Thanks for the “shaders” and “compute unit” updates. I was current when object versus pixel was in full swing. I gotta say that you software guys are closer to old time engineers than today’s engineers are. And as far as engineers “always wanting more power”; that’s the military industrial complex. IMO engineers just want to know the “power of their tools”.

Thanks for being the responsible adult. You’re generous with your thoughts and many of your ideas are new to me. I’ll keep hoping to find some wisdom to return. I saw Cr6 recommend you copyright this JSON, or whatever. I definitely second it. It’s just a baby, but honestly, ideas do come to mind, like - Rockin’ Sockin’ Atoms!

I do suffer from that Firefox clipping the top of the image bug, as you could probably guessed from my prior screenshot.

I’ll continue to play with AV 0.5. I guess I’ll try to help with the math too. More later.

I may beg for a texture-free version to run and dissect on my own at some point, just to see if I can bang two atoms together.

LongtimeAirman wrote:Charge Field Enabled. Did you happen to come up with your carousal spin rule after first viewing your model? Using the same logic, are you sure you’re not still missing any spins? I would assume that matter, especially an alpha, at the “attachment” locations would de-synch the pillars and hooks, as well as introducing the channel fluctuations you have already noted. I could only say that because of AV 0.5.

In my desktop version I made the carousel levels rotate because that is what Miles had said they would do in most situations. I was just going to do the same thing in this web version, in fact, that is exactly what I did do. As I sat back and watched the carousel spin on a model, I started to think about what else might spin and the obvious first thing to look at is the other nucleon, the Axis. That got me thinking about charge to anti-charge ratios and how that would affect the spins. It seemed pretty straight forward that the Axis rotations would affect, if not cause, the Carousel rotations. That got me thinking about Miles papers on superconductivity where the Carousel level actually stops spinning which increases through-charge. Which I thought might be the result of both Axis arms spinning the same way (from a given direction, eg looking top-down). All of this was before he published his latest papers where he discusses neutrons changing charge flow directions so I was pretty impressed with myself when I read that paper. Anyway, it just seems obvious to me that the charge to anti-charge ratio must cause all of this rotation so that's what I implemented and I think it turned out pretty well.

Have I missed any spins? I don't think so, but it's possible. Once I had the Axis arms spinning, I looked at the Carousel level arms and thought that there is no reason they can't spin too. But I couldn't see any obvious force to make them spin and I couldn't see any way that they would affect the rest of the atom so I have not implemented it. I am open to discussion about any other spins you think may be needed. It could be that the charge that comes through from the north and south and then flows out the carousel level could cause the carousel arms to spin just as it causes the axis arms to spin. I would need to determine how much charge goes to the carousel and how much goes to through-charge and then use the same logic that causes the carousel to spin based on the axis charge. That does sound feasible now that I think about it a bit more deeply. That is going to mean that nearly everything is in motion when all of this is turned on (I will add controls to allow the user to enable/disable the different levels of charge-spin).

The attachment locations would definitely affect the rotation of the Axis arms, even if just causing a drag from their mass. I'm not sure I understand exactly what you mean by de-sync the pillars and hooks. I assume you mean that if the north pillar has an attached alpha, then the north hook would spin faster than the pillar and this is more than likely to be correct. At the moment, the whole arm is spinning, not each individual alpha in the arm but I may need to go deeper to implement these kinds of spin differences.

LongtimeAirman wrote:Thanks for the “shaders” and “compute unit” updates. I was current when object versus pixel was in full swing. I gotta say that you software guys are closer to old time engineers than today’s engineers are. And as far as engineers “always wanting more power”; that’s the military industrial complex. IMO engineers just want to know the “power of their tools”.

Professionally, I call myself a Software Engineer, because to me, the definition of an engineer is someone who makes the tools they need if they are not available. An engineer designs and builds things where-as a 'programmer' just builds things kind of like a 'mechanic' just fixes what the engineers designed and built. There is a lot of overlap. I also consider all programmers to be scientists because they don't really have a choice but to use the scientific method. We are always testing what we build against reality (where 'reality' may be the language you are using or it may be the requirements you are implementing, etc). A program that does not operate according to its 'reality' is not very useful. In some ways, we are tied more closely to the scientific method that 'scientists', since they, at least the theorists, seem to prefer to run away from reality at the first opportunity and hide in complex math.

LongtimeAirman wrote:Thanks for being the responsible adult. You’re generous with your thoughts and many of your ideas are new to me. I’ll keep hoping to find some wisdom to return.

I'm not sure what you mean here about being the responsible adult. I think I've missed the reference or something.

LongtimeAirman wrote:I saw Cr6 recommend you copyright this JSON, or whatever. I definitely second it. It’s just a baby, but honestly, ideas do come to mind, like - Rockin’ Sockin’ Atoms!

I couldn't find where Cr6 recommended copyrighting the JSON format. To be honest, I haven't even thought about it and I'm not sure how one would go about doing so. I don't mind if other people use it for their own work. Actually, that is what it was designed for, really. I don't consider it something that I 'own'. The code for my apps is a different story, that is mine and while I don't mind anyone using it, even looking at the source code to see how I have done things, I do not want anyone taking credit for it as their own work. I really should look into adding a licence to it to stop that, at least legally.

LongtimeAirman wrote:I do suffer from that Firefox clipping the top of the image bug, as you could probably guessed from my prior screenshot.

That is a strange bug. My only guess at this point, and I have not looked into it at all, is that the server is adding something to the page that causes it to display slightly differently. The app listens for changes in page size so it should adjust when things change (such as the browser showing a bar at the top).

LongtimeAirman wrote:I’ll continue to play with AV 0.5. I guess I’ll try to help with the math too. More later.

I may beg for a texture-free version to run and dissect on my own at some point, just to see if I can bang two atoms together.

I will look into being able to disable textures or some way to get them working from a file. It is possible to work from a file but it was a bit problematic so I just moved it into a server. Now that I have that part of the code settled down, I might be able to re-work it again and get it operating from the file system again.

I'm just happy that you guys are using it. I am looking at hosting options which I will have to pay for and I don't really want to commit to that unless there is a good reason to. If I do create a more formal hosting arrangement, I will send a link to Miles and see if he wants to use it, publish it, recommend it to his readers, etc.

Nevyn wrote:A program that does not operate according to its 'reality' is not very useful. In some ways, we are tied more closely to the scientific method that 'scientists', since they, at least the theorists, seem to prefer to run away from reality at the first opportunity and hide in complex math.

Just wanted say again Nevyn, awesome work! It is really a stand out "tour de force" for demonstrating all of this material.

I have a question for you all.

If the axis level can spin because of the ambient charge field, as I have implemented in the Atomic Viewer, would that affect bonding between elements? The spins would need to be slowed considerably, possibly to a complete stop, in order for the atoms to join. That is assuming that the bonds are very close. Miles has hinted that they are not quite as close as I have previously modeled them but has not given a very clear picture of how far apart they are.

To be clear, in my previous models, when building molecules, I would put the hook protons from each atom together so that they formed an alpha-like structure (I really have to stop calling it an alpha, proton stack is a better name). This is definitely too close.

Let's work with an example for clarity.

We have 2 atoms, A1 and A2, it doesn't matter what they are, just that they have hooks. Let's say they both have all 9 inner locations filled with 6 protons in each stack. A1 has a north hook stack with 2 protons in it. A2 has a south hook stack with 4 protons in it. This means that they can bond at A1.hook.north and A2.hook.south and complete that position with 6 protons.

There are 3 general possibilities:
  1) the atoms come very close together so that the bonding protons (2+4) form a proton stack with 6 protons in it (minus neutrons, so not quite a proton stack). Miles has ruled this out. This is a nuclear or atomic bond, not a molecular bond.
  2) the atoms come close together so that the 2 and 4 stacks overlap each other.
  3) the atoms are close but the protons do not overlap at all. This just leaves the charge field streaming between them as the bond.

Which one do you think is the most likely? I am thinking that 2) is the correct choice for a molecular bond. Miles has stated that the bonding protons 'move over' to accommodate the incoming protons so that implies some overlap. However, this does require the proton stacks to be in alignment as they bond. Therefore, any spin on that axis, or at least the hook stacks, needs to be stopped or synchronized.

Maybe this is another thing that stops some elements from bonding. Miles has mentioned that the charge streams can be too strong to let small elements bond with big ones and this makes sense but maybe there is more to it. Maybe that charge is causing the stacks to spin and obviously the stronger charge stream will make it spin more so they can not sync up. If the elements do come close to each other, then the stronger field would force the smaller atom to spin faster and faster, possibly to the point of breaking it, but that need not be the case every time. But if the atoms are compatible, then the stronger charge field of one atom causes the hook stack on the other atom to spin and synchronize which allows the atoms to move even closer and a bond is formed.

What do you think? Any ideas?

As currently implemented, AV0.5 is strictly an atom viewer, not a molecular viewer.
It is beyond the model to explore the conditions under which the bond is formed,
we can only show models that are presumably valid under limited conditions.
But you know that, so this is a discussion.

Atoms are stable under wide energy variations. Of course, molecular bonds are much weaker than atomic ones.
Miles (or us either) hasn't agreed on the definition of a molecular bond.
As far as I can recall, none of Miles' molecular bonds were identified as such.
He has portrayed the fact that some bonds, like water, involve angles, in a merged charge flow.
I suppose a molecular bond can be understood as a less than 100%, (degree-wise) alignment.
There must be charge losses at those bonds.
I believe that the proton stacks merge, but you allow small angular losses in molecular bonds.  

In a balanced charge field, north and south arms are always spinning in contrary directions.
They are always passing two-way traffic, and you have determined the spin differential.
The spinning prevents bonds from spontaneously forming.

I agree that large charge channel flows drive away smaller atoms. That channel capacities should be matched.

Yet individual atoms channel charge that reflects the ambient field, and Not the entire charge carrying capacity of a larger atom.

It is extremely unlikely for a molecular bond to form in the isolated ambient conditions modeled by AV0.5
I tend to think of the spins as a "long-term" equilibrium condition.
Under bonding conditions I see no reason why the axis couldn't be slowed down or immobilized (to some extent) while bonds form.

I assume the charge field can be enlisted to increase the likelihood of bond formation (Increase/decrease temp, acid/base, gas or fluid media).
Do molecular bonds take or create energy in their formations?  

I cannot envision a large atom "blowing apart" a smaller atom as a result of joining ends in a normal, balanced charge field. Only the bond should fail.

Hope something connects.

I'm at work at the moment so I can't devote my attention to it in a chat.

LongtimeAirman wrote:As currently implemented, AV0.5 is strictly an atom viewer, not a molecular viewer.
It is beyond the model to explore the conditions under which the bond is formed,
we can only show models that are presumably valid under limited conditions.
But you know that, so this is a discussion.

Yes, that is true, but I am trying to figure out what I need to handle at the atomic level so that I can eventually work with it at the molecular level. My current view of this project is that the Atomic Viewer will always be only an atom modeling application. I will start a new project to deal with molecules at some future time. However, the Atomic Viewer needs to show as many variances as we can think of, some of which will be used when bonding. I was thinking about the axis spins, as we have been discussing, and I suddenly realised that it would affect bonding so I put the question out there to see what others thought about it.

LongtimeAirman wrote:Atoms are stable under wide energy variations. Of course, molecular bonds are much weaker than atomic ones.
Miles (or us either) hasn't agreed on the definition of a molecular bond.
As far as I can recall, none of Miles' molecular bonds were identified as such.
He has portrayed the fact that some bonds, like water, involve angles, in a merged charge flow.
I suppose a molecular bond can be understood as a less than 100%, (degree-wise) alignment.
There must be charge losses at those bonds.
I believe that the proton stacks merge, but you allow small angular losses in molecular bonds.

I remember one of Miles papers saying that molecular bonds are a bit further away than an atomic bond. I can't say which paper though.

LongtimeAirman wrote:In a balanced charge field, north and south arms are always spinning in contrary directions.
They are always passing two-way traffic, and you have determined the spin differential.  
The spinning prevents bonds from spontaneously forming.

Yeah, I thought about that at first too. The arms, or hook stacks, should be spinning in opposite directions which would reduce the chances of a bond. Then I realised that chemical reactions take time. Time on our scale, not an atomic scale. A second to an atom is like a life time to us. The opposing spins provide a reason for that reaction time.

LongtimeAirman wrote:I agree that large charge channel flows drive away smaller atoms. That channel capacities should be matched.

Yet individual atoms channel charge that reflects the ambient field, and Not the entire charge carrying capacity of a larger atom.

True, to an extent. Individual atoms channel charge from within their vicinity. Their own little ambient field, if you like. This is not exactly the same as a general, or global, or universal ambient field. When a larger atom comes near, the charge field of that larger atom becomes a part of the smaller atoms ambient field, increasing it (or decreasing it, depending on the orientation of each atom). Therefore the smaller atom will respond to the altered charge field because it has no other choice. It can only work with charge that it encounters, no matter where it comes from.

LongtimeAirman wrote:It is extremely unlikely for a molecular bond to form in the isolated ambient conditions modeled by AV0.5
I tend to think of the spins as a "long-term" equilibrium condition.
Under bonding conditions I see no reason why the axis couldn't be slowed down or immobilized (to some extent) while bonds form.

I was only thinking about the spins as an equilibrium condition too, hence the way it is implemented now. However, I am using bonding as a test to determine how, and if, these spins occur. While this app won't deal with bonding directly, it must support the features of an atom that do allow bonding.

LongtimeAirman wrote:I assume the charge field can be enlisted to increase the likelihood of bond formation (Increase/decrease temp, acid/base, gas or fluid media).

Yes, all of those things are often needed for reactions to occur between specific elements. Temperature is an interesting one because most reactions will work better if heated. Which is just adding more charge that would be used by the atoms to strengthen their charge fields. This then allows them to manipulate each other more effectively, that is, synchronizing their spinning hook stacks, and bond more easily.

LongtimeAirman wrote:Do molecular bonds take or create energy in their formations?

I would say that molecules change the ambient field in their local area, as compared to that field with the individual atoms in it. This can be measured as an increase or decrease in energy because such measurements are made with respect to the ambient field. I think a molecule must use the charge field in a more efficient manner than its components could, otherwise, why would it form? So in most cases, a molecule will channel more charge than the sum of its atoms and it will do it more effectively. It is hard to say exactly what 'effectively' means as it changes in different circumstances. It may make the molecule radiate more charge making it stronger, that is, it can repel attacks from other particles more easily. It may make the molecule more magnetic if the charge is channeled out the equator. It may make it more electric if it handles through-charge better. It may appear to take heat from the area if it changes the ambient charge into something else (photons, electric current, etc) or it may add heat which the first example of a radiating molecule would do.

LongtimeAirman wrote:I cannot envision a large atom "blowing apart" a smaller atom as a result of joining ends in a normal, balanced charge field. Only the bond should fail.

Yeah, I think I was being a little bit over-dramatic there. I just thought that if the hook stack was given enough rotation, then the rest of the atom may not be able to handle it so it might break. It is probably more likely that it just gets pushed away. Does that mean there is a limited time span where the atoms must sync up or they part ways? A first date, if you will? Which makes the spin synchronization the mating dance. Either the atoms are compatible, in-step with each other, or they move on.

LongtimeAirman wrote:Hope something connects.

Yes, it definitely has. Thanks. Greatly appreciated.

Nevyn, I’ve been thinking a bit more on the subject. I would like to add:

Every proton position is free to spin, hence the disc shape. But the spin can be CW or CCW. AV doesn’t currently distinguish between the bottom or top of the proton’s spin. All of those spins in the proton stack are important because as they line up angular momentum is increased. I don't know if there is any gain in trying to address each proton in this model, but let me urge you to include it in the next.

Alpha. Why wouldn’t the spin relationship between the top and bottom protons in an alpha be the same spin difference displayed between the north and south caps in AV? Both pairs of neutrons and protons in an alpha are thus “balanced”. Proton stacks comprised of balanced alphas makes the most sense to me.

I’m glad you made the time point. Adding spin considerations to the dynamics of bonding seem fair. Obviously, the quickest way to change spins would be to bring two atoms close together, as in an allowed bond, charge channeled between the two atoms would begin to increase, also affecting the various spins.  

Molecular Gap. I read Period Four and scanned several papers without finding a molecular ‘gap”. Though Miles does do a “quick” calculation of how far from the pole the electron is circling. That kind of math, turning a magnitude difference into a radial distance, is hard to categorize.

I gotta say these atomic papers are making more sense than ever. Still, the idea of nuclear charge channeling, a force capable of fission, constantly recycling at "density" levels far above the ambient we are familiar with is difficult. How can atomic matter channel together so much charge at such high "pressures" without tearing itself apart? Don't worry. that doesn't need answering, just stewing.

LongtimeAirman wrote:Every proton position is free to spin, hence the disc shape. But the spin can be CW or CCW. AV doesn’t currently distinguish between the bottom or top of the proton’s spin. All of those spins in the proton stack are important because as they line up angular momentum is increased. I don't know if there is any gain in trying to address each proton in this model, but let me urge you to include it in the next.

Wow. You really had me thinking on this one.

However, the disc shape must be understood as representing the charge emission of the proton. It is not a solid structure and is not even really part of the proton itself (although we often take it as being so). It is a series of vectors pointing out from the surface of the proton (not really a surface but its outer spin radius expressed as a volume) that represent the charge direction and density (you could use the length of the vector as the density since charge always travels at c).

Now, along each of those vectors, charge photons travel and each of those charge photons is spinning. I assume it is spinning about that vector. That is, if you are looking down the vector and the charge photon is coming straight at you, then it will be spinning CW or CCW. This is what Miles seems to assume but I believe there are 2 other axes that it could be spinning about providing 6 possible spin directions: Xcw, Xccw, Ycw, Yccw, Zcw, Zccw. But I digress. Let's assume it is CW or CCW when coming straight at you.

This charge spin magnetism will cause a torque but the interesting thing is that it will cause a torque in opposite directions depending on whether you hit it from above or below. If hit from below, then the tangential velocity will be measure from 6 o'clock  and pointing to the left, say. If hit from above, then the tangential velocity is measured from 12 o'clock and is pointing right. So even with just 1 proton, we already have what appears to be 2 spinning discs rotating in opposite directions but neither of them are actually rotating. The charge photons are really moving radially from the proton and can exert force in 3 directions (the 2 magnetic directions and the electric from linear velocity).

So I don't think we can make that 'disc' spin and I don't think we need to.

LongtimeAirman wrote:Alpha. Why wouldn’t the spin relationship between the top and bottom protons in an alpha be the same spin difference displayed between the north and south caps in AV? Both pairs of neutrons and protons in an alpha are thus “balanced”. Proton stacks comprised of balanced alphas makes the most sense to me.

You had me all excited with this one. I was in full agreement, until I thought about what I wrote above. So how does that affect an alpha?

If we assume that the 2 protons in an alpha are working with opposite charge streams and therefore are emitting charge that is opposite each other, then how would that charge appear to each other? That is, when the 2 charge emission fields meet, how are they spinning with respect to the other.

If the north proton is emitting CW charge, looking straight at the charge vector as described above, then the south proton is emitting CCW charge from the same perspective. So from the 6 o'clock position on the north charge the tangential velocity is pointing to the left, and the 12 o'clock position on the south charge is pointing to the left also. Therefore the charge force is doubled. That is, a particle trapped in between the 2 protons would feel a push to the left from both above and below, doubling the force. From the outside, we find that the alpha appears to rotate 1 way only. The 12 o'clock position on the north charge is pointing right and so is the 6 o'clock position on the south charge so a particle hitting it from above will feel the same force as one hitting from below.

So, ironically, the 2 proton alpha has actually taken us back to 1 apparent spin direction while the single proton gives us 2.

LongtimeAirman wrote:I gotta say these atomic papers are making more sense than ever. Still, the idea of nuclear charge channeling, a force capable of fission, constantly recycling at "density" levels far above the ambient we are familiar with is difficult. How can atomic matter channel together so much charge at such high "pressures" without tearing itself apart? Don't worry. that doesn't need answering, just stewing.

And I love to stew on such questions, so here goes...

Spin!

High pressures are a problem when all you have is linear motion. Everything must fly apart in such a model but spin changes everything. I believe that spin is the best way to express energy and I believe that precisely because linear motion moves things apart but spin doesn't take up space (or much of it, in the case of stacked spins). You can add a hell of a lot of energy to a particle without it moving anywhere. You could say it is internal energy, in a way.

So the parts of the nucleus, the protons and neutrons, use energy in spin while the charge photons use energy in linear velocity. The charge photons do have stacked spins themselves though, so they can gain/lose spin levels while still maintaining a linear velocity of c. If all spins are stripped from a charge photon then it may slow below c but it would soon be hit and start spinning again soon enough. This allows the charge and nucleons to exchange energy without destroying the larger structure.

You mentioned 'density levels far above the ambient' that I thought I may be able to address. When I look at a single proton and think about its charge interactions, I see a director. It does not create, nor destroy motion (or force or mass or energy), it just directs it. But in this way, it does create a measurable force. It does so by taking what was random and making it coherent. The forces were all there, all the time, but the proton has directed them to apply themselves about its equator so the result is a greater repulsion while also less repulsion at the poles since most charge coming at the poles gets directed to the equator so it doesn't find any resistance. So the proton does not create a charge density far above the ambient, but it is noticeably above it. Enough to affect other particles.

I would also like to point out that because of this, any charged particle defies entropy because it creates order from disorder. Although, I don't believe in entropy as order, myself.

Nevyn, Thanks for correcting my misunderstanding of proton and alpha emissions with your excellent descriptions!

Radial vector profile, nice. Every recycling particle type has one, including atoms, a description of the particle’s emission field.

I recently convinced myself that light-speed charges spin orthogonally to their forward direction, whatever its spin level. You indicate that while that seems to be Miles’ view, you have your own opinion, based, I assume, on your stacked-spin model. I’ve played with it some, but not enough to make any comments, which I’d save for that thread.

Thanks especially for your spin insights.

With so many other threads having popped up, I'll hold off asking additional questions here.

I feel a bit mixed on the top-level spin axis vs linear velocity vector relationship. When I look at the stacked spins it does appear to me that a particle would prefer to travel along its top-level spin axis since this offers the least resistance to the field. So in that way, I agree with Miles. However, when discussing charge photons, for some obscure reason, I don't think of them as having stacked spins, when I should. My statements about the charge being able to spin about any of the 3 axes was made thinking of them as spheres or BPhotons (even though I explicitly mentioned them having stacked spins) and I could not see a reason for them to be able to spin about one axis only. At this point, I think you are probably better off keeping that assumption that they travel along their top-level spin axis while keeping an eye out for any information to confirm or deny that assumption.

This discussion does show the power of these applications. I have had years of working with and on them and that gives me a good understanding of the low level entities and their vectors. However, sometimes I still get confused and miss some important connections, even if I have actually made those connections in the past. Now you guys have access to them and while you won't get the benefit of building them and having to figure out what is going on and how to model that, you still get to see the results which is a big part of it.

The stacked spin app is a prime example. It is easy to look at that app and play with it for a while and then move on. However, there are so many layers of information to be found in it that it is easy to move on too early. It is good to take some time and let the info sink in to your mind and then come back to it and see what else you can find. Not all of the information is given to you by the app. You must use what the app gives you and then add in other things in your mind and try to figure out what would happen. For example, setup a certain spin structure and then try to figure out how it would interact with an ambient field. It is not a precise operation but it teaches you how to think about these things and then you will be able to apply that to other areas more easily.

The new Proton Viewer is also a good app for you to dive into the source code. It is much simpler than the Atomic Viewer and a little more straight forward than the Stacked Spin app. If you can understand this one, the others will be much easier to understand because they all have a common structure and you will see that in the code and can then focus on the differences. I'll send you a copy of the source later today.

It has been a little while since I worked on AV as I have been working on other projects. I also wanted to give this one a rest as it is on the downhill slope to version 1.0 and I want to focus more on functionality rather than presentation. However, I have a little treat for you all that I wanted to get out there now, rather than later, so I have added a new version. There may be changes in this version that I have forgotten about, since it has been some time since I looked at the code.

I have mentioned a few times since this project started that I wanted to develop a shader to show the charge emission of the protons and I have now done so. It came together rather easily and I actually spent more time putting it into AV than I did developing the shader itself. This has also shown me some of the limitations of shaders which has put a stop to some of the ideas I had to use them. I will come back to this later.

I have actually developed 2 shaders. The first shows the charge emission and the second shows the charge input. These are basically the same shader but the input one works opposite to the emission one. Every proton has an emission shader which actually belongs to the proton stack, rather than the proton itself. Each proton stack also has 2 input shaders, one for the top and one for the bottom of the stack. You can enabled/disable each type independently of the other and you can also set the charge density of each. Initially, each emission shader has 2000 photons and each intake shader has 500 photons. You may be thinking that you can't have more out than goes in, and that is true, but these are not meant to represent real values, just to show you where the charge is coming from and going to.

How do they work? Quite simply, actually. A shader has 2 parts, a vertex shader and a fragment shader. The vertex shader is executed for every vertex in the geometry of the object being rendered. The fragment shader is executed for every pixel in the 2D representation generated after the vertex shader has been called. In these shaders, the fragment shader is not very interesting as it just sets the color of the photon. All the important stuff happens in the vertex shader.

*** Edit ***

The above paragraph incorrectly states that the fragment shader is executed for every pixel but they are actually executed on every vertex, just like the vertex shader, and the specified color on a vertex is used to interpolate to the color of the next vertex so it smoothly fades from one color to the next (if that is what you want, there are other ways to use them). So in a way, the fragment shader does work on pixels but the programmer does not work that way.

*** /Edit ***

The first thing we need is some geometry for our shader to work on. A THREE.Geometry object contains an array of vectors and in this I store 1 vector per charge photon. That vector stores the direction of the photon either from or towards 0, 0, 0. Emission photons travel away from 0, 0, 0 and intake photons travel towards it.

The second thing we need is some way to determine how far long its path a particular photon is. This is accomplished by specifying another array, the same length as Geometry.vertices, that contains a number for each vertex. That number represents the start or emission time of that photon. The smaller that number is, the closer it is to 0, 0, 0 for emission and the further away it is for intake charge.

These 2 arrays are created by generating a vector per vertex that has random values between -1 and 1 for the X and Z dimensions and a random value between -0.3 and 0.3 for the Y dimension for the emission charge and basically the opposite for intake charge. The start time for each vertex is just a random value between 0 and 1.

Oh, I almost forgot, the vertex vector is normalized which means it always has a length of 1. This means that if we viewed this geometry as an object, rather than a shader, we would see a lot of points on the shell of the proton. Emission would be about the equator, +- 0.3 in Y and the intake charge is about the pole, +- 0.3ish in X and Z.

Now we can look at the shader itself to see how it uses this data to show our charge photons.

Each shader has some common properties that are shared among all vertices in that shader. The important ones are maxParticles, emissionRate, distance and elapsedTime. The intake shader also has a height property that is important. We divide the maxParticles by the emissionRate to determine a time period that each photon should live for. That is, the period is the amount of time that the photon will take to travel along its own path. That path is specified by the vertex vector, giving us the direction, and the distance. We just multiply the vector by the distance to give us the complete path (we don't actually need to create this full path vector but this is how you would do it).

Now that we have the path, we need to determine how far along that path the photon is at this point in time. This is calculated as

Code:

t = (elapsedTime - emissionTime) / period; t = t - floor(t);

. This gives us a value between 0 and 1. The second part of that code ( t = t - floor(t); ) is taking a value that could be above 1 and just chopping off the portion that is above 1.

So we now have a value that is a percentage of the path for that photon. We take this and multiply it by the distance value and then multiply the direction vector by the result to give us the position of the photon. The rest of the shader code just converts that local coordinate into world units and applies some sizing based on the distance to the camera.

There is only 1 part left to this algorithm and that is a way to change the position of each photon. At first I was going to just update the emissionTime values but this would require me to loop over every single charge photon and recalculate its value and this would have to be done in Javascript and hence, on the CPU, not the GPU where it will be fast. I have managed to avoid that and instead I only update the elapsedTime value that is passed to every vertex but it is only 1 value per shader, not per vertex. That is, for a given shader, the same elapsedTime value is passed in for each vertex on a single run. The elapsedTime value is the total number of seconds that the application has been running.

I'm not sure if any of that will make sense to you, it took me a bit of trial and error to reach it. It isn't important that you do, unless you really want to know.

The new controls to manipulate these charge fields are in 'View Settings' -> 'Proton Stack'. They are turned on by default, which I meant to reverse but forgot.

I recommend turning on transparency in 'Graphics Settings' -> 'Charge Emission' and set the opacity to something low like 0.3. Also turn off any backgrounds as they can obscure the charge a bit and make it hard to see.

There is an unintended feature with these shaders that I find quite nice. Each charge photon is rendered as a square that is always facing the camera. There are some sizing calculations performed that make it bigger or smaller depending on the distance to the camera but this is only noticeable when zoomed really close to the charge. However, when you move far away from the atom, the charge actually gets bigger in relation to the atom. As you zoom in close to the atoms protons and neutrons, etc, the charge gets smaller. I think this works really well and is kind of the opposite to the way Airman suggested they would work which was to only turn them on when you were zoomed in close to the charge field of a proton. Airman's suggestion made a lot of sense but I wanted to show the full atom with all that charge flying around as this has the most benefit for understanding. The way the charge particles get larger and smaller works really well so I will leave it as is.

Note that every proton stack will have 2 intakes, regardless of whether it is connected to another proton stack or has a neutron in that hole. I will look into that at some point but I actually find that it works well because some of the intakes are inside of the atom and kind of show the internal charge paths.

Shaders are a lot more limiting than I first realised. My previous experience with this kind of processing skipped the whole shader part and went straight into the computing unit side of it. The first time I used them was for the charge emission project Lloyd asked me to do just before I joined this forum. Then I used them to process images to create effects on them.

So I was expecting more of the same when it came to shaders but I was a bit disappointed. Shaders are very specific to the problem they are used for and they do that very well. This problem may be a limitation in THREEJS rather than shaders in general, I don't know. I may look into the underlying WebGL implementation that THREEJS is abstracting to find out.

There is only 1 problem I have at the moment and that is you can't get information out of a shader, except the data it was designed to generate (vertex and color data) and you don't even get that, the sub-system does. You don't usually need it but it is always nice to have the option.

I had been planning to use them to calculate data rather than manipulate vertices and colors. I wanted to calculate charge interactions, spin energies and their positions, anything that required a large number of particles. I can still do that but it will have to be in a different language and I have come to like being able to present stuff in a browser.

But they have served me well in AV. I am really happy with the charge shaders and they were relatively easy to create mainly because of the restricted environment they are used in. So I don't want to complain too much but I had mentioned it in my last post and now I have it off my chest.

I have rewritten my periodic table page such that it now links to the Atomic Model Editor for the elements we have models for. Clicking on an element will open the editor with that atom already loaded, the background set to 'None' and element titles (metadata) turned off.

To accomplish this, I added some javascript to the HTML page that looks at the parameters specified on the URL. You can currently specify the following parameters:

 element=<atomic-number>
 background=<preset-name>
 position=<x,y,z>
 metadata=<true|false>

Example URL:

 http://.../AtomicWebViewer/AtomicViewer.html?element=8&background=None&position=0,0,30&metadata=false

The position will move the camera to that location but it will always look at 0, 0, 0 so you don't need to worry about it looking away from your element.

I also want a way to specify the element data model (called a Periodic Table in AV nomenclature, which collides with this discussion about periodic tables so I will call it an element data model to separate the 2). This would allow you to load elements from any source we have available in AV. However, I need to figure out a way to do that as URL parameters with the same name get lumped together and you can lose the order they were specified in.

I want to be able to load multiple elements from the URL so that we could setup comparison pages. It will probably end up being something like elements=Nevyn's Periodic Table[8],Cr6's Periodic Table[8],Airman's Periodic Table[8]. I don't like the fact that the model name would need to be exact. I might look into using a regular expression so that we can just specify part of the model name such as: elements=Nevyn[8],Cr6[8],Airman[8]. This could lead to name collisions, for example, what if you specified: elements=Table[8]. Which model would it use since all of them will match that name expression? I would probably just use them all which would provide a shorthand way of specifying multiple models. So elements=Periodic Table[8] would load Oxygen from Nevyn's Periodic Table and Cr6's Periodic Table but not the Test Models (using the currently available data models). I am open to suggestions though.

While I was editing this periodic table page, I made a quick attempt to make it look a bit more modern. This has caused some things to not align nicely, the way they use to. I will fix this at some point. It isn't too bad, so is not too important at this time but it does bug me when I look at it.

Thanks goes to Cr6 for giving me this idea (in a round-a-bout way). I think it works really well and saves me from having to find a way to create a heap of videos and the need to store them on a server (they add up very quickly). It is also a first step in creating a site, rather than just a page. I like the idea of different parts using each other to provide a larger picture of Miles work. Most of all, I think it provides a much better experience for the user. Videos are great but an interactive app is much better.

And a belated thanks to Airman for discussing shaders which got me thinking about them a bit more seriously and now we have all that glorious charge flying around our atoms. I wouldn't have created any of this without you guys and I want you to know how much I appreciate it. I have learnt so much from this (which will actually help in my professional life as well) and I have really enjoyed it.

Good news. I found a way to use Compute Units instead of Shaders.

THREEJS is built on top of WebGL (Web Graphics Language) but there is another similar project called WebCL (Web Computing Language) which is a Javascript version of OpenCL which is what I have programmed on the GPU with in my other work. I used a Java binding of OpenCL before and this is very similar, almost exactly the same, actually.

I don't know how many browsers have a working version of WebCL, but it has been around for a while so it should be fairly stable by now in the major browsers.

Compute Unites (CU) are a lot more low-level than shaders and the developer is responsible for everything. There is no known working environment like there is in shaders so you must provide all context.

I don't know how well THREEJS will handle me using WebCL while it is also using it, but it should be able to deal with it. If these APIs are built well, and I have no reason to believe they aren't, then THREEJS will not even know that I am also using the GPU and they will just get executed side-by-side.

I don't have any immediate plans to use these CU's but I feel much better knowing that I can when I need to.

I have added an initial implementation of through-charge as a particle shader. This is implemented as a group of particles starting from anywhere within a given circle and they all move in a straight line in a given direction and each particle has its own offset (called emission time previously). This forms a tube of charge. Each proton stack has 2 through-charge streams, one at the top that goes down into the stack and another at the bottom that goes up into it. Therefore we have 2 streams occupying the same volume of space but moving in opposite directions. Each stream starts within the outer proton but extends beyond the proton at the other end of the stack so the parts you can see that go past the last proton is only in 1 direction representing the emission of that through-charge (this happened by accident but I like it). When looking at a single proton, it looks like the intake charge is being made coherent by the proton and then emerges on the other side as a more linear stream. A little laser, if you will.

I have also fixed up the math inside these shaders. My first explanation of the implementation was a bit erratic as I tend to let my math evolve. Therefore some of the variable names do not end up reflecting what that variable is being used for. When I have it all working, I then go back and clean it up, rename things, etc. Now, there is no emission rate or period calculation as I am basing it on speed and distance now (which I had intended to do in the beginning but it diverted a bit). This has allowed me to specify a common speed for all charge which you can manipulate. Note that the through charge may look like it is going faster than the other charge but this is an illusion because you are seeing 2 streams moving opposite to each other so the relative speed makes it look faster.

The through charge only moves down the central column of a proton stack. I want to use the structure to determine cross-streams which is through charge from adjacent stacks that flows across another proton stack (in between the proton emission streams). This is the first step in working out relationships between stacks and showing that somehow. This will also lead into determining when intake and through charge are being blocked, by a neutron, for example.

I have found that my work laptop does not handle all these shaders as well as my own computer, but even my phone will show them reasonably well. If you are having trouble with frame rate when using these shaders, please let me know. I still have to add some code that will adjust the number of particles based on the performance settings and it will help to have an idea of the limits I need to impose. As I do all of my development on my home PC, which has a good graphics card, I often don't have performance problems so I may implement things that don't work so well for others. This is why I test it on my work laptop every now and again so I can see how a system without a graphics card (just on-board graphics) will work but even my work laptop is a decent system in all other areas.

Nevyn, These shaders work really well.

1) I'm sure you noticed, the Through charge abrupt cylindrical can-top cut-off boundary around r from the proton is distracting. The impression of a laser is apt, but any more focus makes the cut-off stronger. Of course it's not a problem where the cut-off meets the edge of an adjacent proton emission disk. Is there an option that would allow you to vary the shader end lengths slightly, or taper the shaders off over a small additional distance and/or maybe end on a flame-like cone surface? You know what I mean.

2) Add Through shaders to the Neutrons! Isn't the neutron through charge 1.61x the proton's? I hope you don't mind me stating the obvious.

3) Emission shaders. Try beefing up the emission shader fields and deleting the disks to see how it looks. How big is the memory load to replace the disk?    

My new mouse, and my wife, thank you.

LongtimeAirman wrote:Nevyn, These shaders work really well.

1) I'm sure you noticed, the Through charge abrupt cylindrical can-top cut-off boundary around r from the proton is distracting. The impression of a laser is apt, but any more focus makes the cut-off stronger. Of course it's not a problem where the cut-off meets the edge of an adjacent proton emission disk. Is there an option that would allow you to vary the shader end lengths slightly, or taper the shaders off over a small additional distance and/or maybe end on a flame-like cone surface? You know what I mean.

Yeah, it is a bit abrupt. I will try to make it go more transparent the closer it is to the end and see how that looks. I might even be able to adjust the transparency such that photons near the outside of the tube are more transparent than those closer to the inside. This should make a flame-like cone, as you mention.

LongtimeAirman wrote:
2) Add Through shaders to the Neutrons! Isn't the neutron through charge 1.61x the proton's? I hope you don't mind me stating the obvious.

Yeah, I thought about that too. Not sure if it will get a bit crowded but I will see how it goes.

LongtimeAirman wrote:
3) Emission shaders. Try beefing up the emission shader fields and deleting the disks to see how it looks. How big is the memory load to replace the disk?    

You can do that yourself already. Go into the 'Graphics Settings' then 'Charge Emission' and turn on 'Transparency' and set the 'Opacity' to 0 or even 0.3 looks good as it still gives you that slight coloring. I will make it be able to completely turn off the charge discs as using the transparency option has a performance penalty. You shouldn't get worse performance for seeing less.

You can also adjust the particle density for each type in 'View Settings' -> 'Proton Stack'. It is entirely feasible to only use the charge particles. This is actually much closer to what it would really look like.

LongtimeAirman wrote:
My new mouse, and my wife, thank you.

They are very welcome.

Yes, I did max the emission field. Talk about needing shades!

I have updated the through-charge shader to apply some transparency near the end of the stream. It is not as smooth as I want but it is a bit better than before.

Oops, I missed the transparent choice before. That's better. I see Neutrons butted against protons already channel charge.

Smoother? I would say "less discrete". The disks are supposed to represent proton emission, and now you are doing a better job of it. One can easily see that the entire "structure" is not simply due to the configuration of protons, neutrons (and electrons), but to the compact formation of charge field streams that configuration creates. As well it should.

"Too crowded", You can always turn off the shader particles, but I like it. Like fuzzy dice hanging from the windshield of my screen.

I have updated the through-charge shader again so that it works on a set distance from the end of the tube. This allows all proton stacks to have the same fading section distance, regardless of the number of protons in the stack. Previously, it was just a percentage of the total distance. I have also adjusted the fading algorithm to provide a sharper fade cone.

Airman, the neutrons do not have any effects showing them channeling charge and when I looked at it I saw that part of the neutron is actually inside of the protons charge field which would cover the charge effect. I don't want to move the protons apart any further as I think they look good where they are. I will still give it a go just to see how it looks, but I am thinking it won't work so well. I will also move the protons apart a bit in case it doesn't look as bad as I think it will.

I decided to give it a go before I posted this but I will leave that section in as it gives some insight into my thought processes. The protons in a stack have been moved apart such that there is now 1 proton diameter between them, it was previously about 20%. It doesn't look too bad but it does make all atoms taller or wider, which ever way the stacks are pointing. It looks weird to me but maybe I am just used to the way it was. It doesn't look so bad with a carbon atom, for example, but an oxygen atom looks really tall. I could make the charge fields a bit wider to compensate so that they end up relatively the same.

I have added 2 new controls that allow you to turn the charge disc and particles on/off. The 'Show particles' control enables/disables all charge particles but you can still turn each type off individually. I have also left both charge discs and particles turned on by default, eventually I will turn the particles off by default but I want them on for now since that is what we are all looking at (or at least I am).

I emailed Miles yesterday and sent him a link to these applications to get his feedback and to see if he wanted a version for his own website. If he wants it, I plan to remove all editing code and just make it a viewer. I will still keep working on it as an editor, but I don't think Miles needs that for his site and I think it will eventually require a back-end server which puts restrictions on hosting that I don't want to impose on Miles. I will setup a site of my own for editing purposes and hopefully Miles will link to it from his site.

I have looked into hosting arrangements but have not chosen a particular set of technologies that I may need in the future which makes it difficult to select a specific host. I am looking at 2 different kinds of hosts. The first is the normal web hosting setup where you usually have access to a web server running PHP and a back-end database, usually MySQL. The other hosting type is called Linode and basically gives you a Linux Virtual Machine that I can do whatever I want with. This is my preferred option since it gives me complete control over what I want to use. However, it also gives me complete responsibility to keep it running, secure it, etc. Public sites get attacked all the time and it can be a real time waster dealing with it.

The costs of the basic hosting arrangement is about US$8 a month. I can get it a bit cheaper at the moment as they have a special on and it is about $5 a month but that will eventually run out and it will go back up to the higher amount. There are also some hidden costs (that I can choose) for extra security, auto backups, etc, so it adds up in the end. The Linode cost is US$10 a month, no specials, and while this is a bit more expensive, it does provide me with much more power (but with great power comes great responsibility) and if I want more security, then I just implement it myself, same with backups, etc.

This has led me to think about monetizing the site somehow. I don't like adds on websites, although some sites do it better than others. I was thinking more of a subscription service where I charge $1 a month for access. I don't want to charge too much, just enough to cover hosting costs and a little for my time and effort would be nice, but I don't expect it to be an income. I might offer a free version that is just a viewer and users pay for editing functionality. Maybe even have a tiered system where for a little bit more, you get to store stuff in my database, a little bit more and you get some free steak knifes, but wait, there's more ... (sorry, started channeling a TV shopping show presenter).

The problem is I have no idea of the audience. How many people will be interested in using it? Can I provide enough functionality to make it worth paying for? Is it something that people would use over a long time or just play with it for a while and then forget about it? I guess I won't know until I do it.

Nevyn, Good Luck! Quick, the Neutron's Through Particles do not rotate with the rotation enabled Neutron.

You're too quick for me, Airman. I just updated that!

Heard back from Miles, but just a thanks and he will get back to me once he has a play with it.

I have made another update, this time to show charge that flows across a proton stack as a result of through charge from an adjacent stack. I'm not sure I have all of the motions correct yet, but it is pretty close. With this enabled, you can completely turn off the charge discs and still see the atom.

The graphics performance setting now changes the types of charge particles that are shown. The default setting will only show charge emission. Higher settings will enable intake and through charge. You can always go to the setting yourself and turn them on/off so you can choose a low graphics setting and then turn on the particles to your liking. For the best performance, assuming your graphics system can handle shaders, it is probably best to use the minimum graphics setting and then turn off the charge discs and turn on all charge particles. This will move nearly all processing to the graphics card.

Nevyn wrote:I have looked into hosting arrangements but have not chosen a particular set of technologies that I may need in the future which makes it difficult to select a specific host. I am looking at 2 different kinds of hosts. The first is the normal web hosting setup where you usually have access to a web server running PHP and a back-end database, usually MySQL. The other hosting type is called Linode and basically gives you a Linux Virtual Machine that I can do whatever I want with. This is my preferred option since it gives me complete control over what I want to use. However, it also gives me complete responsibility to keep it running, secure it, etc. Public sites get attacked all the time and it can be a real time waster dealing with it.

The costs of the basic hosting arrangement is about US$8 a month. I can get it a bit cheaper at the moment as they have a special on and it is about $5 a month but that will eventually run out and it will go back up to the higher amount. There are also some hidden costs (that I can choose) for extra security, auto backups, etc, so it adds up in the end. The Linode cost is US$10 a month, no specials, and while this is a bit more expensive, it does provide me with much more power (but with great power comes great responsibility) and if I want more security, then I just implement it myself, same with backups, etc.

That's a great goal Nevyn. I think the Linode long-term might be the better and most flexible choice for web-server/mysql database. But that would require more work for upkeeping the server and preventing hacks. By all means look at getting a minimal income stream to at least upkeep the site.

I've been looking at Apache Drill or Apache Spark lately. They could work with a php/MongoDB combo -- they seem to be very json friendly. Might be a lot of configuration work over a simpler php/mysql start when including the on-going maintenance/security.

https://www.mongodb.org/downloads
https://github.com/mongodb/mongo-hadoop/wiki/Spark-Usage
https://drill.apache.org/
https://spark.apache.org/

Hmmm, non-relational databases? Didn't we throw those out in the 80's?

I am so used to working in relational databases I don't see how to use a non-relational one effectively. I've only spent about 10 minutes looking at it but at the moment I can't determine exactly what they mean by non-relational. Does it just mean that the database does not store any relationship information but you can still link things together in your SQL (like inner joins, etc)? Can a "table" contain child records directly instead of linking to another table? I'll have to look into it a bit deeper. Thanks for the links and getting me thinking in a new direction.

I don't have any ties to PHP. In fact, I've never built a site with it. I have fixed bugs in someone else's PHP code but there's a lot I don't understand with it (although it's just a matter of learning their syntax and function names, etc). My preference would be to use Java as my server language which would run inside Apache Tomcat which would be hidden behind an Apache Web Server (more secure and faster for basic file transfers). I would still do most of the coding in Javascript and only use the back-end server where it is absolutely needed. I was only thinking PHP/MySQL because nearly all hosting environments have those already (but that also makes it a more likely target to hack).

I do have to get things moving though as Miles has offered to put a link on his site to the AV app. I am 90% certain that I will go with Linode at this point. It may cause me some pain but at least I can figure out what it happening and apply fixes, etc. While a more standard web hosting system does provide some security, it is also a little sandbox where you don't always have access to what you may need to fix a problem. They are designed to make is easy for (almost) non-technical people to get up and running.

So my plan of attack is:

1) Clean up the interface. Dialogs, selecting elements, etc.
2) Find a way to separate viewing from editing such that they share code, not copy it.
3) Restructure the settings into a more coherent hierarchy.
4) Write some help pages within the app and some informational pages along side of it.
5) Apply code licensing. Not sure about this now, since it is moving away from an open source model.
6) Buy hosting environment.
7) Setup back-end services on host.
8) Secure services.
9) Setup backup regime.
10) Setup site monitoring system. Checks for dead processes, file changes, etc.
11) Buy domain name and link to host.
12) Research e-commerce frameworks, select one and set it up.

It will probably take me a few months to get all of this done so I am thinking of a new years launch.

Now, if I can just stop playing the new Metal Gear Solid game so much, I might find some time for all of this!

I have updated AV to version 0.7 which is basically some bug fixes in the dialogs to select elements and define JSON objects and some lighting settings. The directional and spot lights still do not work properly and I think I will drop these as they are not really needed and were only in there because I wanted to play with them in the beginning of development of this app. I have also changed the navigation system back to the original Orbital type as this works better for 1 or 2 models and my alternate version had some issues that annoyed me every now and again.

I am trying to clean up the code so that I can split it into a Viewer and an Editor while also trying to figure out how I can use a common code base for both of them. I know how I can do this easily with a back-end server but not so easy without one. I think I really need to bite the bullet and just use one. It will open up a few possibilities that have sat in the back of my mind for a while. Might be a good opportunity to learn a bit more PHP. I keep thinking of Java technologies that I could use but something still tells me not to tie myself into such a hosting arrangement, even though I am nearly certain that I will go with a Linode VM.

I am a little over half way through Metal Gear Solid V and am really enjoying it, hang on, that's not why I'm here...

I haven't been putting much time into this project over the last few weeks, which I feel a bit guilty about since I had just committed myself to getting all of this set up, but I have now made some progress on the hosting arrangement. Last night, I bought a Linode VM, setup a Linux distribution, installed a Web Server, secured it as far as I want to at the moment and installed a copy of my site. It all came together very easily. Linode provides many great tutorials on how to get started and I only had one problem during the entire setup. I suspect that problem was a result of the Linux distro I chose as I went for the more up-to-date version rather than the recommended one. The VM is currently configured as I want it, but I don't think it will survive a reboot because of that error. I will try to track down and fix the problem but I may need to start all over again with the older Linux distro. Unix administration is not my forte, although I have done bits and pieces over the years.

So my updated plan of attack is:

1) Clean up the interface. Dialogs, selecting elements, etc.
   I have done some, but there is more to do.
2) Find a way to separate viewing from editing such that they share code, not copy it.
   I have PHP now so I think I will try to use that to bring all of the pieces together based on whether
   the user is viewing or editing. I could also setup a database and have formal users/groups that
   restrict access. Needs some thought on what is feasible in a small time frame.
3) Restructure the settings into a more coherent hierarchy.
4) Write some help pages within the app and some informational pages along side of it.
5) Apply code licensing.
   I have had a quick look into this but nothing substantial at the moment.
6) Buy hosting environment.
   Done.
7) Setup back-end services on host.
   Done.
8) Secure services.
   Done.
9) Setup backup regime.
   I had a look at my options but need a formal backup regime.
10) Setup site monitoring system. Checks for dead processes, file changes, etc.
11) Buy domain name and link to host.
   I have researched domain name registrars but have not decided on one yet.
   This is tricky because there are some real dodgy operators out there.
12) Research e-commerce frameworks, select one and set it up.
   I will probably not worry about this for now. Maybe later when I have something worth paying for.

So, in spite of not putting much effort into this lately, everything is coming along nicely enough. I really did need a break from it. The first 50% of a project is usually the easiest as you have that drive based on all of your ideas. The next 30% goes ok because of the momentum you build during the first half. But that last 20% is a killer. A lot of personal projects get left at this stage. Even in the professional world, that last bit requires so much work and you don't have the option to just walk away. I'm trying to keep that mind-set with this project because I think it deserves a professional attitude. I didn't intend for it to go this far but now that it is getting close, I really want to push it over the finish line and let it out into the world. For better or worse!

I now have my very own domain name! It took some thought to come up with one (that was also available) as I don't really know what this site is going to end up as. I settled on a more personal touch as I can always buy more domains later for different purposes and point them all to the same system (but completely separate in the web server).

I'm really struggling with an identity for the site. Right now, it is for these applications, but I am not limited to that or to Miles work. I feel like everything has opened up before me and I just don't know where to go. But I am a believer in an evolutionary approach to these things, so time will tell. I do feel that I need more pages around these apps and certainly more pages that describe the apps and how to use them. However, it is the front page that worries me. It really needs to set the scene.

I'm not used to creating this side of a system, usually I am creating the server side components with a bit of HTML/Javascript as an interface. It is good to be learning though, and I do like to be creative.

It's been great setting up the server. I expected a lot of it to be painful, finding info on the web that doesn't quite work, dependency conflicts, security holes, but it has been very easy with my compliments going to both the Linux OS and to Linode for their tutorials. Linux really has stepped up and fixed issues that I have had with it in the past and I really can't say enough good things about Linode. Great platform for anyone with some administration skills or the desire to learn them. Only slightly more expensive than other hosting sites but you get all the power that others don't provide.

So, without further ado, I present to you: Nevyn's Lab.

Updated plan of attack is:

1) Clean up the interface. Dialogs, selecting elements, etc.
  I have done some, but there is more to do.
2) Find a way to separate viewing from editing such that they share code, not copy it.
  I have PHP now so I think I will try to use that to bring all of the pieces together based on whether
  the user is viewing or editing. I could also setup a database and have formal users/groups that
  restrict access. Needs some thought on what is feasible in a small time frame.
3) Restructure the settings into a more coherent hierarchy.
4) Write some help pages within the app and some informational pages along side of it.
5) Apply code licensing.
  I have had a quick look into this but nothing substantial at the moment.
6) Buy hosting environment.
  Done.
7) Setup back-end services on host.
  Done.
8) Secure services.
  Done.
9) Setup backup regime.
  I had a look at my options but need a formal backup regime.
10) Setup site monitoring system. Checks for dead processes, file changes, etc.
  I have setup system monitoring, not site content monitoring.
11) Buy domain name and link to host.
  Done.

Nevyn, I’m not qualified to offer you any feedback in your server development, but it sounds like you’ve got the technical side nailed. Of course, the biggest costs are time and energy. You hinted at other interests; anything to do with World Domination? Maybe (Nevyn’s) Nefarious Laboratory.  I can help with a share and modest efforts but I’m glad I’m not here for the money.

I went looking for the Lab in the usual spot, but of course, it isn’t there yet. So I played with the… Periodic Table (PT), and AV0.7.

1)  PT. It’s really convenient to be able to go back and forth from the Periodic Table to the Atomic Model Editor (AV0.7). I can now easily dial through rows or columns and clearly understand the organization of the table, which, I'm sure you'll agree, has never been possible before.

2) PT, AV0.7. Control Settings are reset each time the Table accesses it. Any chance those settings, if changed, could remain constant?

3) AV0.7 I see that you have divided your view space, top and bottom, left and right, with the Hydrogen proton at the center. This center never changes - except to translate to the midpoint between the carousel alpha protons in the majority of elements - however the atomic structure grows, mostly up. Or with meta data on top. Please consider re-centering the vertical camera space as necessary.

4) You indicated the need for help pages or additional information. I second that. It could be meta data too.

5) PT. Currently, you can display the element’s details when you hover over the element, or hold shift down to keep the detail from changing. I think you can improve the page by displaying a reduced image of the element along with the details.

(5b) Alternatively, if you’re really in with threejs, why not use their famous floating transparent periodic table complete with your models?)

Spaater

Oh. http://www.nevyns-lab.com/

LongtimeAirman wrote:
2) PT, AV0.7. Control Settings are reset each time the Table accesses it. Any chance those settings, if changed, could remain constant?

Yeah, that is a good suggestion. Now that I have PHP I can look into these types of things. Currently, it is stateless, so there is no way to remember the settings. It could probably be done through cookies but I already plan on having session code in the PHP so I will do it all there.

LongtimeAirman wrote:
3) AV0.7 I see that you have divided your view space, top and bottom, left and right, with the Hydrogen proton at the center. This center never changes - except to translate to the midpoint between the carousel alpha protons in the majority of elements - however the atomic structure grows, mostly up. Or with meta data on top. Please consider re-centering the vertical camera space as necessary.

I'm not sure what you mean here. I assume it is a result of the change in navigation controls which now lock on to the center, unless moved with a right-click+drag.

You also might be referring to how zoomed in the camera is when you select a large element from the PT page. Yes, these need adjusting and it is entirely possible now, I just haven't gotten around to it.

Can you try to describe the problem again for me? I just went to the PT page and selected Platinum and it was very close to the atom so I think this is what you are referring to. I will fix it.

LongtimeAirman wrote:
5) PT. Currently, you can display the element’s details when you hover over the element, or hold shift down to keep the detail from changing. I think you can improve the page by displaying a reduced image of the element along with the details.

Another good suggestion. I need a way to generate the images which, again, now that I have PHP I can do this more easily. You've given me the idea to generate a slide show of images of all the elements in a table.

LongtimeAirman wrote:
(5b) Alternatively, if you’re really in with threejs, why not use their famous floating transparent periodic table complete with your models?)

This is an even better idea and I might be able to find a way to incorporate both the periodic table and the selected element into the same scene. It might be a bit tricky on screen space but it is worth a try.

I've been thinking of having as much of my site in Three.JS as possible. Long term goal, but if I can do it right, will work out well, I think. The onus then becomes creating the artwork for 3D environments which is not really my forte. I'll keep the idea in the back of my mind and see if anything pans out.

Sorry not to comment more frequently Nevyn and LTAM.  

Looking over things, it is really very impressive what you have done Nevyn.

I too, like LTAM, find this a great tool to see the structures by flipping the Atomic editor and Periodic table.

The PHP looks like a great option to try.

As for MongoDB, it allows JSON rendering to "tables" in a virtual way. Basically, a JSON atom could be stored in single line of text that can be auto-rendered into a table format from just a single database entry.  I was thinking down the road when Atom Bonding Mathis style is on the horizon, it could allow a full "molecule" to be rendered from a single database entry rather than combining tables with joins (though still available).  Don't want to sidetrack too much on the non-table entities. It might provide fast flexibility in JSON when needed rather than adjusting table structures with alters and such.  Just a thought.

This image relates the story:

http://drill.apache.org

The site looks very nice and presentable.

I spent some time back in the code for AV last night. I updated the PT page so that it sets the position of the camera better when it goes into AV. It could probably still use some fine adjustment, but it is pretty close. This is working on the new site now.

I have also added in PHP so that I can do all sorts of things I couldn't before, but I have not updated the server with these updates yet. PHP is a server-side scripting language. It allows me to put logic into the existing HTML/Javascript source code to control what parts of it get served to the user or maybe alter those parts based on settings in a database, etc. It does plenty of other things but that is generally what I will be using it for in this project.

All previous versions were just straight HTML/Javascript so the app was completely client-side. Once the files were served to the browser, there was no server interaction at all. Now, I am using PHP and a database (currently just for user/role information) to send back code for either a Viewer or an Editor. It is all in the same source files, but PHP allows me to choose which parts I want to serve for a given request. If the user has the 'editor' role, then they will get extra bits of code that implements that functionality. There is no way to actually login yet, so the user is selected by me in the source code, but I will get to that eventually. I don't actually need an editor at the moment so it is really just for my own testing to make sure the code works as both a viewer and an editor.

Right now, I just want to get a viewer up and running so that I can give a link to Miles to publish. This will be a very cut-down version of what you guys have seen so far. I am thinking of removing all of the Graphics Settings and only leaving the Performance selector. Any settings related to the actual parts of the element, such as rotating neutrons/electrons, will remain, but moved somewhere else in the menu structure. I have removed backgrounds and element positioning since these aren't needed and I may have some licencing restrictions on some of the textures I have used. They were all free ones, but often you need to acknowledge the author on your site somewhere and I don't have that information at the moment. It will take a bit of a search to find it.

The other thing I have done with PHP is to save the performance settings so that when you come back to the page it will set it again for you. This is stored as session data on the server and will expire after a certain amount of time. Usually this is set to 30 minutes, I haven't looked to see what my value is, and I think that it expires 30 minutes after it was last used, not 30 minutes since you created it. In the future, these will be saved in the database so that they work all of the time if you are logged in. Might be one of those nice features you have to pay for. I don't wan't to hold back functionality to force people to pay for the system but I think this is a nice middle ground.

I am still working on this. I have the performance setting working but I also wanted to add in whether it shows the metadata or not (atom name, symbol, number, etc). I am thinking of changing how it works so that it can save all of the settings but I think I will have to re-organise some of the settings to make this effective. Basically, there is data in the settings object that are actually values used by the settings rather than actually being settings and I need to move these out so that they are not saved with the settings which would be a waste of space and network IO. This is data like links to background textures, positioning algorithms, etc.

I find myself thinking about things like network, cpu and memory usage on my server. I usually don't have to worry too much about these things because my clients can afford nice powerful systems. Ask any system administrator and they will tell you the developer solution to performance problems is always 'give it more hardware' while the admin is thinking 'make your app work more efficiently'. Now I find myself being both of these roles and stuck somewhere in the middle. I can give it more hardware, but it will cost me more per month. Oh, yeah, I'm the treasurer too.

So I have to really think about what I am going to implement and how that affects the system. It might work fine with 100 users but not with 1000 while an alternative implementation might work better at that scale. I have to think about these things now because I will be charged extra if my server uses more resources than I am allowed, whether that be download quota, cpu usage or memory. I don't expect too much load, but there could be a sudden influx of users when Miles publishes a link to it. I am actually really interested to see those numbers so I better find a way to record them.

A quick search later and I have a solution for that, too.

Cr6 wrote:
As for MongoDB, it allows JSON rendering to "tables" in a virtual way. Basically, a JSON atom could be stored in single line of text that can be auto-rendered into a table format from just a single database entry.  I was thinking down the road when Atom Bonding Mathis style is on the horizon, it could allow a full "molecule" to be rendered from a single database entry rather than combining tables with joins (though still available).  Don't want to sidetrack to much on the non-table entities. It might provide fast flexibility in JSON when needed rather than adjusting table structures with alters and such.  Just a thought.

I understand the attraction of these flexible data structures, reducing the need to change rigid database schemas. My worry is that query performance will suffer because of it. Also, the SQL needed to query these sorts of tables can become horrendous. I was thinking of a schema that would facilitate nice, or at least effective, queries but maybe I shouldn't worry about that. Horrible SQL can always be hidden behind views, stored procedures (I assume procedures are available in these databases) or in the application code (but preferably not). And maybe I was creating horrible SQL by trying to split it into a few tables in order to reduce data redundancy. I was dealing with quite complex data (our element JSON structure) so I will assume that I am at fault, for now.

I got the persistent metadata settings working last night and updated the site which is now at version 0.8. I also spent some time minifying and collating the Javascript files in order to reduce network IO and loading time. It also obfuscates the code, which makes it difficult to read and figure out what is going on. That wasn't really my aim but I don't mind either.

Sorry I missed out on your progress till now, but maybe I can catch up a little. Looks interesting.

Hey Lloyd, welcome back! We were getting a bit worried about you for a while there.

We've made some great progress lately. It seemed a real shame to me that you weren't here for it because you were the real driver for this kind of stuff. Trying to get us organised and productive. Glad your back and I am looking forward to hearing your input. There's plenty for you to look over and absorb, most of my apps are on my new website (www.nevyns-lab.com) except the Solar System app so if you want a link to that, just give me a PM and I will send you the URL. I didn't get very far with that one which is why I didn't publish it on my new site.

I just noticed that this is your first post. What happened to your old account?