Atomic Model Editor

by **Nevyn** Mon Aug 03, 2015 10:53 pm

I have created this topic to contain everything about the Atomic Model Editor. Questions, ideas, complaints. Whatever you need to say about it, this is the place.

What is the Atomic Model Editor?

It is a web based application to view and edit nuclear models as described by Miles. It is written in HTML and Javascript but may extend into some server side code to provide extended functionality if I can't do it in the browser. Server side code will likely be PHP and possibly a MySQL database, just to keep it simple and easy to host since most hosting environments provide these tools. If I had the choice I would use Java Servlets and a Postgres database but that would make it expensive to host anywhere that I don't have complete control over.

The Atomic Model Editor was created as a result of some discussions about Cr6's periodic table data. You can read through it here. I designed a JSON Element format that we could use as an intermediate data storage structure. That is, a way for us all to share our data in a common format so that different tools could be written to use it. I immediately went about adding it to my Atomic Viewer (desktop application for 3D nuclear modelling). That went well but it got me thinking that I should rewrite that application based on this new structure.

I had a look through the code and it was a big job to change it and I thought it better to just start again. Since I had no ties to any existing code, I could rethink my platform and decided on a Javascript 3D API called Three.js. This was a decision made for other people, rather than myself. My other 3D applications are all written in Java and I would prefer to keep doing so as it gives my a lot more power, flexibility and stability. However, getting it running on other systems is a bit of a pain because it needs specific libraries for the host hardware. By using HTML And Javascript, I could let the browser take care of that problem for me. I am happy with the capabilities of the Three.js library but it is a bit unstable sometimes (that's not really Three.js but the underlying WebGL implementation in the browser).

What does it do?

The first version of development focuses on establishing a stable environment for viewing atomic models and provides some basic, text based, data entry and editing tools. You can copy/paste JSON Element descriptions into the app to view them and you can decompose the current models back into JSON Element format to save. I will look into a file saving mechanism soon but this is not an easy thing to do in a browser because of security concerns. If it is not possible to do in the browser then I will need to implement some server side code which just bounces the content to be saved back to the browser which will then prompt the user for a file to store it in. In conjunction with the file saving ability will be an image export mechanism so that you can save an image of the current content. You could do this now by taking a screenshot but I think a more formal mechanism is warranted.

Version 2 will focus on editing the models in the graphical environment. You will be able to select an atom, change its properties, move it, rotate it, show charge strengths, etc. I would like to look into the ability to grow elements. That is, given a starting point, which could just be a proton, determine how we could add more protons to form new configurations. This will be a rule based engine where we define Miles nuclear building rules and the system uses them to find possible elements. This could grow into a project of its own as it is a big job.

The third version will focus on molecules. I want the system to calculate as much information as possible and for it to take care of little tasks like moving protons within a model when it bonds to another element. It should be able to calculate the possible bonding points between 2 atoms and let the user select which ones to use for bonding, then it will combine them into one entity. I have a vague idea of being able to insert a few atoms and/or molecules into the scene and then let the system determine what molecules could be made from them.

What data does it handle?

Currently, it is completely based on the JSON Element format. Here is an example of the current structure:

{
"name": ""
,"symbol": ""
,"atomicNumber": N
,"levels":
{
"core":
{
"protons": N
,"neutrons": N
,"electrons": N
}
,"pillar":
{
"north":
{
"protons": N
,"neutrons": N
,"electrons": N
,"attach1": {
"protons": N
,"neutrons": N
,"electrons": N
}
,"attach2": {
"protons": N
,"neutrons": N
,"electrons": N
}
}
,"south":
{
"protons": N
,"neutrons": N
,"electrons": N
,"attach1": {
"protons": N
,"neutrons": N
,"electrons": N
}
,"attach2": {
"protons": N
,"neutrons": N
,"electrons": N
}
}
}
,"cap":
{
"north":
{
"protons": N
,"neutrons": N
,"electrons": N
}
,"south":
{
"protons": N
,"neutrons": N
,"electrons": N
}
}
,"carousel":
{
"east":
{
"protons": N
,"neutrons": N
,"electrons": N
}
,"west":
{
"protons": N
,"neutrons": N
,"electrons": N
}
,"front":
{
"protons": N
,"neutrons": N
,"electrons": N
}
,"back":
{
"protons": N
,"neutrons": N
,"electrons": N
}
}
,"hook":
{
"north":
{
"protons": N
,"neutrons": N
,"electrons": N
}
,"south":
{
"protons": N
,"neutrons": N
,"electrons": N
}
,"east":
{
"protons": N
,"neutrons": N
,"electrons": N
}
,"west":
{
"protons": N
,"neutrons": N
,"electrons": N
}
,"front":
{
"protons": N
,"neutrons": N
,"electrons": N
}
,"back":
{
"protons": N
,"neutrons": N
,"electrons": N
}
}
}
}

I don't foresee much reason to handle other data formats since none of them know anything about Miles nuclear models. However, I am open to ideas if you have any. I will introduce a JSON Molecule format at some point but I don't need it just yet.

It currently supports the JSON Element format in two ways. The interface allows you to enter the JSON Element definition directly, either as a single entity or as an array of entities, and they will be inserted into the current scene. The other way uses a Javascript file that declares a global variable that is an array of JSON Elements. This is presented to the user as a list of buttons where clicking on the button will insert that element into the scene. It makes use of the 'period' property on an element, if it has one, to create a tab per period for easier selection of elements but all elements are available on the first tab. This uses the output of a converter I wrote to extract Cr6's element data (in Excel, exported into CSV and then into JSON) into the JSON Element format so all of the current element definitions are from that Excel file. I have noticed some elements that are wrong and some that are different to how I have modeled them but a lot of it is good data. As I am focused on developing the app, I have not had time to convert my own models into the JSON Element format (and I don't think there is a way to do it through code so I will need to manually build each one but the new JSON Element format is much easier to work with).

Where can I get it?

There are two ways to apply this question. "Where can I use it?" and "Where can I get the source code?" With respect to the first, I have it on the web on my personal web space (through my ISP) but I don't like sharing that URL in a public forum so I am trying to find other options.

I am also thinking about how to share the code for this project. At the moment, GitHub is a good choice or I might use BitBucket. I'm not sure how much need there is for sharing the source so I haven't spent much time thinking about it. If I solve the hosting issue, then I can just put a zipped copy of the source tree on there.

For now, send me a PM if you want a link to either the web viewer or the source code.

by **Nevyn** Mon Aug 03, 2015 10:56 pm

Here is a screenshot of the current interface. It shows some of the settings that can be altered and a couple of models.

by **Nevyn** Sat Aug 08, 2015 4:02 am

Version 0.4 has slowly crept out of the womb and given a glorious cry of life. Sporting a sexy new look for every element in the catalog.

It has come, in our hour of need, to answer some of the great questions of life. For instance, is there any oxygen on the moon? Well, let's have a look:

I believe there may be trace amounts there.

We also find some interesting chemistry in the fiery heart of the Earth. Could the noble Neon, wearing a lovely blue gown this evening, survive under such pressure?

Now, the most burning question mankind has dared to ask. Some may not like me talking so openly about it, however, I must take the risk and put it right out there for all to see. I must ask you all to think back to a time when you've asked yourself just what would a atom look like on the Windows XP desktop?

There you have it. We can all sleep just a little bit better now.

by **Nevyn** Sat Aug 08, 2015 10:07 pm

After the great fanfare release of Version 0.4, I got to work on actually building models. In doing so, I immediately found that there were some bugs in the UI. I fixed them easily enough but I couldn't be bothered to separate them from the changes already made. Therefore, I have rolled those changes back into Version 0.4 and updated the site.

Fixed Bugs:

I fixed a bug in the JSON Element Creator dialog box where you couldn't add or insert the JSON Element definition. This was a result of some changes I made to how elements are stored inside the system.

I also fixed a bug that caused the text at the top of the modal dialog boxes to not show. It was actually there but it was being rendered white on a white background. This was caused by a missing CSS file for Bootstrap.

New Features:

I updated the atomic structure to support neutrons in various places. You can now specify "attach1" and "attach2" structures on any hook level alpha. These can just be neutrons, no protons required. When only placing neutrons, it will group and arrange them based on the number of neutrons in the group. It currently supports up to 3 neutrons in a group. I have not seen any models that need more than 3 but I will add support for up to 6.

I also fixed the way the attachments are oriented to support neutron groups better. This has changed the side that the attachments are on depending on whether they are in a north or south position (or east/west and front/back as hook alphas in the carousel level can have attachments now too). The "attach1" structures are placed on the right if north and on the left if south. This means that if you want 2 attachments then you just use "attach1" for both (assuming 1 north and 1 south, etc) and the system takes care of placing them correctly. I also updated my converter for Cr6's spreadsheet so that it puts them into the correct attachment.

I have added a Periodic Table Manager that allows multiple tables to be used. There are currently 2 tables, 'Nevyn's periodic table' and 'Cr6's periodic table', Nevyn's table is the default (any complaints of preferential treatment can be taken up with project management). Only 1 table is used at any 1 time but you can swap between them and load elements from either model into the same scene. Use the "Select source" action to choose between tables.

I went through Cr6's data and compared them to my models (visually) and changed the ones that were different to mine. I'm not saying either one is the correct version, just different. We can now load both models into the UI and compare them which will hopefully spawn some interesting discussions. If anyone else wants a periodic table of their own then just send me the JSON elements you want in it and I will add it in. These are easy to add and edit so don't worry about bugging me with updates.

New Features in previous Version 0.4:

Some new features I didn't mention previously are backgrounds, geometry and material quality settings, a new hemisphere light source and I have changed the way lights are setup, and some nice textures for particles and charge fields.

Backgrounds are separated into 2 groups: Sky and Landscape. The Sky backgrounds render a texture onto either a box or sphere that is huge and its texture is rendered onto the inside of it so that you can see it. The Landscape backgrounds render a texture onto a huge plane that stretches off into the horizon. You can combine Sky and Landscape backgrounds into Presets which just apply both at the same time. Also notice that if you change the Sky and Landscape individually, and they both match a preset, it will select the preset in the drop-down box.

The geometry already had a quality setting but we also have a material quality for both particles and charge fields. This selects the way lighting affects the material. A setting of 'low' will not use lighting, 'medium' will use per-vertex lighting and 'high' will use per-pixel lighting. Per-pixel lighting takes a lot of processing power and isn't really worth the effort, but it is there if you want it.

You can now use a hemisphere light which is a general light source from a certain direction. It is kind of a mixture of an ambient light and a directional light. I have also altered the way lights are setup when you choose the performance setting. Previously, it would turn on the different lights as you went to higher settings. This was pretty annoying sometimes as the directional and spot lights could be a bit over-powering and you would lose color definition. Now, it doesn't use lights on the lowest setting, then it turns on the ambient light and then it turns off the ambient light and turns on the hemisphere light. Above this, it turns on the directional and spot lights (at higher performance settings) but does not activate the individual lights (there are 2 of each type). This means that the directional and spot lights are there for you to turn on if you want to but will not be used by default.

I'm pretty happy with how the textures turned out. The protons, with their sexy charge fields, look great and so do the neutrons. The electrons are too small so I did not add any textures to these, although, if they have a charge field this will have the same texture as a protons charge field (since they go through the same code path).

There is also now a Define Element modal dialog box which actually doesn't do anything at the moment but is an attempt to specify the particle counts of an element in UI controls. This will need to be updated to support attachments and to get it operational.

There are probably other enhancements and features that I have missed. The system is much more stable than previous versions but it can still crash under certain circumstances.

There is a bug in the UI system that receives key events. This is a problem when using a dialog box to write element definitions because it will open other dialogs if you press either 'e' or 'j'. It is generally easier to copy/paste into/from an external text editor and also saves you from crashes.

by **LongtimeAirman** Sat Aug 08, 2015 11:27 pm

Congratulations, That’s a fine job indeed!

Your latest update above knocks my comment count way down. I’m anxious to give you feedback but I’m learning too slow.

The control panel works out very well. And you’ve included so many visual possibilities!

I don’t see the bottoms of the element or period selectors (except period 1 since it is so short), but the window sliders allow access. Low priority.

I see titles as the elements are being generated, but as soon as the display is compete, the title is gone. It would be best to have an on/off able switch to control titles. Low priority.

For clarity, compacting your JSON Element format:
{
"name": ""
,"symbol": ""
,"atomicNumber": N
,"levels":
{
"core": { "protons": N,"neutrons": N,"electrons": N },
"pillar": { "north": { "protons": N,"neutrons": N,"electrons": N },
"attach1": { "protons": N,"neutrons": N,"electrons": N },
"attach2": { "protons": N,"neutrons": N,"electrons": N }
}
"south: { "protons": N,"neutrons": N,"electrons": N },
"attach1": { "protons": N,"neutrons": N,"electrons": N },
"attach2": { "protons": N,"neutrons": N,"electrons": N },
}
"cap": { "north: { "protons": N,"neutrons": N,"electrons": N },
"south": { "protons": N,"neutrons": N,"electrons": N },
}
"carousel": { "east": { "protons": N,"neutrons": N,"electrons": N },
"west": { "protons": N,"neutrons": N,"electrons": N },
"front": { "protons": N,"neutrons": N,"electrons": N },
"back": { "protons": N,"neutrons": N,"electrons": N },
}
"hook": { "north": { "protons": N,"neutrons": N,"electrons": N},
"south": { "protons": N,"neutrons": N,"electrons": N},
"east": { "protons": N,"neutrons": N,"electrons": N},
"west": { "protons": N,"neutrons": N,"electrons": N },
"front": { "protons": N,"neutrons": N,"electrons": N},
"back": { "protons": N,"neutrons": N,"electrons": N }
}
}
}
(I've probably screwed up curly brackets and commas).

And the list of Proton Locations. (We are looking at iron).

Atomic Model Editor Proton10

The hook level differences aside, will the Elemental format allow the inclusion of additional neutrons as are shown in Mile’s diagram? Corrected, That’s quick customer service!

Nice to see the neutrons spinning. I could quibble that electrons appear to rotate at the same rate.

Does it seem relevant that the atoms themselves will be rotating right or left? Or that atomic interactions will be occurring despite that spin differential? I believe that we all understand that the primary energy source for our atoms streams up from below (here on earth’s surface), or from the sun or moon, hell’s latrines or the ambient spaces between galaxies. It seems possible to show such differentials within the current structure.

Can you elaborate a bit on using “shaders”? Will it allow quantitative operations, such that we can develop the pre-fields using the current viewer?

I'm using Internet Explorer with a touchscreen. I can easily rotate, or change vantage points, but the zoom doesn't work.

Good stuff, Nevyn

by **Nevyn** Sun Aug 09, 2015 5:16 am

Thanks, Airman. I spent so much time under the hood that I thought I would stop and do some work on more visual features and I'm pretty happy with it.

LongtimeAirman wrote:

I don’t see the bottoms of the element or period selectors (except period 1 since it is so short), but the window sliders allow access. Low priority.

I think this is a problem with your browser. Have a look for any compatibility settings you can change and see if it helps. It works on my version of IE (11.0.9600.17914, updates 11.0.21) which I am very impressed by. I didn't think it would but it works quite well.

LongtimeAirman wrote:I see titles as the elements are being generated, but as soon as the display is compete, the title is gone. It would be best to have an on/off able switch to control titles. Low priority.

I did a little bit of work on titles a while ago but when I rewrote the element loading system it was left behind. I've just added it back in with a bit of an upgrade too so you will see that in the next update.

LongtimeAirman wrote:For clarity, compacting your JSON Element format:
...
(I've probably screwed up curly brackets and commas).

You did very well with the JSON, only a few trailing commas which some parsers may even work with.

Here is the updated version of the JSON format:

Code:: { "name": "" ,"symbol": "" ,"atomicNumber": N ,"properties": { "<name>": "<value>" } ,"levels": { "core": { "angularVelocity": N, "protons": N, "neutrons": N, "electrons": N } ,"pillar": { "north": { "angularVelocity": N ,"protons": N ,"neutrons": N ,"electrons": N ,"attach1": { "protons": N, "neutrons": N, "electrons": N } ,"attach2": { "protons": N, "neutrons": N, "electrons": N } } ,"south": { "angularVelocity": N ,"protons": N ,"neutrons": N ,"electrons": N ,"attach1": { "protons": N, "neutrons": N, "electrons": N } ,"attach2": { "protons": N, "neutrons": N, "electrons": N } } } ,"cap": { "north": { "protons": N, "neutrons": N, "electrons": N } ,"south": { "protons": N, "neutrons": N, "electrons": N } } ,"carousel" { "angularVelocity": N ,"east": { "protons": N, "neutrons": N, "electrons": N } ,"west": { "protons": N, "neutrons": N, "electrons": N } ,"front": { "protons": N, "neutrons": N, "electrons": N } ,"back": { "protons": N, "neutrons": N, "electrons": N } } ,"hook" { "north": { "protons": N ,"neutrons": N ,"electrons": N ,"attach1": { "protons": N, "neutrons": N, "electrons": N } ,"attach2": { "protons": N, "neutrons": N, "electrons": N } } ,"south": { "protons": N ,"neutrons": N ,"electrons": N ,"attach1": { "protons": N, "neutrons": N, "electrons": N } ,"attach2": { "protons": N, "neutrons": N, "electrons": N } } ,"east": { "protons": N ,"neutrons": N ,"electrons": N ,"attach1": { "protons": N, "neutrons": N, "electrons": N } ,"attach2": { "protons": N, "neutrons": N, "electrons": N } } ,"west": { "protons": N ,"neutrons": N ,"electrons": N ,"attach1": { "protons": N, "neutrons": N, "electrons": N } ,"attach2": { "protons": N, "neutrons": N, "electrons": N } } ,"front": { "protons": N ,"neutrons": N ,"electrons": N ,"attach1": { "protons": N, "neutrons": N, "electrons": N } ,"attach2": { "protons": N, "neutrons": N, "electrons": N } } ,"back": { "protons": N ,"neutrons": N ,"electrons": N ,"attach1": { "protons": N, "neutrons": N, "electrons": N } ,"attach2": { "protons": N, "neutrons": N, "electrons": N } } } } }

I've specified "attach1" and "attach2" on the hook.north and hook.south locations but I have not implemented that yet. I'm not sure its needed but it is extremely easy to add (in fact I have to allow it to happen rather than add it in).

LongtimeAirman wrote:And the list of Proton Locations. (We are looking at iron).

The hook level differences aside, will the Elemental format allow the inclusion of additional neutrons as are shown in Mile’s diagram? Corrected, That’s quick customer service!

I spent this morning working through some actual models and added a few nice features like this. It was Iron that forced me into it. I opened up my old model and it had neutrons everywhere! Shit! I thought. I better address that now then.

LongtimeAirman wrote:Nice to see the neutrons spinning. I could quibble that electrons appear to rotate at the same rate.

The neutrons spin at their own rate which is a little bit slower than electrons. You can adjust the rate for both of them in the settings.

LongtimeAirman wrote:Does it seem relevant that the atoms themselves will be rotating right or left? Or that atomic interactions will be occurring despite that spin differential? I believe that we all understand that the primary energy source for our atoms streams up from below (here on earth’s surface), or from the sun or moon, hell’s latrines or the ambient spaces between galaxies. It seems possible to show such differentials within the current structure.

I had implemented some code a while ago that was meant to rotate the carousel level but I never got around to actually hooking it up. Your comment pushed me into it and I have that working now. While I was at it, I thought I would add angular velocity to the axis level too. This would give the atom 2 spins: the axis level spinning about the Y axis and the carousel level spinning about the Y axis independently. I got it working and sat looking at the results and it just didn't look right. Not right at all.

It needed another spin. The axis has no reason to spin as a single entity. It contains a north and a south arm which can both spin independently of each other. With charge coming in from the north and anti-charge coming in from the south (or vice-verse) each arm would gain spin from that charge. So they would spin opposite ways.

So I dived in and implemented that and it looks so much better. As I sat back and watched my north axis spin one way, the south axis spin the other way and the carousel level spinning one of those ways, I realised that the carousel level would spin as a result of the axis spin. That is, the carousel would be feeling forces from both arms so if one of them is spinning faster than the other, that is the direction that the carousel level will spin with an angular velocity that is the difference between the north and south axis velocities. On earth, we have a 1:2 ratio of charge:anti-charge which sets the south axis rotating faster than the north.

This means that in more neutral environments, atoms may not spin about their carousel levels. Also, in superconductivity, we may have a case where the south axis spins the same direction as the north axis, providing more conduction in a single direction. This would take a pretty powerful charge current but under extreme cold it would be easier to accomplish.

Notice that in the JSON Element specification, the core, carousel, pillar.north and pillar.south elements may have an angularVelocity property. If this is specified on any of them, then it will spin at the specified rate which is radians per second. If you DO NOT specify an angularVelocity on the carousel level, then it will go into reactive mode. In this state, it will watch the pillar.north and pillar.south locations and react to them. I will probably do the same for the core which I think should operate on the same principle. I will also implement new controls to disable the rotations because sometimes they just get in the way.

LongtimeAirman wrote:Can you elaborate a bit on using “shaders”? Will it allow quantitative operations, such that we can develop the pre-fields using the current viewer?

A long time ago, in a galaxy far, far away, some engineers wanted more power. Don't they always want more power? Anyway, we wanted to do more graphics work and machines of the day were just not up to the task. So the graphics card manufacturers (NVidia, ATI) answered our prayers with 2 things: vertex shaders and pixel shaders. These were hardware implementations of common routines that could be used in a programmable way. The beauty of them though, was that there were lots of them (more and more with every generation since) and they could all work at the same time! This is the key feature because graphics work often revolves around looping over image data or geometry, etc. We often have to do the same thing, with slight variations, to every pixel in the image, for example. Well, you develop a shader that operates on 1 pixel and then you apply it to every pixel in the image at the same time. So now the internal code of your loops are all happening in parallel and you get the results much, much faster.

In the beginning, the 2 worlds were separate. You had vertex shaders, which operated on vertices of geometry, and you had pixel shaders, which operated on pixels of images. In essence, pixel shaders are a 2D world while vertex shaders are 3D. You often write your vertex shaders to setup data that the pixel shader will use later. Vertex shaders always run before pixel shaders since you have the work the geometry to form the 2D image.

*** Edit ***

I was slightly wrong in my description about shaders here. The pixel shaders are not 2D and do not work in an image based manor. They are still 3D and you can use them in a number of ways, but the usual way is to specify the color of a vertex (3D point in the geometry) and also how the system should interpolate the colors between vertices. So if I set 1 vertex to red and the next 1 to green, then I can tell the system to smoothly interpolate between them and it will adjust the color from red to green as it goes from the first vertex to the second. This gives you are nice smooth change from 1 color to the next along that line. Since all polygons are broken down into triangles, the 3 vertices are used to interpolate the color across the triangle.

*** /Edit ***

Now, there isn't really much difference and you can write it all in one if you want. Some API's still separate the 2 since it is convenient at times. It really depends on what you are doing. You see, they aren't really 'shaders' anymore. That was their purpose in the early days and the name has stuck but they are better called a 'compute unit'. You can use these compute units for anything you want to. I've used them to calculate charge field interactions that had nothing to do with graphics, just 3D entities (and it was attached to a graphics engine later, but not for calculations, just visualizing results).

For this project, I will first look into using them as 'shaders' in order to render a charge field effect. I had that intention, anyway. Since seeing the new textures in place, I'm not sure it's worth the effort at this stage. I'll see what the future holds. I might just decide that I am interested in seeing how that might work one day and get into it.

Other uses I might find for them are calculating charge density fields. I have an idea of creating a 3D grid of a certain volume. Each cell calculates the density and resultant velocity of charge in that volume of space given all of the particles around it. This will create the charge profile of an atom. I can run the calculations of each cell as a shader so that they all run in parallel.

LongtimeAirman wrote:I'm using Internet Explorer with a touchscreen. I can easily rotate, or change vantage points, but the zoom doesn't work.

Good stuff, Nevyn

I've only tried it on an old iPad which didn't work. My phone works, sort of, it is difficult to navigate around because everything is so squashed up. I really haven't thought about small devices but some of the API's I am using support them so there may be limited operation.

by **Cr6** Sun Aug 09, 2015 7:19 pm

Wow, this is too cool Nevyn! Smile

And after reading a Mathis' paper on an element-molecule, it is now fun to fire up your "Atomic Viewer" to see it. The Angular Velocity is really a nice feature...looks great. Nice adds with the protons. It looks like it is giving a true Mathis periodic table.

Like LTAM said, "Good stuff".

by **LongtimeAirman** Mon Aug 10, 2015 5:14 pm

Hey Guys, I can't be happy for long. I'm doomed to wander forever.

http://milesmathis.com/gas.pdf

IMHO This alpha neutron alignment idea is, as Miles kinda said, elegant.

First. I originally believed that the basic unit for describing atoms was the proton. Alphas were simply orderly pairs of protons (along with the necessary neutrons and electrons). But now, alphas act as charge field detectors. Whenever possible, they align themselves (maybe through gyroscopic/angular momentum maxima) to receive available charge flows through a proton pole. The alpha literally changes its “configuration” as the charge flow varies by adjusting antiparallel to parallel neutron positions. Can the alpha be a base unit reflecting charge flow directions and magnitudes. Of course, alphas within the atom align pretty much with the atom, but "end" alphas can redirect the atom or match charge flows.

Second. Atoms want to point their south poles toward the charge flow source too. Lone or loosely associated atoms can act like gimbals. When the charge source direction changes, the noble gases easily realign, while the rest of the elements have wobbles and such that prevents perfect alignments.

I realize we weren’t anticipating large logic structure changes. I hope I'm not making too much of this. Whaddaya think?

by **Nevyn** Mon Aug 10, 2015 11:03 pm

Hi Airman,

At the moment, I don't think this new paper impacts the Atomic Viewer. This new stuff is about calculating data from the atomic structure we have defined (and I am really happy to see some new ways to think about that in the new paper). The current structure is enough to describe the positions of particles and the rest is (will be) calculated from that.

Neutron alignment is not necessary (at the moment) because you could not tell the difference anyway (a sphere is a sphere no matter which orientation you look at it from) and we are not calculating that kind of data yet. I want to get to that point but it is a fair way off. I have started calculating data now. I have added some controls that allow you to set the ambient charge field strengths for north and south. This is then used to make the north and south axis arms spin, which, in turn, causes the carousel level (and core) to spin given the difference between north and south spin. This is very basic at the moment and does not take the size of the arms into consideration in determining how fast they rotate (it is mass so it must reduce the applied force). However, as the arms are usually well balanced, this is not too much of a problem.

Viewing all of this spinning is a bit jarring at the moment. I am not used to seeing it. I thought it looked great until I opened up a model that had some attachments in the pillar positions and it looked very strange as those attachments spun with the axis level. The balance of the atom seemed to be broken but the more I watched, the more I got used to it. You could see how those pillar attachments would take the charge from the carousel level which would cause a pulsing of charge through the nucleus as the attachments (and/or carousel) rotates and the attachment and carousel alphas move in and out of alignment. Miles has mentioned these charge pulses before but not in this way.

So, eventually, we may need to handle neutron alignment. This could be as simple as having a positive neutron count mean it uses charge and a negative neutron count means anti-charge. Or we add a new property called 'antiNeutrons' so that you could specify both neutrons and anti-neutrons in the same location (so neutron groups could have differing neutrons, can't really see where that would be needed but it might). This is probably my preferred option since it would leave the existing code working while ignoring the antiNeutron values. We will need to find some way to visually differentiate them based on this data too. I have some ideas but nothing I really like.

What I would really like to work on, as far as calculating data goes, is determining the charge strengths of the atom itself. Miles did some of this math in one of the nuclear papers (I think it might have been the paper about period 4). He talked about having a core strength (number of protons in the core) and would use that to gauge the strength of hook alphas (protons in hook / protons in core) and then related it to the number of full alphas in the noble levels (all major locations except hooks). I can't remember the specifics but when I first read about it I changed my models (in the old desktop app) so that they were specified much more like how I have built them in this new app (using the idea of arms rather than levels) in the hope of calculating data from it. I didn't get too far down the calculation route or rewriting the models to use it but I think the structure supports it.

From that data, we could determine what elements would bond together and show the general charge profile of the element. I think that would be a great start to using this data in a meaningful way. I just need to find the relevant references and make some sense of them.

Good to see you thinking about this though. Don't worry about taking something too far as it is often good to take it to an extreme and then dial it back to reality (which I think Miles mentioned in his latest paper, but I often work this way). I will just say that in programming, physics and math in general, you need to separate your 'givens' from your 'calculables'. That is, never specify what you can calculate (unless you have a very good reason such as performance, ease of use, etc, there are always exceptions to any rule).

The current JSON Element format specifies the structure of an element but in doing so it also specifies, or implies, the relationships between parts of the element and we can use this to calculate other data rather than specify it directly in the JSON. By doing it this way, all current models get the new feature for free but if we change the JSON definition, we have to change every single existing model to incorporate it. Remember, work smarter, not harder.

As an example, I added the 'angularVelocity' properties to various places in the JSON structure to handle rotations but once I had put in the ambient charge controls, I realised that I didn't need those values in the JSON anymore. The system took care of it all for me and I didn't need to change any models (which at this point is over 200 models if you include both mine and Cr6's data).

As a slight contradiction to that, I will point out that when first trying to implement something, it is good to just get in and build it in a direct fashion. Once you have it working, then you can try to make it more flexible or abstract or whatever you need it to be. It is a bit too much to think about, sometimes, to create the complete solution first go. This does become easier as you get more comfortable with programming (or whatever you apply this info to) because you don't need to think so much about the low-level code and you just think in higher-level concepts.

by **Nevyn** Sat Aug 15, 2015 7:06 pm

Atomic Viewer 0.5 is here for all to enjoy.

We have quite a few changes this time around so we will start with the control panel. We have some new folders in the top level control panel with the list now containing: 'Atomic Models', 'Effects Settings', 'View Settings' and 'Graphics Settings'.

by **Nevyn** Sat Aug 15, 2015 7:07 pm

Atomic Models

Contains actions to work with the models.

'Select source' - select the current periodic table used to load elements.
'Select element' - select elements to load from the current periodic table.
'Define element' - improved and functional element UI system to specify particle counts.
'Define JSON' - JSON based controls to copy/paste element definitions.
'Remove' - delete the currently selected entities.
'Remove all' - delete all current entities.
'Rebuild' - rebuild all entities.

by **Nevyn** Sat Aug 15, 2015 7:08 pm

Effects Settings

Contains controls that change settings for runtime effects. These are actions that are calculated every frame (or close enough).

'Behaviors' - sub folder containing Behavior related controls.
'Enabled' - enable/disable all Behaviors. No Behavior will be executed.
'Scheduling' - enable/disable Behavior scheduling. This sets all Behaviors as scheduled to be executed.
'Schedule radius' - set the radius of the scheduling bounds.
'Element radius' - set the scheduling radius of each element.

'Particles' - sub folder containing particle related controls.
'Neutrons' - sub folder containing neutron related controls.
'Enabled' - enable/disable neutrons being shown.
'Rotate' - enable/disable rotation of neutrons.
'Rotation rate' - set the rate of rotation of neutrons in radians/s.
'Electrons' - sub folder containing electron related controls.
'Enabled' - enable/disable electrons being shown.
'Rotate' - enable/disable rotation of electrons.
'Rotation rate' - set the rate of rotation of electrons in radians/s.
'Charge field' - enable/disable the charge field on electrons, causes crashes on large or many elements.

'Charge field' - sub folder containing charge field related controls.
'Enabled' - enable/disable ambient charge field calculations.
'Rotation rate' - set the base rotation rate in radians/s.
'Charge density' - set the charge density which comes down from the top of the screen.
'Anti-charge' - set the anti-charge density which comes up from the bottom of the screen.

by **Nevyn** Sat Aug 15, 2015 7:09 pm

View Settings

Contains view related controls which are often more static than the Effects Settings.

'Placement' - set the method used for placing elements.
'Explode' - set the distance between proton stacks.

'Background' - sub folder for background related controls.
'Sky' - set the background sky model.
'Landscape' - set the background landscape model.
'Presets' - set both at once to a preset setting.

'Meta Data' - sub folder containing information controls.
'Show metadata' - enable/disable all metadata shown.
'Show symbol' - enable/disable showing the atomic symbol.
'Show title' - enable/disable showing the elements name.
'Show number' - enable/disable showing the atomic number.

'Proton Stack' - sub folder containing controls for changing proton stack settings.
'Field size' - set the size of the charge field.
'Neutron location' - set the percentage of Field size to locate neutrons.
'Color scheme' - set the color scheme used to color proton stacks.

'Color' - sub folder containing color related controls.
'1 Proton' - set the color of a 1 proton stack.
'2 Proton' - set the color of a 2 proton stack.
'3 Proton' - set the color of a 3 proton stack.
'4 Proton' - set the color of a 4 proton stack.
'5 Proton' - set the color of a 5 proton stack.
'6 Proton' - set the color of a 6 proton stack.

by **Nevyn** Sat Aug 15, 2015 7:10 pm

Graphics Settings

Contains graphics settings. These will often require rebuilding elements to implement changes.

'Performance' - set the general performance level your system can handle.

'Particles' - sub folder containing particle related graphics settings.
'Geometry quality' - set the maximum quality of geometry used to build particles.
'Material quality' - set the maximum quality of materials used to build particles.

'Charge Emission' - sub folder containing charge emission related controls.
'Quality' - set the maximum quality of charge fields.
'Transparent' - enable/disable transparent charge fields. performance hit.
'Opacity' - set the amount of transparency (by opacity) of charge fields.
'Wireframe' - enable/disable wireframe charge fields.

'Lighting' - sub folder containing light controls.
'Enabled' - enable/disable all lighting.

'Ambient' - sub folder containing ambient light settings.
'Enabled' - enable/disable the ambient light.
'Color' - set the color of the ambient light.

'Hemisphere' - sub folder containing hemisphere light settings.
'Enabled' - enable/disable the hemisphere light.
'Sky color' - set the sky color of the hemisphere light.
'Ground color' - set the ground color of the hemisphere light.
'Intensity' - set the intensity of the light.

'Directional' - sub folder containing directional light settings.
'Enabled' - enable/disable the directional lights.

'Light 1' - sub folder containing controls for directional light 1.
'Enabled' - enable/disable directional light 1.
'Color' - set the color of directional light 1.
'Intensity' - set the intensity of directional light 1.

'Position' - sub folder containing position related controls.
'X' - set the X direction of directional light 1.
'Y' - set the Y direction of directional light 1.
'Z' - set the Z direction of directional light 1.

'Light 2' - sub folder containing controls for directional light 2.
'Enabled' - enable/disable directional light 2.
'Color' - set the color of directional light 2.
'Intensity' - set the intensity of directional light 2.

'Position' - sub folder containing position related controls.
'X' - set the X direction of directional light 2.
'Y' - set the Y direction of directional light 2.
'Z' - set the Z direction of directional light 2.

'Spot' - sub folder containing spot light settings.
'Enabled' - enable/disable the spot lights.

'Light 1' - sub folder containing controls for spot light 1.
'Enabled' - enable/disable spot light 1.
'Color' - set the color of spot light 1.
'Intensity' - set the intensity of spot light 1.
'Distance' - set the distance of spot light 1.
'Angle' - set the angle of spot light 1.
'Dissipation' - set the dissipation rate of spot light 1.

'Position' - sub folder containing position related controls.
'X' - set the X direction of spot light 1.
'Y' - set the Y direction of spot light 1.
'Z' - set the Z direction of spot light 1.

'Light 2' - sub folder containing controls for spot light 2.
'Enabled' - enable/disable spot light 2.
'Color' - set the color of spot light 2.
'Intensity' - set the intensity of spot light 2.
'Distance' - set the distance of spot light 2.
'Angle' - set the angle of spot light 2.
'Dissipation' - set the dissipation rate of spot light 2.

'Position' - sub folder containing position related controls.
'X' - set the X direction of spot light 2.
'Y' - set the Y direction of spot light 2.
'Z' - set the Z direction of spot light 2.[/b]

by **Nevyn** Sat Aug 15, 2015 7:10 pm

Behaviors

A Behavior is a schedulable action that will cause change in the scene. It has a schedulingBounds which is a sphere that defines the volume of space of the Behavior. The Behavior Engine also has a schedulingBounds, centered on the camera, and if the two schedulingBounds intersect, then the Behavior is scheduled for execution.

Before a Behavior is executed, it is checked to determine if the Behavior is actually executable. If so, then its execute method will be invoked and it can perform its changes on the system. This pre-check allows a Behavior to check for custom conditions such as 'is the control key down'.

The idea behind this Behavior Engine is to reduce unnecessary computations. If an element is so far away from you that you can't see its electrons, then why rotate them? There is a performance penalty for this, even though I am trying to enhance performance. Checking sphere intersections can be expensive if you have too many of them, however, it is pretty hard to tell the difference on my machine.

by **Nevyn** Sat Aug 15, 2015 7:10 pm

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.

by **Nevyn** Sat Aug 15, 2015 7:11 pm

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.

by **Nevyn** Sat Aug 15, 2015 7:11 pm

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.

by **Nevyn** Sat Aug 15, 2015 7:11 pm

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.

by **Nevyn** Sat Aug 15, 2015 7:11 pm

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.

by **Nevyn** Sat Aug 15, 2015 7:11 pm

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.

by **Nevyn** Sat Aug 15, 2015 7:12 pm

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.

by **Nevyn** Sat Aug 15, 2015 7:12 pm

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.

by **Nevyn** Sat Aug 15, 2015 7:30 pm

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.

by **Nevyn** Sat Aug 15, 2015 8:20 pm

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.

by **LongtimeAirman** Wed Aug 19, 2015 8:22 pm

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.

by **Nevyn** Thu Aug 20, 2015 1:27 am

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.

by **Cr6** Thu Aug 20, 2015 2:15 am

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.

by **Nevyn** Thu Aug 20, 2015 8:37 pm

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?

by **LongtimeAirman** Thu Aug 20, 2015 10:13 pm

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.

by **Nevyn** Thu Aug 20, 2015 10:22 pm

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

by **Nevyn** Fri Aug 21, 2015 3:14 am

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.

by **LongtimeAirman** Sun Aug 23, 2015 1:31 am

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.

by **Nevyn** Sun Aug 23, 2015 3:56 am

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.

by **LongtimeAirman** Mon Aug 24, 2015 11:32 pm

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.

by **Nevyn** Tue Aug 25, 2015 12:14 am

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.

by **Nevyn** Thu Sep 10, 2015 1:13 am

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.

by **Nevyn** Thu Sep 10, 2015 8:06 am

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.

by **Nevyn** Thu Sep 10, 2015 8:24 pm

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.

by **Nevyn** Sat Sep 12, 2015 5:02 pm

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.

by **Nevyn** Thu Sep 17, 2015 7:30 pm

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.

by **LongtimeAirman** Fri Sep 18, 2015 11:27 pm

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.

by **Nevyn** Sat Sep 19, 2015 12:17 am

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.

by **LongtimeAirman** Sat Sep 19, 2015 12:31 am

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

by **Nevyn** Sat Sep 19, 2015 10:31 am

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.

by **LongtimeAirman** Sat Sep 19, 2015 12:51 pm

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.

by **Nevyn** Sat Sep 19, 2015 8:16 pm

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.

by **LongtimeAirman** Sat Sep 19, 2015 10:46 pm

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

by **Nevyn** Sat Sep 19, 2015 11:16 pm

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.

by **LongtimeAirman** Sat Sep 19, 2015 11:56 pm

by Sponsored content