Kerbin Mini Shuttle

[ZRM]

Moving along.

ZRM (and any others with solid information).

I'm packing things up to send to you. First we'll tackle the cockpit and work in reverse (cockpit outwards).

I need to know what needs collision meshes and any other important 3D model in my part (I call them dummy models). Look at the hierarchy on the right and check it.

In the image above, the red are dummy collision models on top of the graphics 3d model. Each button on the MFDs have their own collision mesh as well, although you probably won't use ILS, AP, DTV1-2, DCK (although eventually we'll want to implement those modes). Note that the mfd's are named from LEft to Right with A being the left most, and A on the right being the right most.

The switches on the overhead panel are for the light system. The only switches we'll be using is lightswitch_panel, lightswitch_fd1 and 2. Lightswitch panel controls the emissive (on or off) for the entire cockpit backlights. Unless you want to leave the cockpit panel backlights always on. Lightswitch_fd1 or 2, will control and interior light source. How do I add that lightsource? Does a light added in max work? Or do you have to do that in unity? (that's 4 emissives all turned on by one switch)

Do these work as collision meshes? Do they have to be simpler? What are the rules exactly for collision meshes?

What parts on this landing gear need a collision mesh? Can the collision mesh be complex as you see there? Or can it be simple?

We're looking at a 300mb download currently. Although after DDS compression in unity, that number may be a lot smaller.

Let me know in PM or here any additional information.

The hierarchy looks OK - there are no obvious problems other than you only have two hands for the altimeters - the in-game ones have three. The InternalAltimeterThreeHands module may crash if you don't provide another hand. InternalAltimeterThreeHands wants a 100s hand, 1000s hand and a 10000s hand.

I will have to check whether the lighting imports correctly - you could try adding lights in max and I'll see whether they work, or at least their positions are imported, in Unity. Try to stick to just spotlights/point lights.

One thing you need to know is that all collision meshes need to be convex. If you have a part that cannot be accurately represented by a convex mesh, you can split its collision mesh into multiple convex parts. The wing, for example, can probably get away with one collision mesh. The cargo bay doors could be split into a few long boxes. Don't bother with collision for the flaps. Also, collision meshes should be as simple as you can make them without compromising on gameplay. Collision detection is the most expensive part of physics simulation. Also, if you don't want to spend the time creating a good convex mesh, Unity can create a default one that fits the convex bound of the mesh, though of course the auto-generated mesh may still be too complex.

Same goes for the landing gear. You should only need collision meshes for the gear bay, the pylon and the suspended pylon, all of which should be as simple as possible (boxes should do). Wheel collision is handled by a special Unity wheel collider.

Also, at some point, you will probably want to put simple colliders in front of each window, as well as a camera, so that users can double-click on windows to get a better view out of them like in stock command modules, using InternalCameraSwitch.

Edit: Oh, by the way I have now released a Mac version of KCA.

[Kommitz]

It's best to keep collision meshes as low poly as possible, although with due regard for the underlying shape. (afaik) They also have to be convex, so for concave items (such as the cargo bay) you'll need to build a cage of convex meshes to fit it.

This whole project is looking brilliant by the way. I love the style and execution and the cockpit is looking really good.

Edited August 15, 2013 by Kommitz

[helldiver]

The hierarchy looks OK - there are no obvious problems other than you only have two hands for the altimeters - the in-game ones have three. The InternalAltimeterThreeHands module may crash if you don't provide another hand. InternalAltimeterThreeHands wants a 100s hand, 1000s hand and a 10000s hand.

-That was an oversight on my part. I knew about the 10000s hands but I didn't think KSP used it. Adding one would take 10 seconds.

I will have to check whether the lighting imports correctly - you could try adding lights in max and I'll see whether they work, or at least their positions are imported, in Unity. Try to stick to just spotlights/point lights.

Gotcha

One thing you need to know is that all collision meshes need to be convex. If you have a part that cannot be accurately represented by a convex mesh, you can split its collision mesh into multiple convex parts. The wing, for example, can probably get away with one collision mesh. The cargo bay doors could be split into a few long boxes. Don't bother with collision for the flaps. Also, collision meshes should be as simple as you can make them without compromising on gameplay. Collision detection is the most expensive part of physics simulation. Also, if you don't want to spend the time creating a good convex mesh, Unity can create a default one that fits the convex bound of the mesh, though of course the auto-generated mesh may still be too complex.

-Tomorrow I will post a picture of the collision mesh for the cargo bay and wings, and you guys can tell me if I'm on the right track.

Same goes for the landing gear. You should only need collision meshes for the gear bay, the pylon and the suspended pylon, all of which should be as simple as possible (boxes should do). Wheel collision is handled by a special Unity wheel collider.

Hrm... ok I'll do boxes then and label them and you guys can point out which I don't need or you can delete them in Unity.

Also, at some point, you will probably want to put simple colliders in front of each window, as well as a camera, so that users can double-click on windows to get a better view out of them like in stock command modules, using InternalCameraSwitch.

Not a problem

It's best to keep collision meshes as low poly as possible, although with due regard for the underlying shape. (afaik) They also have to be convex, so for concave items (such as the cargo bay) you'll need to build a cage of convex meshes to fit it.

-Ok that's all easy

Thank you guys so much for the help, I'm 85% finished on my end. I'm trying to make things as seamless and easy for ZRM as possible. Think we can get a testing package by end of the week?

ZRM, you will have to add the Navball into the cockpit, are you able to do that?

Do you want me to model our own navball? My concern is the texture it uses. Hence why it is still missing. But I can tackle it if we want to use our own with textures that match your PFD display.

[Edit], you guys said that the complex objects can be more than one collider box. So all these collider boxes (like the "cage" idea for the cargo bay) can be one object? Or a bunch of separate objects linked in a hierarchy?

[ZRM]

Thank you guys so much for the help, I'm 85% finished on my end. I'm trying to make things as seamless and easy for ZRM as possible. Think we can get a testing package by end of the week?

ZRM, you will have to add the Navball into the cockpit, are you able to do that?

Do you want me to model our own navball? My concern is the texture it uses. Hence why it is still missing. But I can tackle it if we want to use our own with textures that match your PFD display.

[Edit], you guys said that the complex objects can be more than one collider box. So all these collider boxes (like the "cage" idea for the cargo bay) can be one object? Or a bunch of separate objects linked in a hierarchy?

I should be able to use the stock navball. We will see.

Make the colliders separate objects in a hierarchy.

Testing might be possible by the end of the week. It really depends on how much I have overlooked. The landing gear may take a bit of fiddling to get to work correctly, for example.

[TouhouTorpedo]

For collision meshes the thing to remember with convex colliders, is imagine wrapping your current mesh entirely in shrink wrap, so its all tight and taught. any open spaces aren't going to be accessible. This shrink wrap mesh if a Physics Mesh Collider in Convex mode. So get around this, you need to either split a mesh into lots of smaller meshes, or swap them out for lots of box colliders. Box colliders are the lowest work for the game, but it depends how accurate you want to be with these, especially on exterior surfaces. (don't bother trying to be too accurate on interior curves, you'd need a mad ammount of collision meshes)

You could likely get away with two mesh/box colliders for the doors. Obviously a mesh collider will provide better exterior impact characteristics, Interior you could perhaps get the box collider to work a bit better, since its easier to tweak.

For the Cargo bay I'd likely go for splitting your model mesh into FIVE meshes to use as colliders. two end caps, the lowest end of the wingbox, and two sides (which are cut quite a lot shorter than they really are, since they will expand when "shrink wrapped".

The landing gear you could get away with only two mesh/box colliders. One for the lower section of the gear, one of the landing gear casing. I used to add lots of colliders, but I found the behavior can be buggy when colliding with the craft. Basically, anything you animate through another part's collider CANNOT HAVE A PHYSICS COLLIDER. It can have a wheel collider I beleive - that doesn't seem to cause problems. Infact for the complexity you have here, I think you'd be better off making the lower gear collider an entirely seperate object that isn't tied to any rendered mesh, animated entirely seperately to the rest, so it never clips into the spacecraft body (animate the scale, leave it outside the landing gear case) as that'll stop clipping errors with the rest of the craft, as the landing gear will be sitting inside of the collider for the spacecraft body.

[The Czosnex]

The cockpit looks absolutely stunning, great work.

[helldiver]

The landing gear may take a bit of fiddling to get to work correctly, for example.

Woah woah, landing gear is already animated. What do you mean by that? You mean wiring it?

.

Alright, I'll take it step by step and post pictures, you guys let me know if it's legal or not. Since it's just boxes and no advanced texturing or anything like that, it'll be easy.

Man, this is the most ass-backwards thing I've ever done. Usually (like in UnrealEd, or Cryengine) the skin mesh becomes the collider mesh on export with little tweaking. Although you can make a collision mesh very easily by lowering the resolution of your silhouette mesh.

[ZRM]

Woah woah, landing gear is already animated. What do you mean by that? You mean wiring it?

No, I just meant making it so that the gear works without colliding with itself or having other physics-related problems.

Also, if you happen to have a tool for splitting a mesh into convex parts, you could use that to easily generate the colliders for parts.

[Marscommander]

Yes you're going to need ZRM's mod in order to run this. How far that goes I would have no idea at the moment. My goal is to make the shuttle functional in a one stop solution. I don't want to fidget was stuff, even if it means it requires a mod solution to be a part of it. Its flight characteristics as well as the engine numbers are all bound with the assumption of ZRM's avionics mod.

It was one reason why earlier on I had asked ZRM in his thread if his mod could be integrated into a part. For purposes of this mod it would have been integrated in the avionics portion.

ZRM will be taking over that portion of the project (coming up in the next few days). I asked him specifically to integrate it all with his mod. The goal is (my goal is) that the average user can download the mod and in just a few minutes with basic KSP launch, orbiting, maneuvering, and decent skills be able to fly this thing. That is my top priority and I'm not deviating from that.

Without his mod (and without proper numbers and flight envelope parameters) people are going to have a nightmare flying, launching, and putting this in orbit. I know, I tried.

Now the part I don't know (and I'm sure he probably doesn't at the moment) is if the KSO will have its own version of ZRM's avionics mod as part of it. We'll find that out once we start testing things in-game.

To clarify: I don't know if you will need KCA specifically. I do know, and I have asked ZRM to use something similar (or the same) to wire the KSO so that it flies properly both atmospherically and in orbit in a space shuttle (piggy back) configuration. He might end up programing an FCS using his KCA mod, I don't know. The ultimate goal again, is for the average non-advanced user to be flying this thing successfully 5 minutes after installing it. Maybe later we'll release a bare bones version without an FCS for advanced users of KSP.

I want my work and his work on the project to focus on cool add-ons to the shuttle; functional MFDs and IVA components, a mini rover, a mini roving vehicle, docking accessories, space station components that fit the cargo bay, alternate cargo bay segments like a crew module, expansion of the mission deck with lab stations, lift vehicle, and so on. I don't want to bog down the project with flight, center of mass, center of lift problems, drop rate, lack of proper flight envelope, and what have you, as to me that isn't fun.

I am perfectly fine with the shuttle using it, that is ok, but I don't want his mod to mess with my other craft. I am an advanced player and don't really want my craft to behave perfectly because I like the stock game.

[ZRM]

I am perfectly fine with the shuttle using it, that is ok, but I don't want his mod to mess with my other craft. I am an advanced player and don't really want my craft to behave perfectly because I like the stock game.

That's really quite easy to do. All you need to do is just not install the configs for my mod that add it to stock command modules. They're optional anyway. Then it would only be crafts containing the shuttle cockpit that are affected.

Edit: Besides, the mod does not control things unless you tell it to - control is disabled by default.

Edited August 15, 2013 by ZRM

[helldiver]

Alright, this should work I believe.

I did it really fast just to get the idea across. Note that it uses 6 "boxes".

I'm getting confused with the terms being thrown around, so I labeled the nose gear with the names I'm using. Simply point out which parts need a collision mesh.

[DANCRAD]

i have never modded or done anything to this respect but probably the wheel, wheel wall, and gear doors

[ZRM]

Alright, this should work I believe.

I did it really fast just to get the idea across. Note that it uses 6 "boxes".

I'm getting confused with the terms being thrown around, so I labeled the nose gear with the names I'm using. Simply point out which parts need a collision mesh.

Sorry about that. I really meant strut when I said "pylon". I was trying to think of the correct word, but it wouldn't come to me.

The cockpit collision looks good.

I think that the only collision required for the landing gear is the wheel well, olio and the strut casing. I think it should work if the wheel well has one convex collider (negating the need for collision for the gear doors), but I might be wrong. TT would be the authority on this.

Edited August 15, 2013 by ZRM

[helldiver]

YEah I was gonna ask about the wheel well, I'll do... 5 boxes? And link it in its hierarchy. If we put collision boxes around the doors we'll run into issues with the door colliders intruding on the wheel well colliders and possibly the cockpit segment colliders.

Ok, sounds good (ignore the convex portion of the lower side boxes in my first picture, I did it really fast and didn't pop out the vertices).

[TouhouTorpedo]

I'll give you a diagram later on when I get home in a few hours. Right now I'm at work and break just ended, lol. the way you've shown should work and let you do whatever you like with the landing gear, but wouldn't be that effecient.

[DisarmingBaton5]

I should be able to use the stock navball. We will see.

How about a black/white navball? That seems like it would look cool and not be too much of an eyesore; the stock navball might not really fit well with that cockpit.

[TouhouTorpedo]

Now this isn't a method I've tried, but it is something I believe can work well with what you are doing here.

the problem is that clipping animating colliders can be big trouble The much older aircraft landing gear in multiwheels are an example of this, they are quite the pain if you clip them with anything - whereas the newer dualgear pod only has a small box collider nearer to the wheels on the bottom of the olio, and the main one. The idea here above to allow the whole thing to clip and minimalise problems from the animating collider.

Adding a lot of collision meshes on the cockpit seems kinda wasteful when you've got a few more complex colliders to come on other parts - and if you're gonna go complex on the cockpit collider, theres some more interesting things you can spend the extra meshes on - as avoiding the "shrink wrapping" effect at the rear of the cockpit and over the window area, where anything attached or in the near vacinity is going to attach to a surface that isn't there.

Edited August 15, 2013 by TouhouTorpedo

[Marscommander]

Edit: Besides, the mod does not control things unless you tell it to - control is disabled by default.

The reason I was saying this is because I figured you can disable it but I wanted to know how to remove it from the other cockpits so that it is not a possible lag-inducing plugin that I won't really use for anything but the shuttle. Thanks! you guys are doing a great job, and I appreciate the feedback you have given.

[ZRM]

Now this isn't a method I've tried, but it is something I believe can work well with what you are doing here.

the problem is that clipping animating colliders can be big trouble The much older aircraft landing gear in multiwheels are an example of this, they are quite the pain if you clip them with anything - whereas the newer dualgear pod only has a small box collider nearer to the wheels on the bottom of the olio, and the main one. The idea here above to allow the whole thing to clip and minimalise problems from the animating collider.

Adding a lot of collision meshes on the cockpit seems kinda wasteful when you've got a few more complex colliders to come on other parts - and if you're gonna go complex on the cockpit collider, theres some more interesting things you can spend the extra meshes on - as avoiding the "shrink wrapping" effect at the rear of the cockpit and over the window area, where anything attached or in the near vacinity is going to attach to a surface that isn't there.

What is it exactly that happens when the colliders intersect during animation? Is there not a way to just disable the collision between the two colliders?

[Nazari1382]

I was under the impression colliders don't mess with other colliders in the same part, unless one is a wheel collider.

[ZRM]

I was under the impression colliders don't mess with other colliders in the same part, unless one is a wheel collider.

That's true. The problem that is being discussed is collision between the landing gear and the cockpit fuselage, which are separate parts. I suppose then, that we could just merge the landing gear and cockpit into the same part.

[Nazari1382]

here's what I would do. Same for cockpit area:

[OrianCEV]

can't wait for this thing!

[TouhouTorpedo]

Nazari,

Landing Gear Modules do not have Collision Enhancers. You are thinking of Wheel Modules. They operate very differently as far as construction goes and are technically non-retractable. The existance of a collsion enhancer would cause even worse problems than the ordinary landing gear module as now you have an actual collider (which a wheel collider is not a collider, its a raycast) which will intersect with the cockpit model. You're also missing the issue here - its not collisions internal to the part thats the problem. Its meshes on an animating part colliding with other parts in the vessel.

ZRM The suggestion of just plain combining the cockpit and the front landing gear module is probably the best one from the standpoint of if the cockpit is designed to only ever be used specficially with this shuttle, or nose gear configuration. Though you'd need to do this to wings as well. I'm not entirely sure if either cockpits or wings have full partmodule support (but then I haven't fiddled with either for some time, so don't let me stop you trying)

The problem with an animating collider intersecting another part is they will physically collide as is parts on seperate vessels. A simple example is any of the animated docking ports included in KSP stock. If you open one into the vessel it will clip and bend anything in the way until the animation is finished. Though the severity of this seems to vary. a very small, barely colliding collider doesn't seem to cause too much trouble. Big or multiple ones is a serious problem. Turning off some mesh colliders by plugin is something I've considered trying, but after trying out another method (a single, smaller collider that intersects as little as possible) I found it was effective enough to not need to do so. I've just yet to adapt everything I've made to do the same.

Another good person to talk to would be Snjo on this. I've mainly got experience with custom animating plugins and the stock animation module. Parts I've animated with the landinggearmodule I never tested for clipping - but I'm reasonably sure they are all running off the same driver.

[Nazari1382]

Nazari,

Landing Gear Modules do not have Collision Enhancers. You are thinking of Wheel Modules. They operate very differently as far as construction goes and are technically non-retractable. The existance of a collsion enhancer would cause even worse problems than the ordinary landing gear module as now you have an actual collider (which a wheel collider is not a collider, its a raycast) which will intersect with the cockpit model. You're also missing the issue here - its not collisions internal to the part thats the problem. Its meshes on an animating part colliding with other parts in the vessel.

Oh I wasn't missing that issue; my point was to use a bare minimum of colliders. He asked what he should use, and imo it is not worth it to even use colliders for most of those parts, much less try to intersect them or mess with complicated animations. If you have things running into the small pylons in the gear bay your ship is probably already gone. But yes I did mix up the landing gear vs. wheel modules.