EVA Parachutes

[sumghai]

@StupidChris has expressed interest in allowing Kerbals on EVA to deploy personal parachutes, to allow skydiving or bailout from stricken vessels.

At present, we'll focus on manual chute deployment, although an automatic bailout systems or even ejector seats could be possible in the future.

Typical use case

• Kerbal goes on EVA
• Right-clicking on the command pod allows the active Kerbal to grab a parachute pack ("Get Personal Parachute"), which appears as an orange backpack
• Kerbal manually lets go of hatch ladder and falls away from vessel
• Parachute manually triggered ("Deploy Personal Parachute")
• Parachute canopy and risers are auto-cut after landing, or manually ("Cut Personal Parachute")
• Kerbal can then manually discard parachute backpack ("Discard Parachute Harness")

Personal Parachute - Specifications

• Pilot-main combo
• 7.24m diameter circular main canopy
• 6 m/s landing speed (2 m/s is more realistic but too slow; Kerbals are probably okay with rough landings)
• One model with one full-deployment animation (no reefing) that plays uninterrupted
  • t = 0s: Pilot chute appears, fully inflated
  • t = 2s: Pilot chute pulls main canopy and risers out; pilot chute disappears
  • t = 4s: Main chute canopy fully inflated
• Main chute risers will converge on a single point from the backpack
  • Having the risers converge on two points would look more realistic, but because KSP cannot simulate proper rope physics, parachute transforms always pivot around a single point
• New combined textures with separate areas for pilot and main canopies
  • RC_canopy_EVA.png: white pilot + main (default, "civilian")
  • RC_canopy_EVA_mil.png: white pilot + "military" green main (military variant)

Parachute Backpack - Specifications

• Fits on Kerbal model
• Consists of a main chute backpack that partially covers the Kerbal jetpack, a spare chute bag in front of the chest
  • The existing harness on the Kerbal EVA/IVA suit model will suffice.

Notes

• There shouldn't be a dedicated parachute container part in the VAB/SPH part list; instead, a ModuleManager patch should just add the chute container PartModule directly to crewed pods
• Some crewed pods should not include chute containers (e.g. FusTek)
• A Kerbal can only grab one backpack at a time (but can discard the current one and grab another one until the pod's chute container runs out)
• Transferring parachutes between Kerbals/vessels is probably too complicated
• Each parachute pack should come with two sets of pilot/main parachutes (one primary, one spare)
  • If the primary set is cut whilst the Kerbal is falling, the user should be able to manually trigger the spare
  • Maybe a simple counter for number of chutes remaining will suffice
  • The number of spare chutes cannot be changed (for obvious reasons)

[sumghai]

@sumghai's TODO list:

• [x] model_RC_canopy_EVA.mu: combined pilot/main EVA parachute model
  • [x] RC_chute_EVA_full_deploy: a single animation consisting of pilot chute appearing, pulling out main chute, then disappearing before main chute canopy inflates
• [x] RC_canopy_EVA.png: white pilot + main (default, "civilian")
• [x] RC_canopy_EVA_mil.png: white pilot + "military" green main (military variant)
• [x] model_RC_backpack_EVA.mu: primary and spare parachute backpack for Kerbal EVA model
• [x] RC_backpack_EVA.png: KSP orange backpack textures
• [ ] RC_hide_jetpack.png: 1x1 px transparent texture used to hide Kerbal EVA jetpack mesh(es) (Not needed, will be generated procedually)

In the future, I could also do different chute canopy shapes / accompanying textures (e.g. T-11 "square" military personal parachute, parafoil parachutes)

[ChrisViral]

Few notes from myself:

• Transferring parachutes is actually kind of planned, Kerbals will be able to move spare canopies from the pod to the parachute case to repack them eventually, or from pod to pod if wanted.
• For now, I would think having a spare chute is not necessary, as the parachute won't be programmed to potentially fail, In the eventuality this is added further down the road we could reconsider this stand.
• You are much more organized than I am :P

[sumghai]

@StupidChris:

Few notes from myself:

• Transferring parachutes is actually kind of planned, Kerbals will be able to move spare canopies from the pod to the parachute case to repack them eventually, or from pod to pod if wanted.

Oh okay, I see.

I'm wondering if there is way (in the current version or otherwise) to optionally disable repacking.

• For now, I would think having a spare chute is not necessary, as the parachute won't be programmed to potentially fail, In the eventuality this is added further down the road we could reconsider this stand.

Aye.

I'll keep the chest bag anyway, in preparation for this eventuality.

• You are much more organized than I am :P

Haha, not really :P

[ChrisViral]

I'm wondering if there is way (in the current version or otherwise) to optionally disable repacking.

Yes, by setting the number of spare chutes to zero :P

But don't worry about it, the EVA chutes will be handled by a completely different module.

[sumghai]

@StupidChris:

Yes, by setting the number of spare chutes to zero :P

Ah, I think I've done that for SDHI already :)

But don't worry about it, the EVA chutes will be handled by a completely different module.

Sounds good.

---

Just uploaded preliminary models and textures (b063ca6) - if I've done this correctly, the animation name is RC_chute_EVA_full_deploy. The default texture should be RC_canopy_EVA.png, while the mil one is an alternative texture.

Because I can't test this in KSP on my shitty laptop, could you please test that the animation meets your requirements? Thanks.

Also, in order to make the backpack, I'll need to somehow figure out the dimensions of the Kerbal torso and jetpack, as well as extract the default orange suit textures.

[ChrisViral]

I can't test it yet as the EVA chute module simply doesn't exist curently. I could probably slap it on some generic part and just run the animation to see, but that'll require a dummy module, and I'm not sure I have the time to write that before the end of the week, I'll see about it.

Thanks though, textures look good!

Though I have a question: Given the canopy textures are being repeated, instead of creating one that wraps all the way around the chute, could the texture simply be the pattern once and then have it tile up on the rest of the canopy? That would save memory space. RealChute is not hungry on that, but knowing KSP the more we could save the better.

[sumghai]

@StupidChris:

I can't test it yet as the EVA chute module simply doesn't exist curently. I could probably slap it on some generic part and just run the animation to see, but that'll require a dummy module, and I'm not sure I have the time to write that before the end of the week, I'll see about it.

Thanks though, textures look good!

You could probably use the standard RealChute part module for a quick test, although obviously you won't need to specify the predeployment animation (since there's only one full-deployment animation).

Happy to help, as always :)

Though I have a question: Given the canopy textures are being repeated, instead of creating one that wraps all the way around the chute, could the texture simply be the pattern once and then have it tile up on the rest of the canopy? That would save memory space. RealChute is not hungry on that, but knowing KSP the more we could save the better.

Good question - I thought about that back when I made the first batch of RealChute models.

My reasoning for ultimately opting for the full canopy was to allow people to put logos / advertising text on custom chute canopy textures (see issue #13).

[sumghai]

Okay, here's another question for you.

I've managed (through various means) get a model of a Kerbal into Blender. Here, I've applied IVA suit textures, for reasons which will become clear shortly:

I've always imagined that a Kerbalnaut abandoning a spacecraft with a parachute would have orange suits, just like the Advanced Crew Escape Suits worn by real Shuttle astronauts:

Notice how the parachute backpacks are also orange.

As such, my intention is to make the parachute packs the same color and texture as the Kerbal orange IVA suits.

The front spare chute bag is easy, but the rear primary chute bag may interfere with the Kerbal's jetback. I've heard it was possible to hide parts of the Kerbal mesh (such as eyes and helmets) through plugins, so I'm wondering if it would be feasible to hide the jetpack when a Kerbal is equipped with a bailout chute backpack.

Thoughts?

[ChrisViral]

You could probably use the standard RealChute part module for a quick test, although obviously you won't need to specify the predeployment animation (since there's only one full-deployment animation).

I'm not sure that would work, if theres no animation of the given name it might cause errors which would break the module.

I've heard it was possible to hide parts of the Kerbal mesh (such as eyes and helmets) through plugins, so I'm wondering if it would be feasible to hide the jetpack when a Kerbal is equipped with a bailout chute backpack.

Sure, by dumping all the transform names of the EVA model to the log I could find which to hide, but that might have secondary effects like preventing the jetpack to correctly work if some of the trust transforms are hidden too. My reccomendation is simply to make it slightly bigger than the EVA jetpack so that the jetpack is completely englobed in the parachute packing, that way it'll be hidden from view. Not giving it a collider would allow the jetpack to work normally too.

[sumghai]

Okies, I see.

I'll do what I can to make the primary chute backpack bigger and encapsulating the jetback.

[sumghai]

After examining the Kerbal jetpack a bit more, I've found that it was far too big to be covered up with the main parachute backpack (the jetpack is even larger than the Kerbal's own torso).

I think the best I can do is to the backup chute chest bag - we'll just have to accept the chute sprouting out of the jetpack.

[TedThompson]

How about making it smaller so there is a chute back pack for those with texture replacer whose kerbals spawn in their IVA suit in atmos?

Sent from my ASUS MeMO Pad

Robin Chang notifications@github.com wrote:

After examining the Kerbal jetpack a bit more, I've found that it was far too big to be covered up with the main parachute backpack (the jetpack is even larger than the Kerbal's own torso).

I think the best I can do is to the backup chute chest bag - we'll just have to accept the chute sprouting out of the jetpack.

— Reply to this email directly or view it on GitHub.

[ChrisViral]

... I'm currently thinking I could just change the texture of the jetpack to a transparent one. I'll have to experiment with that.

[sumghai]

@StupidChris:

... I'm currently thinking I could just change the texture of the jetpack to a transparent one. I'll have to experiment with that.

When I get home today, I'll get you a full list of all the meshes* assocated with the jetpack

*The jetpack has separate meshes for the jetpack base, the two fuel tanks, and all the tiny tiny thrusters. My ripped model apparently doesn't account for the jetpack control joysticks, though.

[ChrisViral]

Oh I can do that easily, it would take a few minutes for me to output it to the log. Besides I need to access the transforms anyway.

[sumghai]

@StupidChris:

Oh I can do that easily, it would take a few minutes for me to output it to the log. Besides I need to access the transforms anyway.

Ah, I see!

Righto, so I'll make the parachute backpack + spare chute chest bag as originally planned, and I'll modify my final model depending on the results from your experimentation.

Do do suppose it would be a simple task of disabling/enabling the mesh render on said parts?

[ChrisViral]

I think setting the textures to a transparent one would be simpler and easier.

[sumghai]

Okies.

A 1x1 px transparent PNG should be very easy to do. Lemme update my TODO list.

[ChrisViral]

You don't even need to do it, I can create one procedurally by code, no need to load it externally :P

[sumghai]

Coolio - lemme take that off the list :)

[ChrisViral]

So...

I have good news. Turns out turning "off" the jetpack does not change it's behaviour at all. I outputted the whole transform tree to the log and I can target what I need easily. I didn't turn off the armrests, nor the trusters. If I did, the thrust would appear to come out of nowhere. What I suggest is that the parachute backpack should basically replace the jetpack. And we'll pretend that the backpack has jetpack properties :P

[sumghai]

@StupidChris:

What I suggest is that the parachute backpack should basically replace the jetpack. And we'll pretend that the backpack has jetpack properties :P

Okies, I'll get on the main backpack this weekend - so far I've got the rough geometry of the reserve chute chest bag in place.

[ChrisViral]

@sumghai All good. Other than that, I was about to test the chute model that you sent me the other day, buuuut I'm going to need the transform name, just like I needed it for the regular parachutes :P

[sumghai]

@StupidChris:

I was about to test the chute model that you sent me the other day, buuuut I'm going to need the transform name, just like I needed it for the regular parachutes :P

I suddenly realised I had introduced a complication into the EVA parachute model.

Currently, model_RC_canopy_EVA contains two meshes, main_chute and pilot_chute. Due to the way I've done the animation, pilot_chute is independent of main_chute, which means the chute hanging/pivoting feature in RealChutes may end up being a bit wonky.

If I make pilot_chute a child of main_chute, that should fix the problem.

tl;dr - use main_chute as the transform. I'll upload the fixed model in a moment.

[sumghai]

I've also encountered a hiccup with the primary chute backpack model, but more on that later this weekend.

[ChrisViral]

@sumghai I suddenly realised I had introduced a complication into the EVA parachute model.

Currently, model_RC_canopy_EVA contains two meshes, main_chute and pilot_chute. Due to the way I've done the animation, pilot_chute is independent of main_chute, which means the chute /hanging pivoting feature in RealChutes may end up being a bit wonky.

If I make pilot_chute a child of main_chute, that should fix the problem.

tl;dr - use main_chute as the transform. I'll upload the fixed model in a moment.

Figured it out myself haha haha

Used the same tool I used to get the Kerbal tranforms, and found that out, both are separate children of the main mesh. Better make the pilot a child, yes.

I've also encountered a hiccup with the primary chute backpack model, but more on that later this weekend.

Aye, I'll be waiting on you for this.

[ChrisViral]

@sumghai Alright after testing , the animation and textures look awesome the only thing I would like to request is for the pilot perhaps to appear folded too and open up before pulling the main chute out? Just a thought, because right now it seems to just appear suddenly fully deployed, pulling the main out. I don't know how doable this is for you, but I'll trust youre judgement :) Else looks awesome as always!

[sumghai]

The reason the pilot appears as fully deployed at the start is because I assumed that it is small enough to inflate very, very quickly (probably even via pyrotechnics). I could give it a faux canopy inflation animation, but given my prior point, I doubt that would be necessary.

Also, I've updated the model (c0fd4fc) to fix the chute transforms. I tried making pilot_chute a child of main_chute, but it did weird things with the scaling I used for the animation. In the end, I put main_chute and pilot_chute under a new eva_chute_trans transform, so that the pivoting feature will work properly.

You can also safely ignore the dummy_ignore transform, since that is a hack to prevent Unity from doing stupid things to Blender models that have only one top-level object.

[ChrisViral]

It's not about the rotation, but mostly about hiding/showing the canopies. I was actually considering having an hasPilot field to potentially give a different wriggling to the pilot chute if one is present, but for that I still needed it to be a child of the main rotating transform. Putting the main chute and the pilot both under a generic transform will do the trick for sure, thanks! And no worries, much thanks :)

[ChrisViral]

p.s. @sumghai, mind pushing new changes to the 2.0 dev branch if you have more models/textures to add? Had to do some git whackyness to get to copy your commit to the branch. Not a big problem, but theres no reason to have the hasssle if you can push to the dev branch. You should probably just fork the dev branch and do your updates there and then send PRs, that might be easier.

[sumghai]

I knew there was something odd with all those error messages the GitHub client was throwing at me on Windows!

Thanks for the heads-up, I'll make sure future updates go into the dev branch :)

EDIT: My GitHub client has a option to select which branch to push a commit into. I've changed it to 2.0-dev-branch so that I don't derp this up again ;)

[ChrisViral]

Alright, so I'll be waiting for the backpack on your end. But I'd also like to request something: The backpack would need an empty transform that would serve as position anchor and parent to the parachute. Since both models are separate and that they will be added to the kerbal at runtime, I need to position them on the kerbal. For thebackpack, it's the same position as the jetpack so it's easy. But the parachute will require me placing it somethere. So basically, a dummy "place me here" transform would be needed.

[sumghai]

Okies, I'll stick an empty transform called chute_attach_point in the backpack model.

[sumghai]

Based on the ACES II escape suit Personal Parachute Assembly design I described previously, I've roughed out the meshes for the backpack (primary chutes backpack + reserve chute chest bag), and put in some temporary textures + AO bake - I'll upload the WIP models to the repo tomorrow:

The hiccup is that I couldn't make the backpack big enough to cover up / fit over the now-nonexistent jetpack base without making it look horribly out of proportion. This is because the RCS thrusters are actually mounted on cantilevered extensions, which made accommodating for them in a new model very difficult (even if I managed, it would look like a bodge).

As a compromise, I think we'll just have to hide the thrusters and joysticks, and disregard the thruster jet effects coming out of nowhere.

_Additionally..._

In real life, no astronaut uses a parachute with a jetpack concurrently.

As such, I'm wondering if the jetpack feature itself be completely disabled whenever the Kerbal is currently equipped with the parachute pack, which will also hide the thruster jet effects as well:

When user presses R to toggle jetpack:

If Kerbal is equipped with parachute
    Disable jetpack;
    Display warning "Cannot use jetpack while wearing parachute backpack";
Else
    Allow jetpack to be toggled as usual;

When user un-equips parachute backpack
    Show jetpack model meshes;
    Re-allow jetpack toggling;

[ChrisViral]

The problem is that in space, a Kerbal without a jetpack is a dead weight. I considered turning it off, and I understand how this is by far the realistic solution to this, but on a gameplay perspective, it does not have a very large appeal. I'm considering limiting the amount of jetpack fuel instead to at least have a downside.

Anoooother thing I could do, is try to move the jetpack thrusters. The problem is that this would be a very long try and error process.

Could you at least accomodate a slot where the joystick extensions would connect to the parachute backpack? I can hide the jet propulsors without hiding the exausts. We'd have exhaust coming out of nowhere, but at least it wouldn't look as weird as floating thrusters.

EDIT: Also, I forgot to ask about this, but is there some sort of "cap" that dissapears on this backpack model? Might look weird else.

EDIT²: Can you make it so that the the center of the backpack object coincides with the center of the Kerbal so that I can just load it in game and slap it on the Kerbal without moving it around? This would include rotation being oriented correctly too.

[sumghai]

@StupidChris:

The problem is that in space, a Kerbal without a jetpack is a dead weight. I considered turning it off, and I understand how this is by far the realistic solution to this, but on a gameplay perspective, it does not have a very large appeal. I'm considering limiting the amount of jetpack fuel instead to at least have a downside.

Okies, I understand

Anoooother thing I could do, is try to move the jetpack thrusters. The problem is that this would be a very long try and error process.

Yeah, sounds pretty tricky to me as well.

Could you at least accomodate a slot where the joystick extensions would connect to the parachute backpack?

I think I can do that.

The weird thing is, the Kerbal model I currently have apparently didn't include the joystick extensions themselves (although the original jetpack model does have the accomodating slots).

When I modelled the parachute backpack, the two side cylinder doohickey occupy the same space as the slots, and I can live with the joystick extensions clipping through them.

I can hide the jet propulsors without hiding the exausts. We'd have exhaust coming out of nowhere, but at least it wouldn't look as weird as floating thrusters.

Yep.

EDIT: Also, I forgot to ask about this, but is there some sort of "cap" that dissapears on this backpack model? Might look weird else.

I haven't included a cap piece yet, but I could add one in if you want.

EDIT²: Can you make it so that the the center of the backpack object coincides with the center of the Kerbal so that I can just load it in game and slap it on the Kerbal without moving it around? This would include rotation being oriented correctly too.

Hmm...

I actually got this Kerbal model pre-extracted from someone called Banbury, which as you can see has the model origin at the base of the Kerbal. Banbury also wrote that model extractor plugin that you compiled the other day.

I may have to re-extract the Kerbal model from the game myself just to be absolutely certain what the correct model origins are, but I'm not sure if my shitty laptop will be able to load even a stripped-down game.

[sumghai]

New TODO list:

• [x] Re-extract Kerbal EVA model from stripped-down KSP installation
• [x] Check Kerbal EVA model part origin
• [x] Check that chute backpack model part origin corresponds to Kerbal EVA model origin
• [x] Check that backpack cylinder doohickeys will hide joystick extensions adequately
• [x] Modify mesh to include cap (if possible)
• [x] Upload WIP backpack model to dev branch (so that you can play with it while I refine it)
• [x] Rework UV mapping (current one is temporary)
• [x] Rebake AO
• [x] Finalize textures
• [x] Upload to dev branch for QA testing

By the way, the parachute pack will be in veteran suit orange. I know that most Kerbals will either be wearing the white EVA or grey IVA (if using TextureReplacer) suits, but the reason for making the backpack orange is because I want it to be clearly identifiable as an "emergency" item.

[ChrisViral]

I may have to re-extract the Kerbal model from the game myself just to be absolutely certain what the correct model origins are, but I'm not sure if my shitty laptop will be able to load even a stripped-down game.

I can run the plugin and send you the output if you'd like.

[sumghai]

I can run the plugin and send you the output if you'd like.

That would be very, very much appreciated!

I'm assuming the plugin will attempt to extract all the models from the game, but you already know the OBJ files corresponding to the Kerbal model anyway.

[ChrisViral]

I'll make an install with no parts. Besides, I'm talking to @NathanKell and @sarbian about this right now, they might have an alternative to offer.

[sarbian]

There you go https://www.sarbian.com/sarbian/forSC.zip The eyes are missing but the other should be here.

[sumghai]

Thanks @sarbian.

@StupidChris When I imported the newly-extracted models into Blender, turns out that the mesh origins were all at the base of the Kerbal - I guess I got lucky after all :)

I've imported the joystick extension arms into my model, and I'm figuring out how to rescale parts of the backpack to cover up the main pivots.

EDIT: Stretched the backpack proportions around a little bit, managed to cover up the pivots to the best of my ability:

The backpack is now fatter and wider than originally envisioned, but it's not too much of a change, so I suppose I can live with that. I'll need to tweak some non-critical areas of the geometry to make it look nicer, though, as well as put in the parachute container cap.

Sorry this is taking so long :(

[ChrisViral]

@sarbian There you go https://www.sarbian.com/sarbian/forSC.zip The eyes are missing but the other should be here.

Thank you very much. Can you confirm that the origin on the mesh becomes the origion of the object transform in the game? Sounds kinda odd that transform.position would be at the feet of the kerbal, but nothing would suprise me anymore.

@sumghai Stretched the backpack proportions around a little bit, managed to cover up the pivots to the best of my ability

Awesome. Looks good to me, I doubt anyone will smash on the proportions on that. Because we could have a long talk on the proportions of the Kerbal's head. Pun intended.

Sorry this is taking so long :(

Don't worry about that :) I'd rather have it well done, and you're doing a pristine job.

[sarbian]

Can you confirm that the origin on the mesh becomes the origion of the object transform in the game? Sounds kinda odd that transform.position would be at the feet of the kerbal, but nothing would suprise me anymore.

No idea. I never looked much on how EVA works. Nothing stops one of the top transform to have a local offset that would make the GameObject Origin at the CoM.

And amazing work. I can't wait to play with that.

[ChrisViral]

No idea. I never looked much on how EVA works. Nothing stops one of the top transform to have a local offset that would make the GameObject Origin at the CoM.

And amazing work. I can't wait to play with that.

Aye, thank you, I guess trial and error is going to have to do.

@sumghai make it so that the backpack also has it's mesh origin with the kerbal mesh origin. We'll see how that behaves in game.

[sumghai]

@StupidChris:

make it so that the backpack also has it's mesh origin with the kerbal mesh origin. We'll see how that behaves in game.

Yep, that's how it has been from the start* :)

*I've also retained that dummy transform you need to position the chutes themselves.

[ChrisViral]

Aye, thank you. In the eventuality where the origin is the COM in game, how easy would it be for you to move the origin of the mesh? Is there a COM indicator on the Kerbal mesh?

[sumghai]

Aye, thank you. In the eventuality where the origin is the COM in game, how easy would it be for you to move the origin of the mesh? Is there a COM indicator on the Kerbal mesh?

That wouldn't be too hard - I'd just move the models in Blender, and re-export from Unity.

I suspect that the Kerbal EVA model might have a secret, undocumented CoMoffset argument (CoMoffset is used in mod wing part CFGs to tweak their CoM).

[sumghai]

I've uploaded the preliminary backpack model (1ce71ed) so that you have something to work with right away, while I refine the UV maps, AO bake and texture over the next few days.

chute_bag_primary is the main backpack itself, while flap is the removable cap; the other meshes (reserve chute chest bags and side cylinder doohickeys) you can safely ignore.

I've also added a little detail to the EVA chute canopies that was inspired by the diagonal lines seen in the US Army T10 parachutes (b3c4a51).

[ChrisViral]

Awesome, thank you. What's the name of the chute anchor?