Search

[Xylotica]

I attached a "mock-up" of a possible evolution of the "Analysis" window.

First and foremeost, I think that priority should be given to respect the execution speed (or percentage of execution speed selected by the user), and that the framerate should always adapt.
In other words, the framerate should always be as high as possible for a given simulation speed , and that for two reasons :
-Who would set a crappy framerate on purpose anyways ?
-Who would want the simulation to not reflect the intended speed ?

If, despite a slower framerate, the simulation can not reflect the desired speed, then there should be a WARNING ! sign because it is not accurate, and accuracy is a desired attribute of a simulation.

Then I added a regular slider to make a "rough" positionning, and would use the white dotted line to make more accurate positionning.

The traditionnal buttons would be used to  "Play" and "Stop" of course, but also "go to start" and "go to end", which is not easy to do with the present interface.

Best,

[Johannes @ Robots in Architecture]

Thanks for the feedback.
Please take under consideration that the speed is always an estimation, it's mostly here for optimization (e.g. as an optimization parameter for Galapagos) but not for giving you a precise value for the time of a project.
If you do need an exact time value, you could e.g. run the program in KUKA Office.Lite.

There are of course technical reasons for the manual FPS selection, though I understand why you would like an adaptive refresh rate.
I'll look into it.

Best,
Johannes

[Xylotica]

Hello Johannes,

I'm pretty much hampered by how slow the simulation playback goes.
Sometimes it's really like watching grass grow ; there's not much that can be learned from that in terms of simulation...

Couldn't there be a cheap hack to get this thing on ball bearings, because as soon as we hit the swamp, simulation speed is not accurate anyways (much too slow).

A pre-compute of all robot meshes ?
A stack of all the A1->A6 values ?

[Johannes @ Robots in Architecture]

Hello,

A large part of the overhead has to do with Grasshopper, as when the component refreshes, it refreshes the inputs and outputs, and that gets slow with thousands of commands.
To demonstrate that, take a look at the time it takes for the Analysis component to run in the GH profile. All it does is assign existing data to outputs, there are no calculations happening at all.

But thanks for having me think about it a bit more, because if we outsource that to a separate component, then that issue goes away.

Attached is an exemplary file how that could work - should be an OK workaround for now. We might implement a separate simulation component in the future to improve performance!

Best,
Johannes

[Xylotica]

Hi Johannes,

I understand what you are doing here, except that you didn't turn off the analysis data in the second simulation component.
So you mean that if you replace that second simulation component by a custom C# component, it could make the simulation much more fluent ?

Hey ! I vote for that ! specially if that allows to make the simulation speed more accurate when running at 100%, to get a real feel for what's going to happen.
To me, this is a core functionality of KUKA|prc, as a simulation tool, and it deserves your love :)