Virtual Scattering Application

Aim: To create an app that shoots bullets at a target to show the results of collisions.

Guns

The user will be able to select different gun types. From single position and direction to multiple positions and directions. Maybe different guns have different bullets too, but that will be for later.

Bullets

The bullets will be small spheres in the first instance. We may expand that to support larger radii in the second instance, and bullets with stacked spins at some stage.

Each bullet has a state, which can be FIRED, ARMED or COLLIDED. A fired bullet has just left the gun and is moving towards the target (or some set direction). An armed bullet has crossed a boundary around the target that marks it as being able to collide with that target, but it may not. A collided bullet has collided with the target. The ARMED state may be needed to determine if a bullet should be recorded or not. We may be able to use the bullets position and velocity to determine the direction that it crosses the detector boundary and only record bullets coming from the target, not moving towards it.

Color will be used to show the state of each bullet.

Detectors

The user can select from a range of detectors. The first detector will probably be a sphere that records the position that a bullet crosses the detector boundary and the state of that bullet at that time. Other detectors may be created, such as a probe that has a position and size in the scene. This would allow you to setup various probes at locations that you care about (such as the poles and equator).

Detectors will be used to save the results of an experiment. It could save an image or the raw data.

Target

The target will be a particle in the first instance, but may be expanded to include atoms and molecules at some stage. That does get very complicated, but we might be able to manage it.

The particle target will have stacked spins, and the bullets can only collide with the BPhoton, not the particle. Initially, the user will just set the number of stacked spin levels, but we may use my Spinning Particle Language (SPL) to allow more flexibility later.


Any ideas anyone has about this app are welcome.

.

Here’s a serious effort – yes, it’s hard to tell - at depicting the new App.

Don't let my images scare you, comments from interested observers are welcome.

The circular firing range of 25 photon cannon – ok, guns - have all fired single bullets sequentially in clockwise order directly toward the center of the magenta particle - All non-colliding bullets will emerge radially outward from the particle equatorial plane on a line that will extend between opposing guns - hence we don't need to add those lines unless we wish to.

Concentrating on the test bullets: Blue were the last three fired, they haven’t yet reached the detector threshold (depicted by 5 brown circles), the equatorial circle is slightly lighter in color. Yellow means the bullets have crossed the detector threshold, and are now being ‘tracked’ by the detector. Inside the magenta particle space the ‘likely’ locations – showing the advancing bullet positions without a collision are also shown in yellow. Green, the bullet has emerged from the particle space on a course indicating there was no collision – it looks like I should have colored one of those yellow exited bullets green instead of yellow. Red bullets have emerged from the particle at unexpected locations and trajectories indicating they collided with the magenta particle’s target b-photon. In this test set-up, reds wouldn’t be expected to emerge radially or along the equator except by chance. The red lines and circles are a suggestion of a possible detector output indicating the particle space target/bullet collision location, but it is almost impossible to judge the true locations and directions of the red lines from one image/position as shown. I imagine 'painting' the exit position with azimuth and elevation angles that would give a much more detector output.

Nevyn wrote. Don't worry to much about the page itself, just try to code some math for it, figure out what data you might need, how you might structure it into an object, and see how they relate to each other

Right now there are mostly spheres, cylinders, circles and lines at their various locations. I can begin sandboxing the code, and loading up cannon. This App seems to have very strong game elements. Are there any special considerations, such as a particle factory?
.

I made that comment with respect to some new project that you might be able to think of. Not really this one. Of course, you can have a go for your own learning, but I've already started doing that for this project (but don't let that hold you back). I wasn't really expecting to share this one, it seems a bit small for that. The core code for the engine can't be shared easily (since a lot of it is in my head). However, there are other parts that you might look into. Unfortunately, I'm not really ready for that. So we might have to make some uneducated decisions about what to try, knowing that we might throw them out before too long. You get to keep the learning though! So it isn't wasted effort.

At this stage, I think it might be best to focus on the graphics, since I don't have the core engine ready. You seem to enjoy building models in your CAD program, so come up with some cool looking guns. I'd probably just do something like what you have above, simple constructs that don't take too much time to build. But it would be really good to have some nice looking models for the guns. Maybe, if you can think of any way to model them, you could try some detectors too. That is difficult because we don't really know what we are going to have to work with, but if you can think of a reasonable detector, and can visualize how you want it to look, then see what you can come up with. I also don't mind if you search for existing models on the internet (that are free to use), both for actual use and for ideas on how you might model your own.

That isn't exactly a programming task, but we often have to venture into other areas to get what we need, so it is a useful skill to work on.

You could also think about gun arrangements, like you have been. You could take the points-on-a-sphere algorithms you created for the Particle Interaction Model and put them into some functions that could easily be used for this project. For now, just a simple function that generates an array of THREE.Vector3 objects and returns it. Something like this:

Code:


function createHosohedronPoints( radius )
{
   var data = [];
   //TODO generate points here
   ...
   return data;
}

function createKoganPoints( radius )
{
   var data = [];
   //TODO generate points here
   ...
   return data;
}


We can put it into a better form later. Just get the algorithms together for now. When things are ready, I'll get you to hook these algorithms up with the gun models and get them arranged and setup correctly. Don't worry about that for now though, we aren't in a position to think about that.

I don't see any need for something like the particle factory at this stage. We also won't have scenarios like PIM did. It will be driven by controls on the page, which we might have to save and load so the user can create complex arrangements without losing them, but that's for later.

I'll look into creating the GIT repo (actually it is already created, I just haven't pushed anything to it yet) and giving you access to it this weekend.

.

Here are a couple of quick drafts, a possible photon cannon and photon detector for your consideration. The view of the 25p-gun array shows many aliasing problems - my autocad is quite old - the close-up shows the p-gun components don’t really have edge problems.


With no idea how serious or artistic the p-gun should be, I shared what I had before I'd completed them. I’d continue working this p-gun a bit more, I thought I’d replace the two semicircular ring/sight end with half an American football shape, then adding a tail fin for an oldtime ray-gun feel. For a second p-gun I’d attempt a classic tank turret cannon and then a third alternative with a modern rail gun look.


The detector has a mesh for a surface. So I made this particular mesh surface from three ortho sets of 25 circles. It’s two dimensional, confusing and complex. I think I’d like to show a sphere with latitude and longitude lines instead. But I think it needs another surface in order to allow the detector to calculate exiting photon trajectories, so a sphere with two - inner and outer - latitude and longitude lines might work nicely.

I enjoy and have done various design projects, but I’ve never even doodled a gun before. Please feel free to redirect my efforts or suggesting any changes, large or small, colors, details or style.
.

That's cool. I like that gun design. Simple to build too.

Detectors are a bit tricky. I'm thinking that spherical detectors will be outside of the guns, encompassing the whole arrangement, so we could think about making them look like walls. Maybe a hexagon pattern that we could put a texture on to look cool. Or even a texture that already has the pattern, like this:



So maybe just look for some textures for that sort of thing.

We may also need different sized guns/canons. We can shrink any model to the size we want, but it might be good to have a few different models for different sizes. Something that looks like a small gun, and others that look like bigger guns. Just something to think about, anyway.

We may even animate them. Moving parts. Light shows. I can't help but look at your ring guns and see each ring lighting up as it shoots a bullet.

I have pushed the first draft of the app.



6 guns around a target. Each gun has a random caliber, which is why some bullets are larger than others. They also have an accuracy setting, set to 0.9 where 1 is perfect accuracy, which you can see by the randomness of the bullets from a particular gun.



The target isn't working at the moment, so nothing collides, but it's a good start.

.

I've tried cloning scattering - no joy. I entered my bitBucket password and received the message above. It seems like every new beginning starts with pain. Blasting it makes me feel a little better.

P.S. Begging your pardon, I set up the empty Scattering folder in the GitFolder. I see that my windows bitBucket credentials was updated today - during my attempts - no doubt. What are the credential manager instructions again? I can't remember whether I'm supposed to delete that or what?
.

You're using the HTTPS clone URL, maybe try the SSH version: git@bitbucket.org:Nevyn2k/scattering.git

.

Everything's up and running - wonderful. I cloned the http Scattering with Fork. I tried to use Fork to fetch your latest changes twenty minutes ago, with a bad result - (unable to update local ref). I went back to SourceTree and Pulled the latest using the terminal, as you can see - that seemed to work. I'll look at the files next.
.

I spent some time working on the gun model. Created a generic way to implement new ones. Added some textures to make them look nice.

I also spent some time in the bullet shader. There are actually 2 bullet shaders now, but only 1 is used at a time. There is a basic bullet shader that just renders a circle of the specified color and transparency (per bullet). The 2nd shader uses a texture to render the bullet and applies the color and transparency to the color from the texture. It is using the textured shader at the moment. I think it looks pretty good. I did try a few different textures, but the current one looked the best.

Simple Bullet Shader:



Textured Bullet Shader:

I should also mention that we can use textures, but to do so I had to upload them to my website so that the app will download them when it loads. Otherwise, it fails a security check because the browser will only use images that it is allowed to use (it is referred to as a Cross Origin). To determine if it is allowed to use them, it tells the server its origin when it makes the request. If the server does not respond with the correct headers, it will fail the load. I tried a heap of things to get around it, but it just wouldn't work without deploying the app to a server. Since I knew you wouldn't have a server to use for dev, I opted to publish them on my site and refer to them in the app as a full URL. This will present problems if you want to experiment with textures, since you won't be able to upload them. We will have to deal with that when it happens. I might create a form that allows you to upload and manage them.

.
I’m 90% certain I’m up and running. Small doubts, such as when I launch the html there’s an alert error – no configuration file - contact my system administrator. Or after a Fetch, Pull and or Push, the top line of the sourcetree commit list contains uncommitted changes that go away after a program restart or two.

The textures bump this up to a half a meg image file.

It’s amazing watching the App grow. You’ve done a lot rather quickly and the pieces are coming together nicely. If I understood any of it I would better express my appreciation. The block house bunker room is almost intimate except for the ceiling being a side stacked concrete block wall, gives me the 'screaming-willies'. So the room’s interior surfaces are the detector eh? I see the bullets passing through each surface. I guess you’ll create a ‘positive detector hit’ object before long. As you indicated - perhaps by leaving stationary sprite/markers on the room’s interior surface?

Good job.

I can finally concentrate on understanding a small corner of the program as the place keeps growing. I’ll go see if torus geometry is available.
.

I spent all night working on that room and its textures. I was playing with Physical Based Rendering (PBR) which combines 4 or 5 images to create a single texture. The images are very large though (2K res, which is low res in a way, but still huge files), so I dropped it back to reasonable images. You can change the type of rendering it uses easily, though. Open the js/scattering-range-gen.js file and go to line 132. You will find this code:

Code:


 module.SimpleRangeGenerator.prototype.getTextureURLs = function()
 {
 return LAMBERT;
// return PHONG;
// return STANDARD;
 };


You can comment out LAMBERT and uncomment one of the others. The STANDARD value uses PBR.

Here are some shots of each rendering method:

Lambert



Phong



PBR with brick wall



PBR with metal grate



PBR showing the reflection of a spot light



This room represents the gun range. It is not a detector, it's just there for a background. The detectors will sit in front of the background and, hopefully, look good with it. There is still plenty of work needed on this room. Mostly just finding textures to try and find ones that work together. It also needs some distractions. Little extra parts that cover the monotonous walls. The walls look good, but are the same texture repeated and it needs some things to break that up.

I don't know what that alert is about. I have not seen that at in Chrome or Firefox. I don't even know what config file it could be talking about. See if there is any information on the console about it.

You should have a go at creating the ring gun above. I think you already are, hence looking for the TorusGeometry class (you should use TorusBufferGeometry if you can). To do that, you need to edit the js/scattering-gun-gen.js file and add a new GunGenerator class.

This is the SimpleGunGenerator class being used at the moment:

Code:


   module.SimpleGunGenerator = function()
   {
      G3D.ModelGenerator.call( this );
      
      var f = 10;
      this.bodyRadius = 0.15 * f;
      this.bandRadius = 0.16 * f;
      this.bandWidth = 0.05 * f;
      this.endCapRadius = 0.05 * f;
      this.endCapWidth = 0.02 * f;
      this.barrelRadius = 0.05 * f;
      this.barrelLength = 0.15 * f;
      this.bodyScale = new THREE.Vector3( 1, 1.2, 1 );
      
      this.useSharedMaterials = true;
   };
   
   module.SimpleGunGenerator.prototype = Object.create( G3D.ModelGenerator.prototype, {
      constructor: { value: module.SimpleGunGenerator, writable: false },
      ModelGenerator: { value: G3D.ModelGenerator.prototype, writable: false }
   } );
   
   module.SimpleGunGenerator.prototype.init = function()
   {
      this.ModelGenerator.init.call( this );
      
      this.geometry.sphere = new THREE.SphereGeometry( this.bodyRadius, 32, 32 );
      this.geometry.bands = new THREE.CylinderGeometry( this.bandRadius, this.bandRadius, this.bandWidth, 20 );
      this.geometry.endCap = new THREE.CylinderGeometry( this.endCapRadius, this.endCapRadius, this.endCapWidth, 6 );
      this.geometry.barrel = new THREE.CylinderGeometry( this.barrelRadius, this.barrelRadius, this.barrelLength, 6 );
      
      if( this.useSharedMaterials )
      {
         this.material.sphere = this.createBodyMaterial();
      }
      this.material.bands = createTexturedCylinderMaterial(
         this.geometry.bands,
         this.textures.concrete,
         this.textures.metal
      );
      this.material.endCap = createTexturedCylinderMaterial(
         this.geometry.endCap,
         this.textures.concrete,
         this.textures.scratchmarks
      );
      this.material.barrel = createTexturedCylinderMaterial(
         this.geometry.barrel,
         this.textures.concrete,
         this.textures.metal
      );
   };
   
   module.SimpleGunGenerator.prototype.createBodyMaterial = function()
   {
      return new CylinderMaterial({ map: this.textures.honeycomb });
   };
   
   module.SimpleGunGenerator.prototype.getTextureURLs = function()
   {
      return {
         honeycomb: 'https://img.nevyns-lab.com/textures/honeycomb-03-small.jpg',
         concrete: 'https://img.nevyns-lab.com/textures/concrete-02-small.jpg',
         metal: 'https://img.nevyns-lab.com/textures/metal-01.jpg',
         scratchmarks: 'https://img.nevyns-lab.com/textures/scratchmarks-03-small.jpg'
      };
   };
   
   //var CylinderMaterial = THREE.MeshBasicMaterial;
   var CylinderMaterial = THREE.MeshLambertMaterial;
   
   var createTexturedCylinderMaterial = function( geometry, barrelTex, chamberTex )
   {
      var materials = [];
      materials.push(new CylinderMaterial({ map: barrelTex }));
      materials.push(new CylinderMaterial({ map: chamberTex }));
      var l = geometry.faces.length;
      for( var i = 0; i < l; i++ )
      {
         if( geometry.faces[i].normal.y !== 0 )
         {
            // these are caps
            geometry.faces[i].materialIndex = 1;
         }
         else
         {
            // each segment has 2 faces
            geometry.faces[i].materialIndex = 0;//Math.floor(i * 3 / (radialSegments * 2));
         }
      }
      return materials;
   };
   
   module.SimpleGunGenerator.prototype.createModel = function()
   {
      var model = new module.GunModel();
      // Body
      model.parts.body = new THREE.Group();
      model.parts.body.scale.copy( this.bodyScale );
      var mat = this.material.sphere;
      if( !this.useSharedMaterials )
      {
         mat = this.createBodyMaterial();
      }
      model.parts.body.add( new THREE.Mesh( this.geometry.sphere, mat ) );
      //
      var mesh = new THREE.Mesh( this.geometry.bands, this.material.bands );
      mesh.rotation.z = Math.PI/2;
      model.parts.body.add( mesh );
      //
      mesh = new THREE.Mesh( this.geometry.bands, this.material.bands );
      mesh.rotation.x = Math.PI/2;
      model.parts.body.add( mesh );
      //
      var mesh = new THREE.Mesh( this.geometry.endCap, this.material.endCap );
      mesh.position.y = -this.bodyRadius;
      model.parts.body.add( mesh );
      // Barrel
      model.parts.barrel = new THREE.Group();
      mesh = new THREE.Mesh( this.geometry.barrel, this.material.barrel );
      model.parts.barrel.add( mesh );
      // Position parts
      var b = new THREE.Box3();
      b.setFromObject( model.parts.body );
      var n = b.max.y * 0.9;
      b.setFromObject( model.parts.barrel );
      model.parts.barrel.position.y = n - b.min.y;
      // set muzzle position
      model.muzzle.y = model.parts.barrel.position.y + b.max.y;
      model.object3D.add( model.parts.body, model.parts.barrel );
      return model;
   };


That class extends G3D.ModelGenerator, which you can look at in the js/g3d.js file. The main things I want to point out now are the properties that it gives you and what you can do with them and when you can do it.

This is the ModelGenerator constructor, which you can see is being called from the SimpleGunGenerator constructor:

Code:


   module.ModelGenerator = function()
   {
      this.positions = {};
      this.colors = {};
      this.textures = {};
      this.geometry = {};
      this.material = {};
   };


Those properties are there to store long term data that is re-used for all models generated. The geometry and material objects are not filled in automatically, but the others are based on some methods that you can implement in your generator class.

Code:


   /**
    * Returns an object containing named positions where each
    * position is specified by a 3 value array: x, y, z.
    *
    * Example: return { muzzle: [1, 0, 0] };
    */
   module.ModelGenerator.prototype.getPositions = function()
   {
      return {};
   };
   
   /**
    * Returns an object containing named colors where each
    * color is specified by a string. You can use these
    * items in the createModel method.
    *
    * Example: return { primary: '0xff0000' }
    */
   module.ModelGenerator.prototype.getColors = function()
   {
      return {};
   };
   
   /**
    * Returns an object containing named textures where each
    * texture is specified by its URL.
    *
    * Example: return { barrel: 'texture/metal.jpg' }
    */
   module.ModelGenerator.prototype.getTextureURLs = function()
   {
      return {};
   };


You only need to override the ones you want to use. The main one is getTextureURLs which will load the textures for you and keep them for all models generated.

These methods will be called in the init method, which is called by the user after they have set any properties on the generator that will effect the models generated. For example, you might have a property called maxRingRadius that you use to set the radius of the largest ring. So the user would do something like this:

Code:


var generator = new GunModels.RingGunGenerator();
generator.maxRingRradius = 5;
generator.init();
var model1 = generator.createModel();
// we can generate multiple models
var model2 = generator.createModel();


The init method should be overridden so that you can create the geometry and materials that you need. You must call the parent init method. So it will look like this:

Code:


   module.SimpleGunGenerator.prototype.init = function()
   {
      this.ModelGenerator.init.call( this );

      // TODO create geometry objects and store in this.geometry using a suitable key
      // example: this.geometry.barrel = new THREE.CylinderGeometry( 5, 2, 7 );

      // TODO create material objects for the geometry and store in this.material using a suitable key
      // example: this.material.barrel = new THREE.MeshLambertMaterial();
   };


The call to the parent init method is a bit strange, so I will explain it.

Code:


this.ModelGenerator.init.call( this );


When I create a sub-class, I put a reference to the parent classes prototype in there to make this a bit easier. Here is the creation of the SimpleGunGenerator prototype where this is done:

Code:


   module.SimpleGunGenerator.prototype = Object.create( G3D.ModelGenerator.prototype, {
      constructor: { value: module.SimpleGunGenerator, writable: false },
      ModelGenerator: { value: G3D.ModelGenerator.prototype, writable: false }
   } );


That allows us to call methods from the parent without calling our own overridden methods with the same name. The this.ModelGenerator part just retrieves the ModelGenerator prototype for us.

From there we reference the init function, which is fairly straight forward. However, then we reference something called call, which appears to be a function that we are passing this to. That's a bit weird, so let's look a bit closer at it.

Every function in Javascript has a few methods that do some funky things for special occasions, and this is one of the more useful ones. Basically, the problem is that if we just call the init function directly, then there is no this value and the function will most likely fail if it references this (actually, this will be ModelGenerator itself and not the object we want it to be). The call method allows you to execute a function and set the value of this. So it looks like you are executing the function and passing this as an argument, but you are not. The call method takes this and passes on any other parameters to the function.

Or in more succinct words: We do it that way because we have to do it that way!

You are free to accept either explanation.

The createModel method is where all the action happens. This is where you will be doing most of your work. You need to create THREE.Mesh objects using the geometry and materials created in the init method. Of course you can create other types of objects too, not just meshes, but most of them will be meshes.

This is what you need to get started. Add this code to the bottom of js/scattering-guns-gen.js.

Code:


   module.RingGunGenerator = function()
   {
      G3D.ModelGenerator.call( this );
      
      // TODO add properties that control the model generation process here
   };
   
   module.RingGunGenerator.prototype = Object.create( G3D.ModelGenerator.prototype, {
      constructor: { value: module.RingGunGenerator, writable: false },
      ModelGenerator: { value: G3D.ModelGenerator.prototype, writable: false }
   } );
   
   module.RingGunGenerator.prototype.init = function()
   {
      this.ModelGenerator.init.call( this );
      
      // TODO create geometry objects and store in this.geometry using a suitable key
      // example: this.geometry.barrel = new THREE.CylinderGeometry( 5, 2, 7 );

      // TODO create material objects for the geometry and store in this.material using a suitable key
      // example: this.material.barrel = new THREE.MeshLambertMaterial();
   };
   
   module.RingGunGenerator.prototype.getTextureURLs = function()
   {
      return {
         honeycomb: 'https://img.nevyns-lab.com/textures/honeycomb-03-small.jpg',
         concrete: 'https://img.nevyns-lab.com/textures/concrete-02-small.jpg',
         metal: 'https://img.nevyns-lab.com/textures/metal-01.jpg',
         scratchmarks: 'https://img.nevyns-lab.com/textures/scratchmarks-03-small.jpg'
      };
   };
   
   module.RingGunGenerator.prototype.createModel = function()
   {
      var model = new module.GunModel();
      
      // TODO create 3D objects
      
      // TODO set muzzle position
      // example: model.muzzle.y = 5;
      // TODO add your objects to the model
      // example: model.object3D.add( model.parts.body, model.parts.barrel );
      return model;
   };


Then alter it to do what you need it to. Note that you have to set the muzzle position as this will be used to set where the bullets start from.

Now you have to know how to use it.

In the js/scattering-guns.js class, at line 79, you will find this code:

Code:


   var SIMPLE_GENERATOR = new GunModels.SimpleGunGenerator();
   SIMPLE_GENERATOR.init();


Add a new one for your new generator like this:

Code:


   var RING_GENERATOR = new GunModels.RingGunGenerator();
   RING_GENERATOR.init();


Just below that is the DirectionalGun.install method. The first thing that does is generate a model.

Code:


   module.DirectionalGun.prototype.install = function( battery )
   {
      this._model = SIMPLE_GENERATOR.createModel();


Change SIMPLE_GENERATOR to RING_GENERATOR and it will use your new version. I will make that a bit easier to use shortly. This is not the way it is meant to be used, but it got me going when I was focused on other things.

That is probably confusing, but it will make a bit more sense as you start to use it, I hope.

.
Correct, I started putting the geometry numbers together for another gun. Initially I would replace your gun's elongated spherical body with the set of eleven toruses that would fit in that same volume of space. Thanks for the explicit directions.


Configuration error. Sorry, false alarm, never-mind. It turns out the Configuration error I mentioned and show above is occurring when I launch Firefox - not Scattering. It was an unfortunate misleading coincidence that I first noticed the error when opening Scattering. Again Scattering is not causing an error. This is also not my Git folder, but my usual working copy setup.
.

You don't want to know how much time I have wasted thinking I caused an error, but it was something else. It's just something you get use to as a developer.

.

Here's an image showing the RingGun body calcs. I'll modify it to agree with SimpleGun's body radius times var f. I can always beef up the rings by increasing the size of r2 compared to r1. This design easily lends itself to animation, say by oscillating between spherical and extended configurations between rounds. Or creating another compacted - flatter than the sphere -configuration to extend the range of motion. Or give each torus a range of motion with respect to its neighbors, allowing a stationary gun with swiveling rings that can change the firing direction.  

I started copy/pasting in scattering-gun-gen before finishing your code instructions. I did a block copy of lines 22 - 152, and added them as new lines 153 – 286. Next I did a Find/Replace, to change the 7 instances of Simple (as in SimpleGunGenerator) to Ring (resulting in RingGunGenerator). There's a lot to play with.
     // TODO add properties that control the model generation process here
Then that particular TODO is much easier. But then I’m perplexed by such things as this.useSharedMaterials. I'm extremely grateful having your instructions to fall back on, I'll need to read it and the code many times. Why is TorusBufferGeometry preferred?
.

The useSharedMaterials property is intended to control whether the Materials created in the init function should be used, or if new ones are created on each call to createModel. Whether you use this on a given Material is determined by whether you want to change the Material later. If you use a shared Material, then all models created will change in the same way, because they are sharing that Material. If you want to be able to change the Material properties for individual models, then you must not use shared Material objects. I would ignore that for now. It can be added in later when you have a working generator.

Note that for a given model generation, you might share some Materials and not others. You get to choose which parts of the model can be animated individually and what is shared. For example, in my simple gun model, I might allow the honeycomb section to be altered individually, but the barrel and the bars around the body would not be individually alterable. Therefore, I would not use shared Materials on the honeycomb section, but would for the others. This would allow the app to change the honeycomb Material in some way during runtime. It might make it change color when the gun is fired, for example.

Try to use math to determine the radii and thickness of the tubes, rather than set values. Let the user (of the class, not the app) set the min and max, and let the math calculate the rest. But get it working anyway you can first, then tailor it to make it more usable and friendly. After a while, you just start to think about it in math first, but you need to understand what you are working with for that to be effective. Work at whatever pace suits you. I'd prefer a badly programmed but good model than a well programmed but bad model.

I've been working on a new way to define and use textures. The textures I am getting have many images that make up the texture, so I wanted a way to declare those without having to do it on a per generator basis. So I have created a TexturePack class that contains the URLs to the images and they will be loaded when appropriate (only when used, and only once). The TexturePack can also create the Material objects, and that allows you to choose what type of Material you want. Only the relevant images in the texture will be used based on what the Material can accept. All of this happens automatically based on some properties that you can set to control it. This will make it very easy to switch between rendering types, as well as being much easier to use textures.

.
I just Pushed changes to scattering-guns and scattering-gun-gen. Copying SimpleGun and renaming it RingGun, and putting RingGun online - or at least there were no errors. Pushing was a bit of ordeal. After trying for twenty minutes and three password entries, bitBucket/sourcetree would not allow the Push. So I tried Fork instead. I entered six bitBucket Atlassian password requests in quick succession, what must be designed to tell the difference between human and machine. After a while it was over. Fork showed the last Push at the top of the Commit list. I think it worked. After I regain my senses, I'll begin playing with RingGun.
.

I got an email stating that you had pushed a commit, so it definitely made it.

Have you enabled 2-factor authentication on Bitbucket?

Maybe look into using SSH instead of HTTPS and create an SSH Key for yourself and add it to Bitbucket and SourceTree. It is fairly easy to do. Instructions are available on the Bitbucket site, I think. The hardest part is creating the key, which is an RSA Id. You may need OpenSSL to create that. It is free but confusing. For this, it shouldn't be too bad, but a google search will help you.

.
Uncle, uncle, uncle.

I've never heard of 2-factor authentication on Bitbucket.

The hardest part is creating the key

https://confluence.atlassian.com/bitbucketserver062/creating-ssh-keys-969536730.html ; that's some relief, I followed the instructions in this link and have created an .ssh directory and rsa key. I guess it's safe to show this 'randomart image'.

Next I need to 2. enable the use of ssh keys, then 3. install the key.
https://confluence.atlassian.com/bitbucketserver062/enabling-ssh-access-to-git-repositories-in-bitbucket-server-969537442.html

Thanks for the suggestions, they keep me going. At present, going mainly alternates between confusion and procrastination, but I'm muddling through. Just don't be surprised if you receive an urgent PM from me begging for assistance.
.

Don't worry about 2FA. I'm using that at work, and thought my personal account was too, but it isn't. 2FA creates a few other problems. They can be gotten around, but it won't fix your problem.

I tried using my RSA Id in Fork, but I don't think it used it. It still asked me for a password all the time. I prefer SourceTree.

Sorry about the confusion. I'm trying to document the classes to help you understand what they are for and how to use them. Most of them you won't have to use, but still may need to understand how it fits into the larger system. I'll see if I can write some info about the architecture to give you a more global picture of how it all fits together. I'll put that into the readme file for the project.

I added a few more texture packs last night. I have also introduced a couple of things to the Model class to allow actions and animations. If you get the latest, you will see the animators in action. The honeycomb section of the gun now pulses between 2 colors. I added that to your RingGunGenerator, since that is what is being used. I'll move it over to SimpleGunGenerator to avoid stepping on your toes.

I probably should explain what actions and animators are.

Animators

At the basic level, an animator is a function that is called every frame, and is given the current time values: elapsedTime and delta; in an object. The elapsedTime value is the total time, in seconds, that the application has been running (although time does get scaled and I have to work that out). The delta value is the time since the last frame, also in seconds.

The Generator can add animators to the Model in the createModel method. Such animators will be run for the lifetime of the model. It is possible to add and remove animators during execution.

Animator functions will be executed as if they were methods of the Model class. So they can refer to the Model using the this keyword, and access everything in it.

Actions

An action is a function that can be used by the owner of the Model. Note that it is up to the owner to use it, it will do nothing automatically. The Model class provides an execute method that takes the name of the action to execute as its argument. The action is executed as if it is a method of the Model class, so it can access the data in the Model using this.

For our gun models, we could implement a fire action that the owner calls when it fires the gun. The fire action could create and add an animator to the Model and after a certain time, or other threshold, it will remove the animator. It allows short term animations to be used based on external events.

I just made some commits using Fork, and it has 2 fields for text when you commit. SourceTree only has 1. One field has the placeholder text 'Enter commit subject' and the other has 'Commit description'. It turns out that the UI will only show the 'Enter commit subject' text in the graph, which is useless. I suggest you don't use the 'Commit description' and only use the 'Enter commit subject' text field. That will keep it consistent with SourceTree.

.
I briefly looked at the latest and didn't see any animation.

SSH Keys. SourceTree wouldn’t let me load/recognize the new ssh key I made yesterday, so I used SourceTree’s PuTTY key generator to make a new RSA key. I made “copies” of the public and private keys.

I logged into BitBucket, went to settings: SSH keys, and pressed ADD KEY. I labeled the key and pasted the public key into the designated area.

To see if anything changed, I did a Fetch (without the terminal). I received the usual output:

Code:

git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks fetch origin
fatal: ArgumentException encountered.
   An item with the same key has already been added.
.
.
.
fatal: ArgumentException encountered.
   An item with the same key has already been added.
remote: Invalid username or password
fatal: Authentication failed for 'https://McBride_Robert@bitbucket.org/Nevyn2k/scattering.git/'
Completed with errors, see above.

So I’m still in limbo. What next? Now that I’ve got the new ssh keys installed how do I implement them and restore my good graces with SourceTree? I believe I need to clone the .git repository next. And throw out the one I'm using? Does that sound correct?

P.S. Interesting, I see my repositories at BitBucket are gone. I guess I must clone the .git repo. That is, if I can find it. I did a search on scattering that came up empty. I'll look for the BitBucket e-mail invite next.

I cloned scattering.git using SourceTree, and SourceTree denied the ssh key. Would I like to try again? I entered the public and private copies of the keys I'd mentioned earlier. SourceTree accepted the keys, and URL . Scattering appeared in a second tab.

Please excuse the play-by-play. I think I'm good. I'll let you know if I see any indications otherwise.
.

I moved the animator over to the SimpleGunGenerator class, so you need to use that to see it.

.
The color change animation makes a big difference.

////////\\\\\\\\////////\\\\\\\\////////\\\\\\\\


I thought I succeeded in installing ssh keys yesterday, but my latest SourceTree Fetch results show otherwise. The direct Fetch request results are on the left and the terminal Fetch request output is on the right. I deleted all other repository tracking on SourceTree except the latest scattering.

When I launch Fork, it does an auto Fetch. I see more than a dozen new commits you've made since yesterday. Why did the Fork Fetch work? Is it still connected to the https scattering repo? I’m afraid to Pull anything at this time.

What next? SourceTree recommends creating another ssh key set or reloading the current one. If/when I create another PuTTY generated ssh key set, do I need to go into BitBucket to load the new public key or does sourceTree do that? I suppose I also need to load the public and private keys in Fork.

I'm much more comfortable with ssh Key addition/actions. Any ideas?

BitBucket confirmation. Failed to mention I received a bitBucket e-mail notification 17 hours ago, including the public key. I suppose I might forward that to you?

Dang, I see from the terminal output I allowed SourceTree to create a new repo location in my Documents folder instead of the Git folder. Does that make a difference?
.

IF you create a new key, then you absolutely need to tell the BitBucket website about it. You shouldn't have to create a new one unless there is a problem with the existing one.

The location of the repo doesn't really matter, but you can just clone again where you want it.

Sounds like you should just use Fork then. If that actually works, then use it. The main thing I didn't like about fork was the interface layout, but SourceTree has now gone and done the same layout. Fork doesn't seem to have many options around authentication. It doesn't seem to save passwords.

Make sure that you are using the correct BitBucket account. Only 1 has access to my repo, so if you happen to login as a different account, it will fail.

In SourceTree, you could try removing all of the saved passwords (Tools->Options->Authentication->Git Saved Passwords) and enter them in again when it prompts you. Maybe some of them are bad. It seems to save about 5 variations of them for some reason.

.

From https://www.xkcd.com/627/

Thanks for the continued support and direction, I’m sure my insecurities have tried your patience. Over the last few days I’ve reviewed many git related videos and instructions, and impressed the heck out of my local support team. So much so they shared their secret logic flow diagram which I’ve included above. I acknowledge that switching to ssh keys is a big improvement. Re-entering my public and private keys when I open SourceTree is a small price to pay for an actual working git/bitbuckt interface.


Here's what 'the range' currently looks like - Super high tech. The solar panels making up the floor and ceiling would also make perfect detectors.

After my two-day break, I'm back to work. I see you’ve made forty or so commits. That’s a lot of changes. The Scattering program now has about 22 support files. Please consider fleshing out the read me file or some other document showing the program flow as in the diagram above.
.

I really like that hexagon texture. There is another one that will work well, but I can't get it yet. The solar cells would definitely work as detectors, but it was all I had to match the hexagons and give it that scientific, futuristic look. I have my eye on some sci-fi panels that might be able to work as the floor and ceiling so that I can free up the solar-cells for the detectors.

While I have made a lot of commits over the last few days, it is really just small parts of a larger piece. I have extracted parts out into their own JS files to keep the file maintainable. I get sick of scrolling from the bottom to the top and back again in a file that is 1000 lines long. It seems I spend most of my time looking for things instead of working on them.

I have been fleshing out the way models are created and trying to find a nice way to do it all. I'm working on a BatteryGenerator that will make use of the spherical point algorithms to place the guns. This causes changes in the RangeGenerators and GunGenerators, which sit on either side of the BatteryGenerator.

I have introduced another level of abstraction around textures. The first was the TexturePack, which is designed to store related textures that work together to create a single Material. Now I have introduced the TextureDef, which is used to store related TexturePacks based on their resolution. So a single TextureDef might contain 3 TexturePacks, where the packs are 512, 1024 and 2048 in resolution. You only use one of those packs though, not all of them. Well, you could use any number of them if that is what you want, but in general they will only be used to retrieve a single Material at a given resolution. This allows the app, or a model, to decide what resolution it wants to use and the appropriate textures will be applied to the models. While everything looks great with hi-def textures, they take time to download. A single TexturePack at 2048 res can easily require above 10MB, and that's just a single Material.

If you look at the js/scaterring-range-gen.js file, and find the SphericalRangeGenerator, then find the getTextureDefs method of that class, you will see a lot of commented out lines. You can change the textures being used by uncommenting out what you want to use, and commenting out the existing version of it. For example, the main one I change to test the textures is the sphere material. It is currently using the hexagons for the sphere texture, but you could comment that out and uncomment one of the other sphere ones to see what they look like. Some textures don't work as good when applied as a single texture across the complete sphere. They might require wrapping the texture so that it is used many times across the sphere. You can play with those settings in the SphericalRangeGenerator constructor where it declares a sphere object that has these settings.

I must admit that I have been having too much fun playing with textures and models, and not spending enough time on the actual purpose of the app. I'll get to that. Eventually. I swear.

I will see what I can do about an architecture diagram, or at least a decent description. I might be able to create a process flow diagram for some of the processes, but not all. Things change too quick for that, but the way everything is created should be feasible. Showing who is responsible for what.

.

Nevyn wrote. Try to use math to determine the radii and thickness of the tubes, rather than set values. Let the user (of the class, not the app) set the min and max, and let the math calculate the rest. But get it working anyway you can first, ...

Using the any way possible rule, we’ve got a set of Ring guns. I’ll try to algorithimize (?) simplify their construction next. It uses the same shared material as the simple gun but they aren't color animated yet. I’m surprised the muzzle is essential, so I’ll need to change the muzzle's shape.

I'll point out a small error. The top view (actually from the side (+/-x or +/-z)) shows that photons emitted by the far gun – toward the viewer - have a small random up/down or side to side component in their forward velocities - that's good. The second image, (a top or bottom view (+/-y)) shows all the photons approaching the viewer are in a horizontal plane passing through zero. Either the x or z random component is gone and needs to be included.

I reviewed all the sphere mats, I'd like to try and make some small changes to a few. I noticed the outdoor range beside a tree just before I Pushed my RingGun changes. Quite nice.

I see I overwrote at least one of your latest changes - probably the tree. I'll try putting them back in without deleting my latest.
.

.

Where would I be but for the screw-ups? I realized my latest changes had deleted the wonderful outdoor range. So I attempted to revert my push and remove the specific hunks deleting your latest changes from my commit staging area. Well that made a mess, uncommitted changes and the creation of a diff doc, scattering-range-gen.js.rej.

Help! Once again your assistance is requested. What's the graceful out here? How should I remove my latest uncommitted changes? Can I delete the diff doc?
.

It looks like you have reverted the changes correctly. It still thinks that scattering-range-gen.js needs to remove my changes though. Do you have any required changes in that file? If not, then just discard your changes, then you can delete that .js.rej file. Definitely do not commit that .rej file, it is an artifact of Fork when it finds a conflict and needs you to merge the changes together manually.

My guess is that you had started to make changes, then pulled some of my changes (without selecting the rebase options on pull), so it assumed that your changes overruled my changes.

Here is how it should have happened:

You do some work.
You may commit your changes (but not push them).
You do a fetch and see that there are new commits.
You do a pull with rebase.
You push your changes.

The pull with rebase option tells the app to pull those changes, and then alter your changes so that they sit on top of those that have just been pulled. Then you are safe to push your changes. Effectively, it inserts the pulled changes into your changes, if it can. There-by making your file the same as if you had pulled those changes before you started working on it.

I sometimes forget to fetch before pushing too, but it's starting to become a habit.

That error in the gun accuracy is not an error, it is randomness. The accuracy setting for every gun is randomized between 0 and 1. I guess you got lucky and the gun was very accurate. The accuracy is applied using spherical coordinates, and both the inclination and azimuth are randomized individually.

Then again, maybe there is an error. Since it uses spherical coords, there are limits to the angles in those coords. The code is not checking for angles over 360° and then reducing them to be 0° <= a < 360°. I'm not sure if that is even required, because 361° works out to the same position as 1° anyway.

If that is the case, then certain gun directions will cause the error, and others won't. The Y dimension is susceptible. So is either the X or Z, but only one of them and I can't remember which one. I think it may be the Z dimension. See if you can see a pattern to the error.

I like the rings. Don't like the barrel on it though. You don't need a barrel, or a muzzle, but you do need a muzzle position. To be clear, you don't need anything in your model that is a muzzle, but you do need to specify the position of the muzzle because that is where the bullets starts from and then move in the gun direction. For a ring based gun, I would like the muzzle position to be at the back so that the bullets travel through the rings and out the front. But I have just realised that won't work because the muzzle position is used to determine the direction of the model. It is assumed to be at the front of the gun. I can fix that.

.
Nevyn wrote.

I taped it up alongside my new tech support logic flow diagram.


Here’s a glimpse of the Norwegian forest scene, along with the latest RingGun image - Honey Bee Hives. I was sure I saw a collision between a particle and the target, but was too slow to capture it. The animation color changes, extra wrapping and additional segments give the appearance of gold or Snakeskin. I replaced the fixed individual ring locations with variables and distance formulas. One can now easily mess with the ring-gun’s axial and radial numbers such that they may, for example, overlap. Above, the axial length is ‘two’; in the image below, we see the center with the overlapped ends of six each eight axial units long ring-guns. I can imagine creating waveform actions by expanding/contracting the individual rings accordingly. Or pulse the color animation waveforms at different rates. The rings are versatile and provocative.

.

I have a WaveAnimator class that is doing the pulsing of colors. It has an offset property that I want to test on your ring gun, since it has the individual rings to do so. I want to attach an animator to each ring, so they will need their own Material (not shared), and then set the animator offset so that the rings pulse from back to front. I didn't want to complicate the code you are working with, though, so I haven't done it yet.

I just pushed some changes and one of them changes your ring gun code. It produces the same results, but I wanted to show you how to create and place the meshes in a for loop. I didn't want to step on your toes, but I thought this was worth pointing out. Whenever you have multiple things that are basically the same, you should use a loop. It can be tricky figuring out how to do some things in a loop, but there is always some way to do it.

As an exercise, you can do the same thing when creating the geometry. The materials should be even easier. You should be able to create the geometry and material in the same for loop (not the same loop creating the meshes, but a new loop in the init method).

If you can get the geometry and material being created in a loop, then try to refactor it so that you can vary the number of rings. A property on the generator, such as this.ringCount, could be used to control it and the code spaces them appropriately. This may mean that the rings overlap, but it is up to the user of the generator to give it meaningful values.

Sorry, I couldn't help myself. I implemented a pulse-wave system on the Ring Gun.

An image doesn't do it justice, but here it is:

.

Like Dr. Who’s Tardis; every time I look, we’re somewhere else. Here we are surrounding by blue slime.  The target zone has a little glare – but look, we have collisions. Many collisions. Note the red photon approaching the bottom center of the image or the photon at top left corner - well outside the photon streams.

Progress, and great directions Nevyn.

I for-looped the ring gun’s geometry and material, but not before noticing that var factors = [ 0.9, 1 ] works like magic. And var geom = this.geometry['cRingPlus' + (i+1)]; turns a name into an indexed array. I'd wanted to turn the long list of geometry parts into a loop but couldn’t see how. Seeing your solution, wow, such ideas had never occurred to me.

As you suggested this.ringCount is now a variable. This enables the 25 rings in each ring gun shown - too many to see in this image. The color animation wave pulse is enhanced.

I still owe you a gun or two.
.

I'm building a texture library, so I keep changing them to see how they look. Some work better than others. For example, I really like the scifi panels and flooring, but they hide the bullets too much. I have to remind myself that it is no good if it looks great, but we can't see the main point to the app.

Using loops can be difficult until you work through a few and get a feel for how to make them work the way you want them to. It usually means creating some data structure(s) that allows you to retrieve the data you want in a looping fashion. Other times you just need to work out how to use the loop to perform some math. Try to figure out how to use the incremental variable to your advantage. Also, the incremental variable does not need to increment by 1. You can increment by whatever value you want, even negative values.

The statement: this.geometry['cRingPlus' + (i+1)]; doesn't turn it into an indexed array, it is just treating an object as if it were an array. You see, in Javascript, all objects, even arrays themselves, are just maps of keys to values. An array just happens to use integers as keys (although they are actually converted into strings internally). You can actually have what is called a Sparse Array in JS just by only using certain indexes. They don't need to start at 0 and increase by 1. So this is valid:

Code:


var array = [];
array[10] = 'Ten';
array[1001] = 'Big number';


So we can references items in an object like it is an array. Sometimes, we actually have to do that because the keys are not valid JS identifiers.

Code:


var ob = {
  one: 'One',
  'invalid-identifier': 'still works'
};
// we can reference the first as:
console.log( 'one: ' + ob.one );
// or we could reference it like this:
console.log( 'one: ' + ob['one'] );
// but we can't reference the second like this:
console.log( 'invalid-reference: ' + ob.invalid-reference );
// JS will interpret that as ob.invalid minus reference
// but we can still reference it like this:
console.log( 'invalid-reference: ' + ob['invalid-reference'] );


So in this case, I was using that to build the keys used in the materials object, since I can treat them as strings and not identifiers.

Tricks of the Trade.

.
I'm not complaining; I like textures, I'd be fine with a random default setting for the start. I can't think of a better opportunity to learn about textures, materials, etc.

By the way, I came across this instruction.

Code:


this.ModelGenerator.init.call( this );
 // TODO create geometry objects and store in this.geometry using a suitable key
 // example: this.geometry.barrel = new THREE.CylinderGeometry( 5, 2, 7 );
 //this.geometry.sphere = new THREE.SphereGeometry( this.bodyRadius, 32, 32 );


Sometimes things click, most times not so much. Your last post and this request for a suitable key sound related. It still doesn't make sense to me. I'm afraid I might relegate this problem to my toDo list. Like the possible random bullet velocity/direction problem - for that I suppose I should start looking in scatter.js?

Would you care to expand your request/statement a bit?

Please feel free to task or redirect me as you will. I don't ever consider your changes and additions as stepping on my toes.
.

You're already doing that. This is from RingGunGenerator.init:

Code:


...
this.geometry.centerRing = new THREE.TorusBufferGeometry( cRingRadius, cRingTubeRadius, tubes, radials, Math.PI * 2 );
this.material.centerRing = this.createBodyMaterial();
...


It isn't related to my last post, where I was just discussing programming techniques, nothing specific about this project. I just wanted to show how to use strings to retrieve values from objects because it is so useful.

Speaking of this.geometry and this.material, there are some objects being created in RingGunGenerator that are not needed. They were from the original SimpleGunGenerator. Try to identify them and remove them.

The bullet accuracy problem is a bit tricky because it revolves around spherical coordinates. If you want to have a look, it is in scattering-gun.js, lines 131 to 138 (at the moment).

Really cool stuff to be building into an app! Keep going, guys.

.
Hey Jared, thanks. Nevyn is a wizard. I’m hoping he'll provide some physical details to account for all the collisions. Separate subject, can’t help but mention I saw you and Ollie at Cutting Through the Fog, exchanging recent theoretical claims concerning planetary conjunctions and pyramid power; and Miles’ response. HuAhh.

Random trajectory testing. I used scattering.html lines 253-255 camera.positions.x, y or z to set the app viewpoint. Comment out two of the three component positions, leaving only the x, y or z ( include + or - ) distance in order to conveniently view each gun’s boresight direction. The misses are clear enough – there’s no need to turn off collisions.

scattering-guns.js lines 135-143. Comments have been added to the code.  
With s.inclination only (s.azimuth commented out) all viewpoints show a random component – sometimes just a small amount, yet nevertheless always present, in a single plane passing through the perfect bullet firing direction.

With s.azimuth alone (s.inclination commented out), all viewpoints except the top and bottom show a random contribution. There are no random contributions to the +/-y top and bottom gun firing trajectories. Perfect bore shots every time.

In summary s.azimuth is not working for +/-y shots. At present I have no idea how to fix it, especially given the fact that there will likely be new configurations soon.  
.

I fixed that accuracy issue. It was caused by the limitations of the spherical coordinate system, where the inclination is a value between 0 and PI. The azimuth can be wrapped, it doesn't matter if we use 720° or -10°. The inclination does care though. So when the gun was on the Y Axis, it could not apply the accuracy changes to the inclination correctly.

To get around that, I use a set direction that I know is safe (so not near the zero points in either inclination or azimuth) and calculate the accuracy changes on that. I convert that back into a vector and then calculate the required axis and rotation to put that known direction (with slight changes) into the actual direction of the gun.

A lesson in knowing your tools. If you ignore the limitations of your math, it will give you invalid results. Math doesn't care about correct or incorrect, right or wrong, good or evil. It only calculates. If you give it bad data, it will happily give you bad results.

.

Lessons learned and appreciated. I briefly considered using a 'good angle', for when the gun is on the +/-y axis. I believe the same thing is necessary when using Euler angles, but I've never looked at that problem and am not familiar with any details. This experience is a good example to draw from.

Forgive me for pointing out - good thing we aren't using real beam guns yet, the +X gun is firing backwards. I'd race you to fix it, but am afraid I'd cause an accident.
.

Fixed that. It is caused by trying to find the axis to rotate around, but the vectors are in opposite directions.

I improved the collision detection system. It still looks like they collide too soon, but it is really just a visual discrepancy between the size of the particles bphoton, and the bullets which are sized in the shader.