[WIP][1.8.x] SSTULabs - Low Part Count Solutions (Orbiters, Landers, Lifters) - Dev Thread [11-18-18]

[Shadowmage]

17 hours ago, Jimbodiah said:

Nice photoshoot Mage! STartin up KSP as I type...  Is that EVE/Scatterer or are you using something else?

[edit]Playing with it now... Maybe a 1.875 step size?  

[edit] Very cool!!!!  This thing is very cute, nice and tiny, makes a great addition. Already love it.
 

Last time I tried using a 0.625m step increment on parts, there was an uproar from a few users because 'now I have to click the increase diameter button an extra time!~!'.  I guess I should probably just do it and tell those people to ____ and deal with it (or they can always change their config if the half-step size really bugs them).

Yah, its a bit on the small-ish side, but I think it fits in quite nicely.  Still quite a bit of balancing to do on it... which I should probably get working on now that I've got the initial selection of pods in-game.

Really not sure how/if an IVA would work for those parts... but not too worried about it for the time being--will look into IVAs maybe sometime after 1.1.

1 hour ago, Jimbodiah said:

OK will do.  I've used them on the last release though, but this time the tanks were closer to each other, maybe that is the difference. I'll test some more and switch the damage off otherwise..

The new way of ejecting is a lot nice, no boosters overtaking the core etc and the glide away nicely. Thanks for that change!

Gotcha on the auto-decouple!!! Took a couple of passes of reading it before the lightbulb went on. Nice feature, I'll test it out right away.

[edit] Just tested it. OMG, this is so freaking cool!!!

And this happened after an abort   Funny!

Aye, I think the BPCs are likely too draggy, and thus have such a low terminal velocity that they do not often explode on impact.  Previously I had a drag-cube modifier on those parts to reduce it to 50%, which seemed to work well.  I had removed it from the SC-C BPC for...uh.. testing reasons... but apparently I should probably add it back in.

(BTW - the gray color is temporary -- it is because that part does not have any UV map or texturing yet)

[Jimbodiah]

Hah, I actually like the way it sticks into the ground

The grey suits the craft, but all-white would also be nice and stick more to the original.

Is there any chance of getting textures on the fairings/decouplers at some point? Or will they stay all-white (as in only a white texture)?

I've sent in PRs for the SAS torques. I've removed it completely from the OM as this is just a hab container, and the DM/SM combined have enough torque (even with my PR for lower ones) to turn the craft nice and steady. RCS seems fine for now, docking is smooth together with these SAS settings. Maybe smaller plumes, but I saw you mentioned being busy with the FX.

The LS supplies in the new patches are only in the OM/DM for the C series, to keep it a bit more realistic, and also for 3+3 days instead of 3+9 as with the A/B.

Having fun with the interstage decouplers, you get that Apollo feeling now when the entire fairing lets go while you fire the 2nd stage. I find myself running lower thrust rates and fuel ammounts, as with 100/100% you can actually propel your craft quite a bit dV-wise. Maybe make a rocket only out of decouplers

[Shadowmage]

First test of using a skinned-mesh-renderer for handling of the fuel-line deformation stuff; this is at a gimbal angle of 15' X and 15' Y, so far more angled/gimballed than the engine would achieve in real use (done that way for testing of extreme deformation).

 

Requires a bit of a change to the overall setup of the model, but might make for cleaner looking setups in the end.

[Shadowmage]

And as the skinned-mesh renderer stuff was apparently going nowhere useful

[Jimbodiah]

What do you mean?

BTW, was the 2-seat soyuz intentional? The original is a 3 seater?

[Shadowmage]

3 hours ago, Jimbodiah said:

Is there any chance of getting textures on the fairings/decouplers at some point? Or will they stay all-white (as in only a white texture)?

Not really -- massive texture distortion results on any procedural mesh when using anything but a plain flat-color texture.  A bit of noise is the best you can hope for -- horizontal or vertical lines are out.  Horizontal lines don't work because of the vertical scaling of the texture along the surface, and vertical lines don't work because of how quads get rendered as triangles when the radius' are different.

However, its all config based, so feel free to make your own textures if you want to try something out -- but I'm not going to waste my time making textures that would just look like @#%^ when rendered/used.

Basically, you can only get 'pretty' textures on pre-built parts; its not going to work properly for procedural stuff (unless... you want to actually employ me to spend the ~year worth of time to do the coding to support it... but as nobody is paying me, I'm certainly not going to spend that much time on a feature that...well... makes zero difference to gameplay).

7 minutes ago, Jimbodiah said:

What do you mean?

BTW, was the 2-seat soyuz intentional? The original is a 3 seater?

What do I mean by what?

 

Actually, the Soyuz was a 2-seater for many years.

Also... do you want to try and fit three kerbals in there?  Hint:  Even two fit very snugly, and not at all with helmets.

Additionally, having a three-seat setup early in the tech-tree would break stock balancing and progression.  The entire purpose of this series of parts was a low-tech-tree 2-seat command pod that sits inbetween the stock mk1 and mk1-2 pods.

[Jimbodiah]

What did you mean with the RS68, is what I meant with what do you mean

Kerbal's gotz big headz, I know. I just noticed when I wanted to send up 3 guys.

[Shadowmage]

1 minute ago, Jimbodiah said:

What did you mean with the RS68, is what I meant with what do you mean

Kerbal's gotz big headz, I know. I just noticed when I wanted to send up 3 guys.

Ohh -- skinned mesh renderers are apparently very bad performance wise.  Would be counter-productive for me to include them in a performance-oriented mod.  Perhaps if the goal of the mod was 'super-realistic models' it might be more pertinent; but as the goal of the mod is 'low-part-count performance friendly vessels (with better than stock detailing)', it goes directly against the theme of the mod.

As such, I had move on to working more on the mount geometry rather than wasting time on a feature that... I'm not too impressed with anyway (especially after seeing the performance implications, and the massive change to model setup).

Yes, using skinned mesh renderers might look a bit better; but is it worth the massive change to engine model setup (and additional work on top of an already work intensive model), and the increased overhead/decreased performance?  I don't think so.  The current fuel-line baffle stuff looks acceptable and as far as I'm aware is pretty close to how those lines would look when flexing (have never found videos of gimbal tests on engines that show good detail of the fuel line stuff).

[Jimbodiah]

Looking good is one thing, but if it is detrimental to cpu load, then not worth it.

[blowfish]

@Shadowmage What causes the performance issues?  I wouldn't think that moving vertex groups around would be that costly.  And the stock Panther jet engine uses the same technique for its gimbal.

[Shadowmage]

Just now, Jimbodiah said:

Looking good is one thing, but if it is detrimental to cpu load, then not worth it.

I'm going to do a bit of testing to see just -how- bad it is (when using 10-20+ engines in a scene).  Sadly, this requires that I fully animate and rig a model; export it through unity; get it fixed/working in KSP, and -finally- I can do some comparisons... *sigh*.  Ohwell, I guess I didn't want to get anything productive done today anyway....

[Shadowmage]

6 minutes ago, blowfish said:

@Shadowmage What causes the performance issues?  I wouldn't think that moving vertex groups around would be that costly.  And the stock Panther jet engine uses the same technique for its gimbal.

Its caused by a few things:

1.) Skinned mesh renderers are never batched.  One SMR = AT LEAST one draw call (possibly more with more complex shaders/texture setups).

2.) For -each- vertex that is manipulated, a new matrix transform and multiplication must be done, for each bone that is influencing that vertex.  More verts being moved = worse performance.  More bones per vertex = even worse performance.  For my fairly-detailed engine models, moving around 4-6k verts to animate the bell is probably a bad thing (and due to how armatures are setup, that is the only way I could find to animate the fuel-lines; had to animate the entire gimballed portion of the model).

3.) This is all done on CPU -- in a game that is already CPU limited due to phisics/joints/whatever the cause is.  Doubly bad.  If it did all the SMR calcs on the GPU I wouldn't stress it; but Unity apparently does them all on CPU.

4.)  Apparently using SMRs can -increase- performance in rare cases where the single SMR is replacing -many- previously distinct objects.  From the reading/research I've done, this is a rare case -- most real-use cases result in decreased performance when using SMRs, even when they are not currently animating.

As I stated in my last post -- I'm going to do some actual in-game tests tonight (hopefully; if I can get the rigs to work in Unity) to see just how bad the performance hit is.

 

http://docs.unity3d.com/Manual/class-SkinnedMeshRenderer.html

http://forum.unity3d.com/threads/skinned-meshes-performance-issues.261492/

http://forum.unity3d.com/threads/skinnedmesh-performance.25257/

http://docs.unity3d.com/Manual/MecanimPeformanceandOptimization.html

[blowfish]

@Shadowmage Thanks for the info, I think that makes sense.  Re (2) though, I'm puzzled why most of the bell can't be a regular mesh though - to my knowledge, any number of things can be parented under the gimbal, this includes bones.  What prevents the pipe (or even just the flexible part of the pipe) from being split out?

[Shadowmage]

Mostly I can't find a way in blender to parent an entire mesh to a bone and get it to animate the mesh deformation in object mode (bones only deform when moved in pose mode).  Honestly, I have no idea if it -should- animate in object mode; but as all my animation is done in object mode, that is the point I'm starting from.

E.G. I set up the vertex groups, and rotate the bell around its gimbal -- the bell rotates, but the rigged verts do not deform at all.  If I rotate the bone in pose mode, it will deform the verts, but then the bell does not get rotated around its gimbal.

 

 

[Shadowmage]

12 minutes ago, blowfish said:

@Shadowmage Thanks for the info, I think that makes sense.  Re (2) though, I'm puzzled why most of the bell can't be a regular mesh though - to my knowledge, any number of things can be parented under the gimbal, this includes bones.  What prevents the pipe (or even just the flexible part of the pipe) from being split out?

Additionally, splitting the pipe out into a separate object would increase the draw-calls; proportionate to the number of objects it is split into.

Ideally I will find a way to A: Parent the bone to the gimbal.  B. Only parent the necessary vertexes/groups from the non-gimbal mesh to the bone (resulting in those verts deforming as the gimbal moves).  C. Be able to rotate the gimbal as-per-normal and have that deform only those few verts (this is the questionable part, that does not work at all in blender -- I have to parent the gimbal to the bone, and then nothing works in object mode properly). 

[blowfish]

1 hour ago, Shadowmage said:

Additionally, splitting the pipe out into a separate object would increase the draw-calls; proportionate to the number of objects it is split into.

Ideally I will find a way to A: Parent the bone to the gimbal.  B. Only parent the necessary vertexes/groups from the non-gimbal mesh to the bone (resulting in those verts deforming as the gimbal moves).  C. Be able to rotate the gimbal as-per-normal and have that deform only those few verts (this is the questionable part, that does not work at all in blender -- I have to parent the gimbal to the bone, and then nothing works in object mode properly). 

My recollection is that it's possible to do that in Unity (maybe not in Blender), but I'd have to experiment.

[Shadowmage]

1 hour ago, blowfish said:

My recollection is that it's possible to do that in Unity (maybe not in Blender), but I'd have to experiment.

Apparently yes; while the stuff does not animate properly in blender, it will in Unity.  Doing an in-game test now to see how it holds up...

Found out a few things. 1.) If any vertex in a mesh is assigned to a bone; they all must be assigned to a bone. This is a Unity limitation; un-parented verts work fine in Blender.  2.) You can parent entire objects to bones; it just doesn't look like it in the hierarchy, and the methods to do so are a bit clunky.  3.) Wow.. the instructions/tutorials on this stuff... suck (esp. in regards to stuff that works in Unity).

After parenting the main bell to a bone, and the frame to a bone, I split of the fuel-line joint areas and made them into a separate mesh (single mesh for both sides, so only one SMR for the entire engine), and set the vert weights for the 32 verts that comprised the skinned mesh.  This is probably as optimal (performance wise) as this setup would allow.  It actually removes two distinct objects (the fuel baffles), and the code running their constraint updates.  So.. trade 2 regular renders + 2 active model constraints, for a single SMR; might be a decent tradeoff.  The gimbal actuators will still require distinct objects+constraints, but there has not seemed to be any problem with those so far.

 

 

Additionally, there is no noticeable hit from using quite a few engines (and tanks...) in a single scene (not sure how far I'de have to go before I could even go below FPS cap....).  Pretty terrible test... but... at least I know there is not any massive/dramatic performance hit.

My main objection is mostly to the change of workflow and model setup;  I'm not a fan of how the hierarchy doesn't look proper in blender, and it messes up quite a bit of my naming/hierarchy scheme that I've setup to keep these models manageable.  Nothing that can't be solved and/or re-learned given time... but I'm going to make sure that this is something I want to move forward with before I do.  Will be a lot of work to re-rig all of the existing engines (and do some minor texture updates for the new geometry), and I'm not sure I want to get into it that far.

 

Re: Fairing textures -- I mentioned that the textures are configurable, but I should probably mention that the UV-mapping is configurable as well;  currently only on a simple level, but I've set the mesh-generator up in such a way that it will be very easy to expand the functionality to more complex setups in the future.  However, as mentioned, it will be a ton of work to do so, and it is not anything I really want to get into at the moment.  Probably not a year worth of work, but likely a few weeks at least of headache inducing graphics math (which is why I delayed redoing the mesh-generator so long in the first place).

For now, you are more than welcome to try out other textures to see how they would look; they use the same UV map (by default-configurable) and layout that the stock fairing textures do (left side is the outside of the fairing, right side is the inside).

 

 

[Jimbodiah]

Pfff, I don't get past 30fps average with just regular parts. What kind of GPU are you running?

[RedParadize]

1: Skining t will slow down fps a bit, but definitively not as much as force calculation. I think its overkill for the purpose.

2: I will get +50 fps on luchpad, but as low as 15 fps when flying heavy rockets.

3: Soyuz is cool but ist too heavy to be practical. If you want to go "realistic" it should be Soyuz OM+EM+SM mass = Apollo CM mass. Since its 2 crew it should still be balanced.

 

[Shadowmage]

1 hour ago, Jimbodiah said:

Pfff, I don't get past 30fps average with just regular parts. What kind of GPU are you running?

[email protected], 24g ram, gtx-970 -- is my main gaming (and dev) computer.  Its not super high end, and all but the gfx are getting old, but it gets the job done.  Frame-rate doesn't stay that way for long though; I'm sure it would start to bog down if I lit those engines, or was trying to launch an actual rocket

 

42 minutes ago, RedParadize said:

1: Skining t will slow down fps a bit, but definitively not as much as force calculation. I think its overkill for the purpose.

2: I will get +50 fps on luchpad, but as low as 15 fps when flying heavy rockets.

3: Soyuz is cool but ist too heavy to be practical. If you want to go "realistic" it should be Soyuz OM+EM+SM mass = Apollo CM mass. Since its 2 crew it should still be balanced.

 

I agree on all points

Looking over the skinned-renderer stuff; its probably more than I want to get into, and obviously more than is needed (the current system works acceptably).

Yep; same here... and in-atmo is always worse than vacuum, with some of the supersonic region especially bad.

Yah, it is a bit overweight; the OM/DM combo right now is near the same as the A-CM.  I might be able to get away with that low of a weight for a 2-man setup, especially considering the low dV the SM will have (~380, or less, 350 sounds reasonable).  Will play around with things and see what I can come up with.  Lowering the mass on the DM should also help with its buoyancy issues (it sinks...).

[Shadowmage]

Yesterday consisted mostly of testing out the skinned mesh-renderer stuff.  Yes, it does work;  but I think I will be sticking with my existing method for dealing with fuel lines and gimbals -- the skinned renderers are just too much additional overhead on top of an already complex and demanding setup.  Perhaps in the future I'll revisit this feature; for now though I'll be staying with the existing system.

Rebalanced the SC-C OM/DM/SM to reduce the overall mass, decreased the RCS and SAS, and rebalanced fuel for the new mass to maintain similar dV.  Total mass of the entire orbital system is ~3.1 tons (not including BPC).  Should be launchable on a much smaller rocket now, and is much more fitting for its 2-kerbal capacity.  This brings them to a mass ratio of 0.44 compared to the real article (where the real scaled value would be 0.64*0.64*0.64 = 0.26), so still vastly overweight compared to a true-cubic-scaled mass balance.

 

However, this begs the rebalance of the SC-A and SC-B parts to bring them in-line with the mass balance of the SC-C parts. 

SC-A-CM - 5,560 kg * 0.44 = 2446.4kg  (or 2.5t); only slightly less than the 3.1 that it currently sits at, reduction of 0.6t
New Mass = 2.5t (total, including ablator, monoprop, etc)

SC-A-SM - 24,520 kg * 0.44 = 10788.8kg (10.8t) (total mass) -- 6110kg dry mass * 0.44 = 2668kg (currently @ 3.5t, reduction of ~0.8t).
New Mass = 10.8t total, 2.7t dry, 8.1t propellant

SC-B-CM - 10387kg * 0.44 = 4570.28kg (4.6t); current is 5.2, reduction of 0.6t
New Mass = 4.6t

SC-B-SM - 15461kg * 0.44 = 6802.84kg(total mass) -- 6185kg dry mass * 0.44 = 2721.4kg (currently @ 6t, reduction of ~3.2t). (yah, this thing is massively overweight for some reason...)
New Mass = 6.8t total, 2.7t dry, 4.1 propellant

 

Will probably work on updating those throughout the week, as well as fixing up the SC-B-SM RCS transforms to conform to the new system and improved control (esp during translation).

Edit: Also... cleaning up the geo work for the last previously started engine; obviously it is a WIP (still missing a lot of geometry, needs all the mesh joins, cleanup, and the low-poly pass):

 

 

Edited January 19, 2016 by Shadowmage

[Jimbodiah]

What engine is that? AJ family?

[Shadowmage]

J-2X

https://en.wikipedia.org/wiki/J-2X

[davidy12]

Just now, Shadowmage said:

J-2X

https://en.wikipedia.org/wiki/J-2X

Good to see you finally getting to this again.  

[Jimbodiah]

LOL, yeah, almost got it right, the J part anyway    Cool to see you are completing the set, now I can build a real Ares I/V set