Potential new SRBs (with models!)
blowfishpro opened this issue · 37 comments
An upper stage solid rocket is something I've wanted in SSTU for a while. Something with better vacuum Isp and maybe attitude control (roll during burn and all axes during coast). Would be useful for all-solid LVs as well as deep space probes where burn time matters (e.g. inserting into Moho orbit)
I came up with this: https://p3d.in/pQHt3 . Very loosely based on Orbital's Castor 30(XL). Still plenty of changes that could be made. The skirts could be shortened or eliminated entirely, for instance.
Code-wise, this could re-use a lot of the MUS stuff. Really the only missing part is the thrust-setting, which could be extracted from the existing SRB module so that it could be shared.
Could also do a version without gimbaling and RCS. Was thinking about doing something based on the star series of upper stage motors (e.g. http://www.spaceflight101.net/uploads/6/4/0/6/6406961/4827946_orig.png).
Was also interested in a lower stage solid nozzle with roll control. Came up with this https://p3d.in/F0yAW based loosely on the Minuteman series of ICBMs.
I am prepared to do the rest of the work to finish these myself, so I'm mostly wondering if you'd be interested in including them in SSTU.
I have no problem with the parts / models, the first model you linked is looking very nice.
However I'm quite leery of using the MUS module for anything new. I've actually been trying to find a way to deprecate/remove it entirely and unify those parts into the MFT tank sets (to unify the model and texture-set handling across all of the tanks). The sticking point is, of course, the RCS thruster handling.
A better method would be to use the existing MSRB module -- but then the RCS thrusters are problematic (oh why do stock modules have to be such a PITA to work with?), as they need special accommodations in order to not break when models/meshes/transforms are swapped around.
Don't the upper stage tanks use a different method to set the length? My understanding was that the regular tanks use different models for each length whereas the upper stages stretch the middle part of the tank? I think the second method would work better in this case because for upper stage solids you probably want more control over the amount of fuel.
It sounds like maybe the modules could just be broken down further so that the common parts can be reused.
@blowfishpro - Yes, the MUS uses scaling to adjust the middle tank length, whereas the MFTs and MSRBs use a multitude of pre-compiled models for each tank/body length.
The MUS module however lacks the SRB thrust/curve features from the MSRB module, so there is also that to take into consideration.
It does almost seem that I need to find a way to split out some of this modular-part functionality into either helper classes, a generic/abstract parent class, or even separate inter-linked part-modules. With a KSP update looming, if there were any potential craft/game breaking changes to be made, now is as good a time as ever. I'll put a bit of thought into it and open up a separate ticket for general discussion of that work.
Anyhow, back on subject, yes, I'm quite fine with adding a few more SRB models, especially some upper-stage types; I'm sure we can get the plugin/module details sorted out one way or another.
@taterkerman - I'm quite alright with the parts themselves, at least the concept and functions; its the implementation of the module and model setup that I've grown to... dislike (distrust?). It has made it a bit difficult to implement simple things such as texture sets or swapping top adapters.
I'm not suggesting scrapping the parts themselves, but reworking the model(s) to use the MFT module or a derivative. As the MFT module already supports 'V-scaling' of the center section the only bit that would be a bit odd would be scaling on the split-tank interstage mesh, and some distortion on the normal-maps; these could be limited by offering 3-5 pre-compiled lengths in addition to the scaling (similar to some of the current MFT variants).
The last bit is the RCS support, which I have a few ideas on that might also allow for interesting setups such as swappable RCS ports. If the idea turns out to be workable, I may well include the RCS-port bit into the MFT module code, and include a selection of vernier engine models as well for use on lower stages. The key sticking point will be if the RCS module can be cleanly disabled when there are no models present.
When I originally implemented the MUS it was before NathanKell (I believe) reworked much of the RCS code and made a ton of general modding improvements to the KSP codebase. It is entirely possible now that I might be able to access the data that I need in order to cleanly swap models/thrust transforms without it crashing the game.
If/when I get to all of that I'll open up a separate ticket for the general discussion. Quite a bit to think about in there, along with some of the other potential code-side developments to consider (e.g. the discussion on shaders for texture reduction).
My initial plan was just to extract out the thrust-setting part into its own module which could interact with the SRB module or the upper stage module, but more modularization could definitely be done.
I actually use the MUS parts (mostly the small one, not the EUS looking ones), and mostly for the simple reason that it has RCS.
On the one hand, making physically smaller versions of the current RCS parts would remove the need (strictly speaking) for the MUS parts, RCS tends to increase part count a lot, since it's almost always 4 at a time.
Another issue with RCS (stock problem) is that it fights with SAS.
Getting back to thinking on this setup a bit -- I'm curious on how you would propose to code the 'engine thrust manipulation module' in a generic setup, and how it would interface with the rest of the modules' on the part.
One thing of note is that I already have abstracted out the majority of the engine-thrust updating code into a static utility method. All it needs is to be passed an engine module and a min and max thrust and it will handle all of the module thrust updating code. ( https://github.com/shadowmage45/SSTULabs/blob/dev/Plugin/SSTUTools/SSTUTools/Addon/SSTUStockInterop.cs#L118-L126 )
What this would mean is that mostly all that would be needed would be to add a bit of engine-updating code to the MUS module.
This is where I become a bit hesitant -- I really don't like how the MUS manipulates the models (stretching), and am fairly certain I'll be replacing it with a precompiled model setup as per the MFTs/other modular parts. The biggest part that I'm not fond of is how I had to split up the models for the part; the 'upper tank' alone consists of four separate models (dome, upper ring, center, lower ring). I'm not sure that setup would be compatible with your SRB models without needlessly splitting them into extra sub-models/meshes.
The one problem I'm running into while trying to think on how to rework those parts to use precompiled models is how to keep the precision that the vertical scaling allows. About the only option I can come up with would be to still allow some vertical scaling, but somehow only scaling specific transforms/meshes within the model (specified in the ModelDefinition). Would be a bit like the SUBMODEL setup, but would specify what transform receives scaling, and what other transform(s) need to be adjusted when the main transform is scaled. This is only a concern with the 'split-tank' upper stage tanks; how to allow for scaling of the 'tank' sections, while not skewing the mesh for the 'intertank' section.
After that bit is sorted out I can investigate how to add RCS (and engine) module interaction support to the base MFT module in such a manner as to not have additional overhead when the RCS/engines are not present. Shouldn't be too hard to do that end of things.
The goal for all of this, of course, would be unification of all of the ModularXXX modules into either a single base class that can have derivatives created for special functionality, or a generic base class that can interact with small external modules for added functionality (e.g. the nozzle gimbal support for SRBs could be moved to a separate module, or have that code be in a subclass).
What I had in mind was a separate module that both the SRB module and upper stage module could optionally talk to to a module that dealt with thrust setting.
Not sure what the optimal way to split things up in general is though. On the one hand, I think that having a bunch of separate modules talking to each other could work quite well, but on the other, I have heard that adding to the number of MonoBehaviour instances (of which PartModules are) to the scene can have an impact on performance.
Currently working through adapting the SSTU-ModelData / model system to allow for 'compound models' that allow for vertical-scaling of only specific transforms.
This addition, once completed, should allow for a much cleaner implementation of the MUS module, allowing for use of code very similar to the MFT tank module as far as model-data handling and setup/positioning/scaling goes. The MUS tank-model sections will be able to be combined into a single model and treated as such in the code. Nearly complete with the prototype implementation, will then require a bit of testing with some prototype models before I start on reworking the MUS module into its new form.
The goal is to allow the MUS parts to use the MFT module, or possibly a derived subclass with minimal overrides for updating RCS model scale/position/thrust and fairing position data. (Still haven't found a clean way to handle RCS and engine interaction in a generic fashion).
I'm also contemplating rolling RCS and engine module interaction support into the MFT module as well. Haven't quite worked out the specifics of how this would work yet, but have a few ideas that warrant further investigation.
One of the major points on this investigation will be to figure out how to get the stock ModuleEngines and ModuleRCS to not crash/error when the thrust transforms are not present on the part, and to get them to work properly with the 'moduleIsEnabled' stock status flag. (might not be possible, ModuleEngines doesn't use that flag at all, and ModuleRCS doesn't bother to check the flag before trying to setup thrust transforms and effects).
The goal for this would be to allow for 'service-module' type fuel tanks with integrated engine and engine switching capabilities (and specifically to allow for the engine to be removed -- Hmm... can I safely -remove- a part-module from a part at runtime? Might be a solution to disable them when not present). RCS functionality as well -- would love to be able to add an 'RCS' model-data module to the MFT tanks that can optionally be enabled, for use as verniers/ullage or additional upper-stage RCS options.
And the overall goal for all of these changes is to have a single unified module that can function for standard fuel tanks, upper-stage tanks, modular boosters, and possibly even the station-core parts.
Cool. Given that goal, it makes sense. I was going to say that for service modules, being forced to have 2 parts instead of 1 (SM tank, plus engine cluster) is not terribly draconian :)
Compound models stuff is mostly working. Tiny bit of cleanup work to do on it, but 100% confident I can get it working as it needs to. Will allow for much cleaner use of partially-scaleable models such as the MUS tanks or the proposed SRB. They can now be used just like any other 'model-data' based model, in a manner fully transparent to the PartModule that is manipulating them. Good stuff.
Working on figuring out a generic system for RCS module interaction that I can easily integrate into the MFT module. Think I nearly have something workable, but likely a few edge cases to clean up. The idea is that the module is present in the part.cfg file (and prefab part), and the module removed from the part instance if the RCS model-data is disabled.
Hoping to do the same for engine-module interaction. Not sure what kind of 'gotchas' I'm going to run into on these, so might not be workable... but seems like the best place to start investigating (after all of my other... failures... on runtime module-switching).
For RCS, it might be easiest to either
- Have it on some parts but not on others.
- If it is togglable, have it not be there by default but add when it's needed. It's probably easiest to not have to worry about how that module is going to initialize when all the things it needs might not be present.
One bit of good news in this department is the development of the compound-model setup for model definitions is finished. This allows for only specific portions of a model to be effected by vertical scaling. Important for allowing for some detailing on the body sections to not be distorted. Entire thing should be transparent to the module that is using the model, and the compound-models should be usable in nearly any of the modular-part modules.
With that bit implemented and working, I think it would be fairly easy to add a 'body scale' control to the existing MSRB part-module. It could be optionally enabled through the config through various means, including specifying min/max scales that can be applied. This can even be applied to the existing MSRB body models to some extent, probably with a much smaller range of scales.
The last bit that would be needed would be the RCS support. Certainly doable with multiple options for implementation. I haven't done any further investigation on module-switching/dynamic add/removes, but it really doesn't need to be that complex, certainly not for the initial implementation. An external module that handles the RCS-module updating functions would be workable, or possibly even just a few static/extension/helper methods. Often I get too caught up in trying to make code and systems re-usable/generic, and this seems like it is one of the times where it is getting in the way of actually getting things done.
@blowfishpro
It currently looks like I'll be working through the MSRB module (and parts/models/textures) within the next week or two in order to add support for the recoloring system. I will add in the main-body scaling features at that time, and make sure that the module can support rcs-module updating in one fashion or another.
If you are still interested in developing these new SRB parts I'll work with you to make sure all of the needed features are supported and get the model setup figured out. It has taken awhile, but I think all of the pieces are finally coming together to make these a reality :)
Sounds good, I was kind of waiting for the dust to settle a bit before I started UV'ing stuff, but it sounds like now might be a good time to start.
Yeah, hoping to have the MSRB module reworked and updated by the end of next week.
Looks like adding in RCS support shouldn't be too difficult with what I've learned while reworking the MUS. If desired we can even make it configurable/toggle-able (if you felt like making two mounts; one with rcs, one without).
As I've finally finished the textures, going to close this issue.
@taterkerman feel free to open a new issue regarding the engine renders if still interested -- probably a few other parts that could use decent quality renders.
(more or less) final lineup of upper stage SRBs:
All are partially UV'd but changes are still possible
The quad nozzle lower stage still exists but I'm separating it for now.
Question regarding texturing: I did a bit of texture work years ago but (a) It was in Photoshop and (b) I never really got very good. So for consistency would you like the textures to be in Gimp, or does it not matter to you. Do you have any good texturing tutorials you'd recommend?
That quad base would actually make a good addition to the current SRB?
I there anyway to turn the current SRB into an MFT in terms of mount choises; some with main core mounts and some with fairinged uperstage mounts? If you shorten the SRB a few steps, you could make it into what blowfish is looking for perhaps? The other nozzles look like existing versions but with the ability to add fairings.
@blowfishpro If you have the geometry finalized, I can probably pick up the UV and texturing work from there. Easier for me to do textures if I also do the UV's (which also allows me to make sure they will be able to use the various mask setups).
@Jimbodiah No, not really possible. The MSRB has very specific requirements for the setup for its 'mount' (nozzle) selection. Notably, the nozzle needs to have built-in gimbal and thrust transform(s); without these there is no thrust.
Edit: Apparently I misread your original comment (mount vs. nozzle). Yes, a single MSRB should be able to have both upper and lower-stage nozzle types. The fairing setup would be similar to the existing engines/etc, where it will disable itself when used with the lower-stage type nozzles. Fairings = easy; RCS = uhh...no clue yet :)
I'll look into what it would take to add (optional) fairing interaction to the MSRB module; currently it is not designed with fairing use in mind, but I can probably adapt some of the MFT code easily enough.
Also still need to figure out how to best handle the integrated/optional RCS ports. This is more problematic for me, as I really don't like leaving modules in the part if they don't have to be, but cannot think of any 'clean' way to implement the feature (the upper-stage MSRB will always have an RCS module, but it will be disabled/use dummy transforms when a non-RCS mount is selected).
The other option is to have a completely separate part for the RCS-enabled version... but that comes with its own downsides.
Could there just be a vacuum optimized solid rocket, and a vacuum optimized US? The US would be rather like the US tank we have now.
Alternately... could this version be a new fuel type, and then use an engine that burns that fuel? Then you are adding a new upper stage look, and pick solid fuel and throw on the vac solid engine? For no RCS use a regular tank with the fuel switched to solid?
@taterkerman I don't think you can get SolidFuel to flow like that; it is almost hard-coded to not allow fuel flow (it can be over-ridden through configs/patches, but is game-wide; cannot be applied to just specific parts).
You could have a single part MUS-with-integrated-engine though, and still allow for switching between solid/liquid fuels (or different solid fuels even). Well, not with the current plugin/code, but aside from that I don't see any technical problems stopping it from working. I don't think that I'll be doing it though, at least not in the near term as I simply don't have the time to be digging into that level of coding currently.
Gotcha, I was trying to think outside the box... but in a situation where I don't really know anything about the box. or the existence of boxes. Or something ;) .
No worries. More ideas and are rarely a bad thing; quite often they have led to the development of new parts or features that I had previously not considered.
I believe the models that @blowfishpro has created will serve the needs of the solid-fuel upper-stage SRB quite well. It won't be integrated into the MUS/etc, but it likely will be its own separate part (SC-MSRB-US or similar). As with the MUS though, it will use vertical-scaling of the model to allow for much finer control over the fuel quantity/burn-time.
Just gotta get the RCS bits sorted out. Likely will do what I did with the MUS and just leave the RCS module in the part all the time, but disabled when there are no RCS ports. Less than ideal from an efficiency/performance standpoint... but I don't think the disabled modules should add too much overhead (hasn't been a problem with the reworked MUS as far as I know).
Hopefully soon I will start getting a bit more free time to work on this stuff :) (soon being a relative term; still looks like I'm in for at least a few more crazy weeks at work, the transition we are going through has been anything but smooth....)
RCS support -- should be added, but untested. Mostly copy-pasta'd the MUS rcs code, which was surprisingly easy to transfer -- was not as interconnected as I had feared.
Fairing support -- WIP, should get it working (or at least implemented) next time I can do some coding work. Again, mostly copied from the MUS code.... but there were a few more things that will need cleaned up for this one.
Yeah, RCS seems like a challenging problem, not just with the existence of the RCS but that one of them has roll-only RCS. I was kind of expecting to have to make them separate parts.
Hmm... honestly... I think I can handle that through config/code as well. Few more fields to load and store in the srb-nozzle data structure, but it already has fields for other rcs-related data, so I don't think adding a few more bools for the axis stuff would hurt much.
The new nozzle configs would look something like this (all fields defined, can omit to use defaults)
//nested inside the SSTUModularSRB module
NOZZLE
{
name = Nozzle-SRB-US-A
thrustTransformName = SC-ENG-MOUNT-SRB-US-A-ThrustTransform
gimbalTransformName = SC-ENG-MOUNT-SRB-US-A-NOZZLE
gimbalAdjustRange = 0 //in-editor offset range for the gimbal
gimbalFlightRange = 2 //in-flight actuation range
hasRCS = true // default = false -- controls enabled/disabled status of RCS module (if present)
rcsTransformName = SC-ENG-MOUNT-SRB-US-A-RCSThrustTransform //or something shorter... whatever the transform is named in the actual model.
rcsPower = 1 //default = 1, some nozzles might have more powerful/less powerful rcs?; specified at default model scale (2.5m? 5m? will figure it out)
enableRCSYaw = false //default = true
enableRCSPitch = false //default = true
enableRCSRoll = true //default = true
enableRCSX = false //default = true
enableRCSY = false //default = true
enableRCSZ = false //default = true
// anything else that needs per-model differentiation?
// fuel types for RCS would be doable but complicated, might consider for in the future
//
}
Could move some of that off to the SSTU_MODEL node for the nozzle, but it would really just be to cleanup the part config (and very minor memory savings).
Could also port some of that over to the MUS code for use on its RCS setups as well.
@blowfishpro Do you have those models to a point where I could use them for prototypes for testing of the module code (rcs, fairing, v-scaling)?
I can always throw together some quick prototypes myself, so no worries if they are not quite there yet.
Excellent, thanks :)
Looks like that has everything I should need to get them working for testing.
Getting them finished up will probably take awhile for textures, but these will likely be the next models that I do texturing for.
On the texture subject -- did you have anything specific in mind for these parts? I would like to re-use one of the existing textures for the body if possible, though the nozzles will likely require an all-new texture.
Yeah, the middle section was basically intended as a placeholder for the existing MUS-CB body. I guess it follows that the rest of the textures should look similar.
Here's what I currently have:
https://drive.google.com/file/d/0BwOUWbxCxiu_VFJULWwzRlBrcFE/view?usp=sharing
pretty much every bit is unwrapped and the overall scale normalized but not laid out as a whole. Feel free to change anything as you see fit of course.
@blowfishpro any thoughts as to what the starting / upgraded ISP should be for these SRBs?
For bodies I have gone with the two MUS tanks, as well as some of the MFT-C tanks (no side piping, smooth body). They all have the full range of MFT texture sets available. The thrust is scaled the same as it is for the SRB-A part (roughly 20kn for every m^3 of fuel volume).
Adapted the plugin code so that the SRB module has a 'support tank' slider similar to that in the MUS. It auto-adjusts/disables when there is no RCS on the selected nozzle. The RCS module itself also gets disabled when a non-rcs-equipped nozzle is selected.
I'm inferring that these are intended to be cold-gas/monopropellant thrusters? (only a single propellant tank on the nozzles).
@taterkerman
Renders of the SRB nozzles? (yes, can do, just making sure I'm doing the right stuff :) )
Hmm... I think I'm going to have to learn blenders cycles rendering system to setup the materials for those... because the actual textures used are flat gray and quite boring (and would take quite awhile to make new textures just for renders). However, if I setup the material properly, I should be able to get essentially the entire recoloring system working within blender.
-- reminds me that I should also add renders for the rest of the engines that are lacking individual high-res renders of the finished models.
I was just thinking of matching the other images in the wiki. Alternately, I could take screen shots, the phtotshop out the background (maybe use a huge tank and a green screen), and make the image float that way.