Sjack Abeling Gravity Wheel and the Worlds first Weight Power Plant

[mondrasek]

But, see, Stefan suggested to use double pin joint instead of rigid joint and that also constrains the three degrees of freedom while fixing the error.

Think through the process of translating the object held by two pins.  You calculate the X and Y positional shift of one pin and its object.  And then the free rotation of the object around that pin.  But wait...  There is a second pin so there cannot be any free rotation.  Calculate the X and Y positional shift of the second pin and align the "rotation" around the first pin.  No extra error was induced.

Yes the two pins also constrain all three axis of freedom.  But it does it with several independant equations, not two interdependant ones (I think).

M.

[mindsweeper]

Talking about strange behaviour...  Why is this going the wrong side???

The mass of poly 2 was incorrect, I set it to 6 and it worked as it should.

[Cherryman]

Tnx, i repaired it myself also.

Here you can see the flying path of the ball...  I think this is the force we seek......

"may the force be with you" 

[hartiberlin]

Talking about strange behaviour...  Why is this going the wrong side???


* KAD Wip.wm2d (50.92 KB - downloaded 3 times.)
* KAD Wip2.wm2d (28.66 KB - downloaded 2 times.)

Because you made the see-saw bar about 6.4 tons of weight.

Just change it to a real value of 1 to 10 Kg and it works
the way it should.

Watch out for the weights you are applying.
If you use a different tool other than WM2D to design your polygons and
things you have to edit out the weight in WM2D.

Hope this helps.

Regards, Stefan.

[mrsean2k]

@mondrasek,

How do you explain the rigid joint problem? Also, do you think parallel processing would improve matters and maybe somehow the object-oriented programming would be a palliative solution? Sorry to get into these software issues and detract from the discussion at hand but do you know what language was used to program this and any other details you've come across? Just curious.

Excuse me for stepping in, but:

Object orientation will help only in that it provides a language in which concepts can be expressed and state capture in a relatively easy to maintain way. For some projects it is an excellent fit, reducing the apparent complexity and consequently the possibility that bugs are introduced. Although most implementations of OO incur an overhead when it comes to execution, this is usually more than made up for by the fact that better algorithms can be more elegantly expressed and developed. A better algorithm trumps shaving a few cycles off 99 times out of 100.

So there is nothing that makes OO intrinsically more accurate as a candidate for making simulations more accurate, other than the fact it can foster some good development practices compared to older methods.

Parallel processing is a bit of the same. Parallel processing improves accuracy only as a result of being able to execute the same algorithm more efficiently. In terms of your simulation application, you have the opportunity to decrease the interval and increase the number of iterations performed in a given time period, but other than that, no intrinsic advantage over a beefier single processor.

The nature of the problem really stems from the fact that computation is discrete and reality is continuous. It doesn't matter how brief the tick or short the distance you use when calculating the next frame of the simulation, it's a coarse approximation of what actually happens. The current speculation is that the ticks and lengths the universe operate on, the Planck Time and Planck Length, are 1.3546 * 10^-43 sec and 4.0610 * 10^-35 m respectively. Comparing the resolution of simulations to those two figures is like comparing the results of a commercial colour printer to a daisywheel, and that's vastly understating the case.

That's not to say that the simulation can't be good enough for your purposes, but unless the effect is pronounced and easily replicated, you won't know if it's a breakthrough or a rounding error.