Constructing a Mathis' Charge Flow Chip?

Thought it might be possible to construct a virtual Mathis' Charge-Flow Chip

What does that mean?

Sorry for the late reply Nevyn. I think I had a few beers when I posted this one.

The idea was basically how to create "chips" that demonstrate the charge flow (spin mechanics). I think I was thinking in terms of Graphene. How to create a chip that demonstrably demonstrates the Mathis' charge flow opposed to traditional QTM explanations.

I think that since all current chips demonstrate the charge field already, this is kind of a strange task. I've been reading up on so-called "quantum" computers, which are of course not quantum at all, and they also demonstrate the charge field.

But both types are terribly inefficient, of course, since they're still conflating the electron with the photon.

What we need are good animations for the basic electrical components (resister, capacitor, inductor, power sources, transistors, etc). A chip is just a very small circuit. You can make them out of the normal components you are used to seeing, but they won't work as well and cost a lot more in money, space and power.

Agreed. I'm just not that far along with my technique (in Maya) to be able to diagram this, yet. Constantly researching how to make this work better.

I really need to learn some programming (scripting, anyway) so that I can develop a mechanism similar to yours, and just enter the spin numbers to make it work, instead of the tedious animation technique I've been using. It takes too long to make changes. The model becomes too complex too quickly, beyond the first four spins.

I believe Maya uses Python for scripting. I have never done any Python programming but it is a scripting language so it should be fairly simple to get started in. The complexity is in knowing what objects you can use and how to use them which the documentation for Maya scripting should provide.

I'm not sure how the scripts are applied though. Can you apply a given script to a certain object or does the script need to find the object? The former makes more sense to me because you could then write a 'rotate spin level' script and apply it to each spin level. The script would assume some sort of structure and make the necessary changes to the variables on each invocation of the script.

For example, suppose we took my spin level structure and wrote a script for it.

Structure:

Spin Level (group)
- Rotation (group)
 - Translation (group)
  - target (object or group)

Script:

I assume the script will be given the object to be manipulated which would be the Spin Level group. I also assume that you can specify values for variables used by the script (may be called parameters or arguments to the script). There must also be some global variables that give you things like the current frame number, time values (elapsed time and delta time - time since last frame), etc.

RotateSpinLevel( level, tangentialVelocity )
{
 var rot = level.getChild( 'Rotation' );
 rot.rotation.a = // calculate angle to rotate based on tangentialVelocity and delta time
 rot.updateMatrix(); // this may happen automatically
}

That is not Python syntax, more like Javascript (but not quite that either) but it gives you a rough idea of how it would look.

If there are different types of scripts, such that some are executed on every frame and others are only executed at the start or on some specified frame number, then you could even create a script that creates the spin levels for you.

CreateSpinLevel( axis, innerLevel )
{
 var level = new Group(); // not sure how you would create a node
 var rot = new Group();
 var trans = new Group();
 // setup spin values
 trans.position = // calc translation vector based on axis and radius of innerLevel
 // create scene graph structure
 trans.addChild( innerLevel );
 rot.addChild( trans );
 level.addChild( rot );
 return level;
}

That's the basics of it. A lot simpler than altering pivot points and figuring out timing values, etc.

The scripts are just another way to access the values you are manipulating in the user interface (such as position, rotation and scale vectors). Anything you can do in the interface can be done in a script. These modeling tools are written with that in mind.

I suggest you give it a go when you have some spare time (and it will take a lot of time to get started) but a lot of it will just be you figuring out how to do what you already do in the interface. Once you have that down, you should find scripting fairly easy, I imagine.

Although, you will also find that you might need to create different kinds of scene graph hierarchies that work better with scripts. You will have to think about what you want to manipulate in the script and then create the hierarchy that allows that to happen easily. That comes with experience though, so don't let it stop you from starting.

That's great stuff, Nevyn, and I appreciate you taking the time. I'll plug away on it and see what works and doesn't, and learning PyMEL scripting can only benefit me all the way around. I do have some buddies in CGI that may be able to help, as well, over on CGTalk.com. A few hundred of 'em. Though of course, they tend to deride my physics but light-heartedly for the most part. Arguments about photons are constant, since Maya (mental ray) calculates "data photons" for its lighting system and global illumination.

But I digress. I'll see what I can come up with and if we can get it to work in a similar fashion to your setup (which is amazing!) it could be very helpful in moving forward diagramming electrical systems and effects, down the road.

Jared Magneson wrote:Agreed. I'm just not that far along with my technique (in Maya) to be able to diagram this, yet. Constantly researching how to make this work better.

I really need to learn some programming (scripting, anyway) so that I can develop a mechanism similar to yours, and just enter the spin numbers to make it work, instead of the tedious animation technique I've been using. It takes too long to make changes. The model becomes too complex too quickly, beyond the first four spins.

The simplest way to go is to build an AI unit and tell the damn thing to figure out how to do the animations or simulations we need.

I tried that previously back in 1997. The AI became self-aware, tried to nuke the Russians so they'd take out its targets here, but then realized nukes weren't real and short-circuited promptly. Skynet, schmynet.

Next time, program the AI to build an AI that won't short out.