Atomic Model Editor

Page 2 of 7 Previous  1, 2, 3, 4, 5, 6, 7  Next

View previous topic View next topic Go down

Re: Atomic Model Editor

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

LongtimeAirman
Admin

Posts : 620
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Atomic Model Editor

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

Posts : 826
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Atomic Model Editor

Post by Cr6 on 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.

Cr6
Admin

Posts : 695
Join date : 2014-08-09

View user profile http://milesmathis.the-talk.net

Back to top Go down

Re: Atomic Model Editor

Post by Nevyn on 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?
avatar
Nevyn
Admin

Posts : 826
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Atomic Model Editor

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


Last edited by LongtimeAirman on Thu Aug 20, 2015 11:44 pm; edited 3 times in total

LongtimeAirman
Admin

Posts : 620
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Atomic Model Editor

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

Posts : 826
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Atomic Model Editor

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

Posts : 826
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Atomic Model Editor

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

LongtimeAirman
Admin

Posts : 620
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Atomic Model Editor

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

Posts : 826
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Atomic Model Editor

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

LongtimeAirman
Admin

Posts : 620
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Atomic Model Editor

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


Last edited by Nevyn on Thu Sep 17, 2015 7:33 pm; edited 1 time in total
avatar
Nevyn
Admin

Posts : 826
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Atomic Viewer 0.6

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


Last edited by Nevyn on Fri Nov 20, 2015 4:08 pm; edited 1 time in total
avatar
Nevyn
Admin

Posts : 826
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Atomic Model Editor

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

Posts : 826
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Atomic Model Editor

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

Posts : 826
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Atomic Model Editor

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

Posts : 826
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Atomic Model Editor

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

Posts : 826
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Atomic Model Editor

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

LongtimeAirman
Admin

Posts : 620
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Atomic Model Editor

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

Posts : 826
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Atomic Model Editor

Post by LongtimeAirman on Sat Sep 19, 2015 12:31 am

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

LongtimeAirman
Admin

Posts : 620
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Atomic Model Editor

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

Posts : 826
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Atomic Model Editor

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

LongtimeAirman
Admin

Posts : 620
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Atomic Model Editor

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

Posts : 826
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Atomic Model Editor

Post by LongtimeAirman on Sat Sep 19, 2015 10:46 pm

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

LongtimeAirman
Admin

Posts : 620
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Atomic Model Editor

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


Last edited by Nevyn on Sun Sep 20, 2015 10:52 pm; edited 1 time in total
avatar
Nevyn
Admin

Posts : 826
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Atomic Model Editor

Post by LongtimeAirman on Sat Sep 19, 2015 11:56 pm




LongtimeAirman
Admin

Posts : 620
Join date : 2014-08-10

View user profile

Back to top Go down

Page 2 of 7 Previous  1, 2, 3, 4, 5, 6, 7  Next

View previous topic View next topic Back to top


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