Question concerning time-based Motion of legs and Physics

i might not be totally correct but heres some points.

the speed factor is VELOCITY of the joint. the actull joint strenth which it can lift and the maximum force that can be put on it are set when you first create the joint , ie joints set streanth to lalalla so although you increaseing speed so the legs will move faster it will not nescercerry be able to jump although it can happen.

there is a way of speeding up simulatoins , the easyest being enable fast physics which is documented.

the speed of each leg is based on a sinewave. so acceleratoin increases , then decreases then reverse increase and reverse decrease. most notiably this makes it much easer for a joint to have a starting directoin , if you change the phase by 180 degrees then instead of the leg moving forward first it will move in reverses first. becouse of this min max angles are not needid as long and the inital joint strenths are stroung enough :)

if you lookup sinewaves on google you can see some intreasting things can be done, so you can change the normal angle of the joint , put pauses in. you could even create square wave.

Before you start diving into the code i would read the manual at least twice, some explanatoins are not where you would think and a quick glance at a way of doing something could save you hours later when you run into problems.

hope you have fun with breve.

I'm not sure I totally understand the question, but yes, the SPEED factor as used in the Walker demo will change the behavior of the joints. This is intentional, as SPEED -- by design, in that specific case -- is referring to "joint speed", not simulation speed.

To increase simulation speed, as NoZ suggests, you can enable fast physics (see the PhysicalControl class documentation).

If that's still not fast enough, you can play with the integration steps and iteration steps in the Control class, but be careful: increasing these values leads to less accurate simulation.

- jon

Perhaps my fault is in thinking that the simulation runs in a given speed. But it seems that breve runs the simulation as fast as possible(?!)
I only wanted to speed up the simulation in comparison to real life by speeding it up without using faster joints. More like skipping frames in a movie to have only half the time, than telling a car to drive twice as fast.
The first thing does not change physical simulation, the second does.

But if breve already tries to speed up the simulation at maximum, my intention is worthless. This is what I have to figure out.

Yes, breve always runs a simulation as fast as possible, but it uses an internal simulation clock so that the speed of the computer has no effect on the simulation.

An object moving at 1 meter/second (there is no inherent space scale in breve, but "meter" is the one typically used for physical simulations)) will always move 1 meter in 1 simulated second. The "real-time" required for that simulation though will typically be far less than 1 real second.

- jon

Is there a way to make breve run in real-time? That is; when the iteration-step-size = 0.05 (as is the default), is there a way to make the iterate method perform all the calculations during 0.05 seconds? I am currently training neural networks to control breve based on data gathered from a Pro Reflex tracking system (i.e. I have placed fluorescent balls on my own body and I have tracked the coordinates of the balls). What I would like to do is to display the video of my own movements and the video of breve at the same time, but for this to look nice breve must be run in real-time as well. The feature that breve run as fast as possible is nice when training the networks, but it would be nice if there was a variable that could be set allowing for real-time rendering of the breve engine.

this is a simple piece of code to make simulation go real time:

realTime = (self get-real-time) - startTime.
simulTime = (self get-time).
iterationStep = (self get-iteration-step).
if simulTime > realTime: self sleep for-seconds (simulTime - realTime).

ok although e-kapp is right i take it the refreash rate of your data is 0.05 secounds , then youve tryed to get breve to iterate every 0.05 secounds. and it hasn't worked and you think that breve is too slow, well the solutoin is fairly simple, only use every secound part of the data. and set breve to 0.1 secound. if you just want a visual interpriatoin this will work fine becouse i dont think are eyes work that fast. so altough breve isnt refreashing the imagine as often it will still keep pace with the other video or whatever.

******* ignore if your not going extrapalate results from breve **********
if you are making a simulatoin in breve and your going to use the data to create it then compare data you would need to get breve to iterate at every 0.025 and breve will slow down at this point ( if its running slow at 0.05) but the corosponding data will be at a 0.05 secound intervals although in realtime it took longer (becouse your not only extrapoloating your using the processor to create data). and nyquist declares if you want to faithfull reconstruct a signal (or data) you have to sample over double the highest rate possible which for you would be 0.05.

NoZ

e-kapp: I have already implemented a similar solution (but at the MatLab side), but this leads to jerky behaviour of breve, since it will wait for a small period of time before continuing the motion. NoZ: it is not the problem that breve is too slow, it is actually too fast.

The internal clock uses simulated seconds for knowing when to call breve; it would be nice to make the internal clock to use real seconds through some easy method call (like how to change from fast physics to "real" physics).

i think the solutoin is to increase the simulatoin timestep then. it is in the breve documentatoin. you may need to mess around with it a bit but im 99% sure you can set it to what you want. breve works of the system clock and trys to keep in proportoin with it. (thats why simulatoins seem smoother on more powerfull computers) so by increasting the timestep it will go slower only refreashing every sec instead of every half sec or whatever. if your still not happy or dont want to do it that way then get the present timestep of each iteratoin , then for each vector or acceleratoin devidid it so thats breves iteratoin timestep will keep the same and then everything else will be cosher.

it doesn't stop the motion. it exaclty use more time than necessari to make a step of integration. Trust me :-)
The reason is simple. Each iteration Breve evaluate the new positon and velocity of every object in the simulation; then it wait for a very short while but do not change the risult. The solution of NoZ is right to but does not allow you to be shure of an exact real-time simulation cause it is too "empiric".
Maybe you can use both in order to have more precision (the shorter is iteration time the more precise is the solution) ad my method precision. I use the method i told you, and I have no problem.

I appreciate both of you taking interest in my problem and suggesting solutions, but your suggestions do not attack the core problem - i.e. making it run in real-time from within the engine itself. I was kind of hoping that Jon Klein would say "Hey, there is an undocumented function you can call to activate real-time mode!" Perhaps I must implement this myself (which will not happen until after my Master's Thesis though).

elton_john wrote:I appreciate both of you taking interest in my problem and suggesting solutions, but your suggestions do not attack the core problem - i.e. making it run in real-time from within the engine itself. I was kind of hoping that Jon Klein would say "Hey, there is an undocumented function you can call to activate real-time mode!" Perhaps I must implement this myself (which will not happen until after my Master's Thesis though).

Yeah, sorry -- there is no hidden function to do this. I can implement one for the next version, but in the meantime I would suggest using e-kapp's suggestion.

Or perhaps a variation on e-kapp's suggestion which would be to calculate the elapsed time and then use that to set the integration step. This would avoid the jerkiness and is the approach I would take with an internal implementation. The only downside with a simulation-level implementation (I think) is that it will lag one frame behind, meaning that it will be adapting to the previous frame. If the load is fairly uniform, however, I think it shouldn't be a problem.

The reason I've resisted this behavior in the past is because it causes simulation results to be different on different computers, which is generally not desired, but there are of course situations where it is preferable.

- jon

This seems to work for me:

realTime = (self get-real-time).
freeTime = max((iterationStep / simSpeedFactor) - (realTime - lastRealTime),0).

if freeTime > 0 : self sleep for-seconds (freeTime).
else print "Running slow than requested".

lastRealTime = realTime + freeTime.

super iterate.

I am planning to create menu items to speed up or slow down the simulation by fixed ratios without affecting the integration or iteration step sizes hence the simSpeedFactor. It should also allow the sim to be paused and restarted without confusing the timings.