Algodoo

This scene is awesome.

I never made any engines with Algodoo, but I am still very impressed by this amazing tool that you've made, and I'm sure that it will be useful to others who do make a lot of engines. Nice work!

Is this dynamometer turning the engine? If that's the case, then either you got things backwards or you have some explaining to do.

I guess I have some explaining. But yes, the concept is basically backwards of what you would expect, but in Algodoo, with engines being much rougher and with sudden spikes of torque instead of something more consistent, measuring by brake is much harder and really imprecise. What we do in Algodoo is:

totImp3(2)*sim.frequency (i'll call it _force) shows the rotational force being made by the axle. Let's say that the axle is a brake (By using a motor we can also find out about engine brake force, but that's for later on). If you use a crank and exert, say, 1 N at 1 meter, _force will output 1. Now, if you make that axle a motor, opposed to the direction of the crank force, the crank will still make 1 Nm and _force will still be 1. So, by the conventional approach, if you brake an engine with 100 Nm and it goes to 3000 RPM, you have the torque at a given speed.

But in Algodoo, if you make the axle run at 3000 RPM, the engine will make a certain force to try and spin it faster than that, and that will be the power at a given speed. If the engine was off and without any friction/compression, it would generate 0 Nm, therefore the reading on the dyno is 0. If the engine is off and has friction, then the dyno should report negative values (i think this one doesn't but the Dyno2 did, and it was handy). And if the engine is running and at full tilt, it will try to spin the axle faster, and _force will report it.

Now that we have 5K/7K RPM engines it might be feasible to make a brake dyno. But before, when an engine gave huge torque (around 3000/5000 Nm) to compensate the RPMs for the same amount of HP than a real one, the torque would be pulsating so much that the engine fluctuated between like 500 and 900 RPM for a given brake.



Anyways: The main idea of this dyno is to cut entirely the lag generated by smoothing on graphs. The graph that is printed out at the end only has the same amount of datapoints that are calculated by averaging measurements on the test, and that allows for using smoothing 3.0 which smooths everything maybe excessively with no performance impact. plus the scripts are as modular as possible so that the majority of the code is ran only at a given time, for example the display driver is ran every time that one full measurement is taken (around 1 second) and the output script is run for as long as printing the graph takes, which is usually 30 steps

Bottom line is, if it's a useful tool for engine design, then that's a good thing. I'm impressed by the whole design. The graphs look good even without the smoothing. totImp3(2)*sim.frequency is torque, which you probably already know, even though you call it _force.

Yes, but since i made the analogy of the force at 1 meter, i just called it _force. Don't read into it

Until about a year I thought that scene.my's, lasers, and all that kind of stuff was horrible for sim.time and created a bunch of lag, so I started doing everything with keys.isDown and a bunch of postStep stuff. Now I found out that using those is much better as long as less steps have to run scripts. A laser as a key trigger (with onHitByLaser) is much better than a keys.isDown on postStep, and modularizing scripts and running them at, say, 10 steps per second is much better than just using postStep or update and running them 60/120/240 times/s. I guess you know that, but for anyone who comes around, it's good advice.

Regarding "Now I found out that using those is much better as long as less steps have to run scripts.", how did you measure that?

I usually don't think about lag or performance until I run into problems. What's the best way to do something every nth time? (maybe sim.tick % n == 0 ? {doSomething}:{};)

I measured it with the "-" and "*" key. Those give you frametimes and how much time is needed to process each thing. While a complex script running in postStep would give me about 20-50% processing time, I found out that using those old boxes that flickered between transparent and opaque so that a laser could pass through them were perfect for the job (basically: the boxes have refractiveIndex 1 and change color from transparent to black via onHitByLaser. Stacking many of them one after the other give sort of a binary effect. After the last box would go the object with the script, and the script would be in onHitByLaser instead of postStep. hence the 1 step every x steps).
I also tried a counter on postStep (if less than X add 1, if X or higher run _script and X = 0) and it was more or less the same, but curiously it gave me slightly more overhead (using the "Sleep" percentage under the "-" key, since obviously the laser and boxes would use the draw process, so I needed something that would add up both.). While the laser gave me 70% sleep, the postStep script gave about 66-67% avg.

I haven't tried sim.tick but maybe it works better

Thanks. Sometimes I set laser maxRays = 1 which is similar to setting refractiveIndex = 1. I had forgotten about the "-" and "*" key and couldn't find it on the forum when I went to look for it. I searched "hotkey", "ctrl", "special", "performance"... all to no avail. At any rate I should note that it's the numeric keypad "*" and "-" keys.

well you can't just set maxRays to 1 in this case because the laser has to pass through the transparent boxes. so the ray that comes out of the box would be the 3rd one. What I do is limit maxRays to, say, 10 or 15 as needed just in case

Now I see that. Thanks.

nice. is this phunlet safe?

yep

sorry s_noonan

Only he made the algobox this scene saved to log the investigation so
you s_noonan

That's clear as mud.