[WIP] R.E.L Skylon C2. Alpha Released. FAR config broken. (08 Dec 2014)

[nli2work]

I would just do a simple animation; call it with ModuleAnimateGeneric and let the player link it to mode switch with action group key

[CaptainKipard]

I have asked a moderator to move all the gear-related posts to the gear dev thread. Please keep all relevant discussion there for the benefit of others. Cheers.

[CaptainKipard]

Here's some progress. I've animated, imported and rigged the cargo bay in Unity. This shows the opening mechanism with which I'm quite happy.

It was inspired by the Space Shuttle mechanism.

I'm still learning about video capture and editing, which is why the windows looks weird like that.

Edited September 19, 2014 by Cpt. Kipard

[nli2work]

looks nice. you are paying a lot of attention to details, will pay off in the final result for sure

[CaptainKipard]

That's true. Given how sparse the rest of the plane looks I'm wondering whether I went a little too far with it. I had a look at other people's cargo bays and from what I have seen no one bothers with that sort of thing.

[CalculusWarrior]

I really like the mechanism that you've included; it always annoys me when a cargo bay 'magically' hinges open.

[Daishi]

That's true. Given how sparse the rest of the plane looks I'm wondering whether I went a little too far with it. I had a look at other people's cargo bays and from what I have seen no one bothers with that sort of thing.

I think the biggest factor for the other guys is just the lag that comes with detailed animations in game. One of the reasons i shied away from a similar sort of thing with the US doors, and just stuck with that simplified push-plate (which was just parented to the Rotate-Y keyframes on the door). Unity or PartTools doesn't handle complex animations very well, or so I've been told.

If you can in Blender (or haven't already done it), delete the channel data you don't use in each keyframe. In Maya, setting keys in the timeline adds a ton of data for every area of translation, regardless if it's used or not. For my door, only the Y axis keys are kept, as well as the minor X and Z translation keys for the initial "pop" of the panel getting pushed out the frame.

Although, this could only be a Maya quirk, and you could be animating everything in Unity directly (I should follow your threads more!). Ignore my advice where applicable

Looks great though!

[CaptainKipard]

If you can in Blender (or haven't already done it), delete the channel data you don't use in each keyframe. In Maya, setting keys in the timeline adds a ton of data for every area of translation, regardless if it's used or not. For my door, only the Y axis keys are kept, as well as the minor X and Z translation keys for the initial "pop" of the panel getting pushed out the frame.

I have two armatures in the Blender scene for this part (each with two 2-bone IK chains) each animated with a single controller empty. The Location keyframe generates values for all three axes. I guess I can delete two of the curves because the controller only moves along Z. Thanks.

The curves are very simple. Each only has three keyframes with some bezier handles or whatever it's called.

Unlrelated

Right now I'm working on the collision meshes for the cargo bay. I think I read somewhere that the limit for collision meshes is 256 triangles. I'm wondering if that's for a single collider or for the total of all collider components. The bay collisions need to be quite complex, and the total polycount of all the collision meshes already exceeds 256, and I'm not even finished.

@EatVacuum

If you're still up for this I could use some help with configs.

[CaptainKipard]

Here's a shot of the colliders for the cargo bay so far. This wasn't very easy, but....

... here's the underside of the cargo bay. It has a weird shape, which makes designing colliders for it even trickier. Any ideas?

[nli2work]

I'm worried about the kind of framerate all those colliders will eat up

[CaptainKipard]

I'm worried about the kind of framerate all those colliders will eat up

I am too, but I have no positive knowledge of how much is too much.

I'm not sure what else to do. The bay has to be hollow and there has to be holes for the doors and for the gear bays.

Edited September 22, 2014 by Cpt. Kipard

[Justin Kerbice]

I'm worried about the kind of framerate all those colliders will eat up

Easy: 1 FPS, 2 if you're lucky !

I've tried 16 colliders on 1 single part => boom, even in VAB, it was not playable at all !

(these colliders were not very complex, some were just boxes, but as far as I remember, I haves used a convex colliders from meshes, not sure on this)

Cpt, you'd better let your "accuracy frenzy" cool down, a cargo bay is good enough with 1 collider per side (5 for a box, + 2 for the 2 half-doors), don't waste your time in that path you'll be disappointed (or wait for a miracle from Unity !)

[nli2work]

Well, worth a shot. The IXS Enterprise ship appears to have pretty complex collider setup, it seems to have very playable framerates. You may have to break up the ship into smaller parts. I'd say 6 or 7 collider on a single part is about tops, that's when I start noticing frame rate drops.

[cxg2827]

I used 27 colliders (26 boxes, one half cone) on the aeroshells I've been working on in order to get the hollow center. with top and bottom aeroshell pieces (and cylindrical extensions) I had 80 colliders total for the 4 pieces. Didn't see a massive frame rate drop with that.

The DRA 5.0 lander chassis I'm working on will have a high collider count as well, and I'll be pulling that into the game sometime this week to start seeing how laggy it gets. But, from what I've seen with the aeroshells, it might not be much of an issue.

[CaptainKipard]

My keen sense of logic tells me that at least one person here is talking nonsense. But who?

@cxg2827 could you post a screen of your colliders?

@nli2work Why would that work? More parts obviously means more physics calculations.

Edited September 22, 2014 by Cpt. Kipard

[cxg2827]

Not near my computer, so here are the blend files:

https://www.dropbox.com/s/6xc2fzge47z09mi/3M%20Nose%20Top.blend?dl=0

https://www.dropbox.com/s/9gamnuy9sha52g2/3M%20Shell%20Top.blend?dl=0

[nli2work]

colliders per part is not the same as colliders per vessel. I start to notice frame rate drops in VAB/SPH with my command pods that have 6 or 7+ colliders, specifically convex mesh colliders in the upper half of the 255 triangle limit. It's slight, but noticeble; I haven't tested to see how many convex mesh colliders a single part can have before it's unusable. Once launched the frame rate improves.

Vessels can have very high part count and still be reasonably flyable.

as another anecdote, someone was asking about extremely poor frame rates in VAB with a solar panel part; turned out it was set to automatically generate colliders, and the design generated something around 30 mesh colliders. Once that was adjusted, the frame rates went back to normal.

but like I said, it's worth a try, like all things magical.

Edited September 22, 2014 by nli2work

[OrbitusII]

More parts obviously means more physics calculations.

Adding more colliders is not the same as adding more parts. It's just extra data for collisions and not extra data for Newtonian physics and whatnot. Adding more parts adds more rigidbodies (the physics objects in Unity) but adding more colliders doesn't. Managing the colliders is still a good idea, as too many mesh colliders will degrade performance more than primitive colliders will, but it's generally less severe than rigidbodies.

[CaptainKipard]

I'm still getting conflicting information.

Obviously less is better, so I'll simplify things a bit. There are also places where I can use primitives instead of meshes.

But about the breaking up of parts. Is it worth it or not? I can't tell.

I can detach the bay doors but that's about it.

[nli2work]

I stick to primitives whenever possible.

breaking it up depends, for what you have, a single piece of cargo bay that's not changeble in length it makes sense as one part. but if you have bays in sections, tubes essentially, you can eliminate the colliders on the front and back and let the builder close those up with other sections of the vessel. as for corners, and nooks and cranies, anything smaller than a kerbal doesn't need to have concavities with compound colliders, since they can't get in there anyway. so for example the armatures can be a simple box collider that encloses the entire volume containing its full range of motion as opposed to capsule collider on each arm piece.

[CaptainKipard]

I'm trying hard to optimise the colliders on the cargo bay. I have 28 meshes and 4 primitives at the moment. I think I can do better but that depends on whether or not animated colliders can clip through eachother on the same part and on two parts. Does anyone know?

[Daishi]

I'm trying hard to optimise the colliders on the cargo bay. I have 28 meshes and 4 primitives at the moment. I think I can do better but that depends on whether or not animated colliders can clip through eachother on the same part and on two parts. Does anyone know?

Yep they can, used to have them on the doors of the wedges and they intersected inside each other when closed. Never tried opening the doors against another parts though.

[nli2work]

colliders in the same part will pass through each other no problem, exception being wheelCollider which is a special case.

Door panels with colliders will push against neighboring parts if they are close enougu, the square B9 retractable docking port did that if you didn't give it enough clearance for the doors to fully open.

[CaptainKipard]

The cargo bay is functioning in game now: animations and all. Colliders work well. No noticeable framerate issues so far in the VAB or outside. Will keep an eye on it as I add more parts to the craft.

[hieywiey]

The cargo bay is functioning in game now: animations and all. Colliders work well. No noticeable framerate issues so far in the VAB or outside. Will keep an eye on it as I add more parts to the craft.

http://i.imgur.com/7eppOQY.png

Good to hear.