Board index FlightGear Development New features

Rope dynamics

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

Re: Rope dynamics

Postby wlbragg » Sun Dec 03, 2017 5:43 pm

It's a 3d model of chained segments with ball and socket joints. There are so many issues involved for any particular use case and every use case adds to the issues you have to account for. One step forwards invariably takes you two steps back.
Case in point, what happens to that coiled rope on the ground when it hits a collide-able object (lowered onto)?

My first impression is I want it for the cargo hauling simulation, but if I lower the rope over an object it needs to have a different animation. I think Thorsten states it best
could it be made in a way that the rope in the scene isn't the single most framerate-draining thing? And the answer to that one is probably 'no'.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Rope dynamics

Postby Hooray » Sun Dec 03, 2017 6:01 pm

so that means, that for say 30 segments, each 3D position is computed separately and then placed in the scene accordingly ?
Like you say, I also have no idea how to account for turbulence/collision detection, or hitting a water surface...

Looking around online, it really seems like modeling ropes and chains is a fairly common challenge 3D modelers - but that's just the visual aspect, i.e. not the physics.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Rope dynamics

Postby wlbragg » Sun Dec 03, 2017 6:09 pm

Looking around online, it really seems like modeling ropes and chains is a fairly common challenge 3D modelers - but that's just the visual aspect, i.e. not the physics.


And most of it is a very simplistic use case.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Rope dynamics

Postby Hooray » Sun Dec 03, 2017 6:32 pm

The cylinder-based approach I mentioned turns out to be way too simplistic, some of the more technical papers favor using a series of springs, actually modeling lots of details like air density and friction coefficients, as well as weight of the rope (elements) themselves. Like Thorsten said in his introductory posting, it is indeed a surprisingly interesting problem actually.

But since you mentioned switching between different model animations, I take it then that the visualization part existed prior to the physics simulation underneath ?
Would the visualization part actually work by treating each part as a segment that has its own 3D position/orientation relative to the previous elements and the forces at work, and smoothing the space in between each segment using a shader/effect ?

Or in other words, what is it currently that is making this computationally heavy, I expect the physics code or is it the visualization part ?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Rope dynamics

Postby Thorsten » Sun Dec 03, 2017 7:39 pm

Or in other words, what is it currently that is making this computationally heavy, I expect the physics code or is it the visualization part ?


* you have the per-segment property I/O (at least two, possible four operations per segment) - if you want a detailed 50 m rope with 5 cm segments, it's 4000 properties per frame, go figure

* in addition per segment (dependent on the strategy you use to compute) the rough equivalent of a PID controller to solve the wave equation

Dependent on the level of detail you want for the second, it can be less or more than the first, but I am fairly sure if you go realistic and solve 2000 JSBSim PID controllers, that's going to hit you badly.

so that means, that for say 30 segments, each 3D position is computed separately and then placed in the scene accordingly ?
Like you say, I also have no idea how to account for turbulence/collision detection, or hitting a water surface...


Yes, except 30 segments don't get you far with a rope (even 90 look pretty coarse). And, again, dependent on the level of realism, you'd need one terrain query per segment.
Last edited by Thorsten on Sun Dec 03, 2017 7:50 pm, edited 1 time in total.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Rope dynamics

Postby Hooray » Sun Dec 03, 2017 7:48 pm

okay thanks for clarifying - I take it then, that it's the usual property bottleneck we're hitting here, not unlike the ADI ball.
What are the required "inputs" that the rope simulation is using currently - i.e. would it be feasible to provide those in the form of a texture (think n-dimensional table) and pass that to the GPU, would that help with the bottleneck ?
As we mentoned elsewhere, we actually have working code to integrate the Canvas and effects systems - which is to say that a texture can be created dynamically and passed to the effects framework for further processing (you mentioned once the ADI ball could do away with many property accesses if it were done in GLSL) ?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Rope dynamics

Postby Thorsten » Sun Dec 03, 2017 7:52 pm

What are the required "inputs" that the rope simulation is using currently - i.e. would it be feasible to provide those in the form of a texture (think n-dimensional table) and pass that to the GPU, would that help with the bottleneck ?


Doesn't get rid of the computation. You can do the computation on the GPU, but then the rope doesn't interact with anything because at the GPU level it's just screen pixels.

As I said earlier, you have to dig deep into the C++ part of the rendering code to make fast rope simulation happen.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Rope dynamics

Postby Hooray » Sun Dec 03, 2017 9:28 pm

What is it actually that you are doing to implement the current set of functionality in terms of interaction handling (terrain & atmosphere, I suppose ?)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Rope dynamics

Postby wlbragg » Mon Dec 04, 2017 3:32 am

Terrain, yes. Atmosphere, I don't think so unless I am forgetting about something. We're using pilot force properties to effect motion and I think that is pretty much it.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Rope dynamics

Postby Thorsten » Mon Dec 04, 2017 7:37 am

It's not an outrageously long piece of code, and less messy than it was

https://sourceforge.net/p/flightgear/fg ... mation.nas

Terrain is assumed to be flat located below at aircraft ALG altitude. Wind pressure is assumed to be driven by airspeed and proportional to a user-controlled parameter, also dependent on orientation of the segment relative to the wind. Ground friction is assumed to be proportional to speed over ground and number of segments on the ground. Waves along the rope are (where numerically feasible) damped harmonic oscillators with a harmonic potential parameter and a damping parameter. Inertial force (gravity and accelerations) always acts along the aircraft acceleration vector (at pilot position, but using accelerometers in JSBSim you could easily make it act at rope attachment position).
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Previous

Return to New features

Who is online

Users browsing this forum: No registered users and 4 guests