Need to fill the gap between H-1 and F-1 engines, both in thrust rating and in position on tech tree. KLOX or Hypergolic. Already have several HLOX engines in that range; rs-25 and rs-68.

Options are (from: https://en.wikipedia.org/wiki/Comparison_of_orbital_rocket_engines ):

Including some of the existing engines in the range for comparison purposes.

Yea, sadly, mostly Russian engines. Which means lack of publicly available (english) detailed schematics and documentation.

Open to comments/suggestions as to alternative engines, and/or links to information on the ones listed.

The NK33 looks cool and at least has an AJ designation ;)

I have about 80% of an RD-180 sitting around (mesh, haven't started thinking about UVs/textures yet) ... much of it would be reusable for an RD-191 or 171.

NK-33 seems to have at least a few orthographic diagrams sitting around.

Maybe add a russian cluster and a single bell to entertain both options, like we have now with the Merlin vs RDxxx for the soyuz.

Are there any hydrolox engines out there between the RL10B2 and the J2? I patched an RL-60 using the RL10B2 model, but that is still closer to the RL than the J2.

HLOX mid-size engines -- surprisingly thin pickings from the easily available info:
BE-3 - https://en.wikipedia.org/wiki/BE-3 - only one on the wikipedia list (though it mostly only contains built/flown engines)

Hydrolox - LR87-LH2 maybe?

E: RL60 might be a more modern option (it hasn't flown yet, and at this rate may never)

@blowfishpro
Yea, your estimate of 80% complete seems about right. Could probably be worked into good shape in a few hours for the intended engine model (RD-180), and a few more hours for each of the other variants.

I've been feeling like taking a bit of a break from working on KSPWheel/KF for a bit, and this seems like something productive that I could do for SSTU (something that is currently needed even).

I've got some time off work over the next couple of days / through the weekend, and could possibly spend a day or two working on finishing off the model(s), at least getting them to the unwrap and/or texturing stage.

So, yeah, if you wouldn't mind packing that stuff up for me, would be appreciated. If you have images/schematics already I can certainly put those to use as well (I've got a ton of engine stuff saved already, but unsure about that specific engine). No rush though; if/when you have the time. PM through forums would work, or I can send you my email address for DropBox sharing, or whatever works best for you. Thanks :)

@blowfishpro do you have any plans for finishing up the RD-180 in the near term? And/or any objections to it being added to to SSTU (you would of course get full credit for the model(s))?

I might not mind finishing up the mesh and doing the textures/etc. Seems like a good deal if I could get all three engines out of it (with a bit of additional work, I'm sure).
The RD-190 and RD-180 fit very nicely in range of engines that I'm looking for. And having another heavy-lift engine option might also be good (esp. with it being quite a bit higher ISP).

I've been working on it slowly but haven't had much time lately. I would be perfectly fine with it being added to SSTU

Current state: https://p3d.in/G0lfe

Still a fair bit of work to done - a bunch of the pipes are still missing, need to adjust the fuel lines to work with the gimbal, add some details including bolts and some stuff on the gimbal actuators. And probably optimize because it's already 15k tris.

If you have time to work on it I could definitely send it to you, along with all the images and schematics I've been basing it off of.

That LR87-LH2 looks like a nice go-between at around 60% of the J2.

Re your kerlox engine list: No shortage in future modelling work, Mage ;)

.blend is great if that is the native format, otherwise .fbx, .dae, or .obj work.

Cool. Do you have a preferred format for the model?

Working through the RD-180 model now. Looks pretty good as is, quite a bit is certainly more detailed than I would have made it (but that is not a bad thing).

First up will be finishing off the turbo plumbing and cleaning up some of the other detail bits (joining meshes mostly; intersecting geometry bugs me for some reason). Should probably have that done in a day or two. From there it will probably be a short pass on model simplification, and the initial pass at getting the various bits UV-unwrapped (but not laid-out yet; that will come after all the geometry is 'finished').

Will be going with skinned / bone based setup for the fuel line baffles on this model I think (and on future models). Now that I learned how to set the stuff up while working on the KF tracks, I'm pretty sure I can get it all working -and- looking nice.

Feel free to re-do anything if it doesn't look right to you. Looking back at this model there definitely seem to be some things that I could have done better.

Re: SMRs - The areas that should require them are quite small - just the inner parts of two joints on each fuel line and the hot gas duct inside the gimbal. Though I guess the challenge is getting them set up at all, not that they're complicated. But since the areas in question are so tiny, you might be able to get away without using them.

Model is actually very well done as is. 95%+ will be unchanged/untouched. Just a few places with extra faces that don't need to be there, or meshes that could be joined for a savings in tris (and smooth shading). As a bonus I've already brought the model down to ~13.5k tris, and haven't even started on the actual 'simplification' pass yet (though I'll be adding a few back in for the new turbo plumbing I'm about to create).

Aiming to let the RD-170 come in at ~20k tris, ~10-12k for the 180, and probably ~7-8k for the 191. That is about inline with my other engines, that range from ~7-20k depending on the engine (multi-nozzle engines generally come in at the higher end of that range).

SMRs -- yea, just 4 small places that need it. 3 bones, ~200 verts total. Probably could be skipped on the top of the chamber, but the small lines running along the side will need something to allow for engine gimbal movement.

Edit: Render of rough geometry of the fuel and ox input turbo plumbing.

Next up will be the nozzle fuel distributor plumbing bits.

Edit2:
Nozzle rough geometry bits in-place. Need to do a bit more cleanup on the paths, convert to meshes, and do the manifold joins.

Wow, really nice work on that!

I think the moving bits of the fuel lines are even smaller than the part on top of the combustion chamber. Based on the images and diagrams I've seen, the fuel lines actually each have two joints, one for each axis.

Also, I suspect this part of the engine is a bit squished. There's a bulge which I neglected to model:

Updated render with the extra nozzle fuel attachment stuff in place. I think using the extra attachment bracket works quite well, and interferes less with the shading and geometry of the existing flange on the nozzle.

(Yes, I do love smooth-shaded manifold joins)

Edit: Here it is all together -- all plumbing is in place, all manifold joins have been done. The added plumbing brought it up to ~19.5k tris, but I might be able to trim that down a bit further. Seems likely that the RD-170 may end up in the ~25-30k range....

And a proposed modification that I would like to make in order to minimize the engine footprint -- turning the fuel input line to be vertical:

One thing I'm not able to figure out from the images is how the gimbal actuators should be rigged.

The problem I'm encountering is that when the gimbal is rotated, the connection points for the gimbal are no longer co-planar -- the actuators need some sort of ball-joint at each end in order to accommodate the movement properly. It doesn't appear that they can be rigidly bolted with only a single axis of rotation.

Will update shortly with some images detailing the problem a bit better. Seems likely that I'll have to rework the model slightly to accommodate this.

Locking gimbal actuator to a single axis (determined by the bolt going through the gimbal actuator attachment points):

The actual joint is above where you've put it, it's where the boxy part attaches to the mounting frame.

But still, it's a problem. I think this sort of issue is the case with every engine, though probably very pronounced on this series because of the large gimbal range. I'm not sure how it's dealt with in real life as it looks like each gimbal mount is really only intended to rotate alone one axis.

You may already be planning this, but I think there are a few more details that are worth modeling:

• Red: lines feeding the booster pumps. The oxidizer one is pretty visible on images and diagrams, the fuel one less so. But I believe it originates from the main fuel outlet - there is already a line going directly down to feed the booster pump, I think this one goes up (exactly opposite) from the same location.
• Green: Fuel line feeding the preburner. It appears to originate from the fuel booster pump (dome at the bottom of the turbopump assembly) at a 45 degree angle. I think the two long cylinders are hypergolic start cartridges (but the fuel flows through one once it is empty, the other delivers into the main combustion chambers)
• Blue: a couple more details on the main oxidizer line - another coupling and the main oxidizer valve extending down from the joint
• Orange: I think these are pipes that are supposed to be round (this should be a quick change)

Of course, feel free to veto any of these changes, they're just suggestions (or tell me to do them myself)

Re rotating the oxidizer pump: In my fiddling, I've found the actual mounting to be a significant barrier to clustering, so it might not be a huge deal. At any rate, the RD-191 will be available for more complex clustering setups.

Also, been meaning to ask. What's your workflow for creating pipes in Blender - I've tried a few things but I'm not 100% satisfied with any of them yet.

Oh, also not sure if it's worth putting some of the rings of bolts as actual geometry or not. I've seen a lot of other models in KSP do it, but much of the effect could be accomplished in normal maps.

Re: Gimbal - Yeah, I'll have to give it a bit more thought and take a look at a few more resources on it. Those bottom attachment points certainly seem to be limited to a single axis, but there might also be a bit of play in them (the bottom doesn't need much anyway). The top I haven't been able to figure out quite yet.

Extra geometry -- The model is already getting fairly complex, but with it being an engine that is fairly large and probably won't see much clustering use, it might be okay if it comes in a bit high on the poly count. The other Russian engines also came in pretty high, so nothing really new there.

• Red -- Will have to see what I can get of that from the other images I have, and can probably add those in without too high of a cost. Can't quite figure out the attachments from those images, but I'll take a look around.
• Green -- should be pretty simple to add those on (once the routing is figured out), they are pretty prominent on the images and diagrams. I had ignored them as they appeared to be instrumentation to me as I didn't see any connections anywhere.
• Blue -- shouldn't be a problem to add that one in, pretty sure I've got some good images of it, and can be a pretty simple addition as it shouldn't need any joins.
• Orange -- already done, smooth shaded the area, added an extra edge loop in the middle and rounded it all off a bit. Could maybe be made a little more round looking with some minor adjustments.

If you have a good idea on how some of those pipes are run feel free to add them to your existing model and re-send it to me, I can merge it the additions in with what I've done pretty easily.

Bolt modeling -- When I've done series of repeating bolts I always add them in on the normal map, doesn't look nearly as good as if they were modeled (unless you use a high-res normal map), but dozens of modeled bolt heads add up quickly. Examples of some of this on SSTU engines can be seen in the F1/B and RS-68 to some extent.

Retaining bolts, pins, or larger bolt features can often be modeled as there may only be a few of those on a model, and they can usually be kept to 6-sided cylinders (or less).

For modeling pipes in blender I use Path with a Curve-Circle for a bevel object. Allows you to do straight, curved, bends of any radius, control the number of faces dynamically, and about a hundred other options. It basically just draws a curve between a series of vertices that you setup, and wraps the resulting 3-d line-curve in a circular mesh.

It has also made making trusses and such dead simple, as you just set a vertex at the start and end of each truss beam, and it will figure out the rotation of the output mesh. No more fiddling with rotating cubes 'just right' (it can even do 4-sided 'circles'). Combined with the array, mirror, etc modifiers, it has cleaned up what used to be one of the most time consuming processes for me.

The downside is that it can be a bit high-poly if not converted to a mesh and cleaned up a bit, and once it is a mesh it is hard to edit. Once the model is finished, you always have to convert to a mesh in order to do UV unwrap and map, which again makes it hard to edit the piping past that point. It does however make very nice meshes that are easy to unwrap or manipulate if needed.

Let me know if you wanted more info on it; can give some tips or at least find some tutorials that would probably explain it better than I can.

Updated the second image, realized I had the colors flipped.

I'd actually argue that the red part is one of the most important, particularly the oxidizer boost pump feed line, since it is very visible. I'll try to get some of this stuff modeled once I get home on Sunday.

Good advice on the pipes, though I'm still curious how you control bends - do you just have 3 vertices for each bend or is there a more dynamic way to specify a radius?

Sounds good; I'll keep this thread updated with anything I happen to get done on it, so that we're not duplicating effort.

Curves -- Vertex influence can go as far out as 3-4 vertexes on each side from the apex of a curve; the mesh that is drawn does not directly follow the lines connecting the vertices, but is smoothed between them using a series of bezier curves. How close together the vertices are, as well as their positions, both go into determining the sharpness of the bend.

There are also a few other options for controlling the sub-division density (which is very high by default, far too high for game-modeling, but looks great for rendering), which greatly effects the output mesh. I'll try to put together a few screenshots with some of the options/examples for those, as it can make a ton of difference in the workflow.

Few images on the blender path/curve setup for piping, hopefully they are mostly self-explanatory on how it does the curve for various vertex layouts and 'resolutions:

Base path, with bevel freshly setup.

Moving the middle vertex outwards a bit to get a curve

Subdividing the two segments on either side of the peak of the curve, results in a more defined curve

Moving the vertices closer to the apex of the curve increases the sharpness

Some of the roundness can be restored to the peak by moving the peak vertex back a bit:

Moving the other vertices around also effects the curve near the mid-point to some degree:

And finally, adjusting the 'resolution' of the curve will set up how dense it is / how well it follows the vertices (and how high-poly the resultant mesh is) -- I generally find a setting of 3 to be good for piping on models intended for games (you will need to add more vertices to the areas you need smooth, but allows for a higher level of manual control on the resultant mesh density). The default of 12 makes really nicely smooth shaded pipes, but is very high on the poly count.

In the end I would say this is more of an 'artist' tool than an 'engineering' tool -- it is hard to get 'exact' outputs out of it, but it is easy to play with to get something that looks 'very close'.

Ah, good explanation. Not too far off of some processes I had used previously. I hoped there might be a way to specify the "straight" path and then specify a bend radius, either for the whole path or at each vertex, but it seems that isn't the case. But this method seems pretty reasonable.

Bit of work on some of the additional detailing:

LOX input boost pump lines:

Initial bits from the green-highlighted areas in images above:

Will continue to refine and update these images/this post throughout the day/as more work is done on them.

Just found (or rather, remembered about) this wonderful little site that has 3d models, right from Energomash: http://www.npoenergomash.ru/eng/dejatelnost/engines/models/#
Hopefully should give me what I need to be able to finish off the last of the geo additions.
(direct link: http://www.npoenergomash.ru/swf/180_out.swf ) - trying to figure out how to get the... mesh data from it....

Bit more geometry work on the additional geometry bits:

And the fuel-input boost pump line. I cannot for the life of me find any information on where it gets routed to. None of the images that I've seen show that bit of the engine, and the 3-d models available leave it unconnected.

Hopefully will start working on the UV unwrapping a bit later this week.

I made a few updates, sent you a new link to the .blend file

• I modeled the joints on the fuel lines. They should now not need any skinned mesh renderers. Each joint looks like it can rotate on both axes but it really only needs to rotate on one. I parented everything to the relevant parts of the engine itself, so it should be pretty clear what needs to rotate where (let me know if it isn't)
• I connected the the fuel boost pump to the fuel pump. Like you I wasn't able to determine the exact route of that pipe but I connected the endpoints in a way that is consistent with not being able to see it on any diagram
• Likewise, I connected the fuel pump to the start cartridges (vertical tubes on your previous pic). I didn't know exactly where you had them so the endpoint is approximate (it should connect to the one that goes into the preburner)
• Added a bit more detail to the gimbal actuators, joined the objects so hopefully what is supposed to rotate is apparent now. Tried moving the gimbal myself and nothing seems to get too far out of place.
• Built the approximate cross section of an Atlas V and added the main oxidizer line about where it should go. Definitely sticks out a lot but I don't see a way around that. At least there will be the RD-191 for clustering.
• Added one more pipe to the mid nozzle that I noticed was missing. Path is somewhat approximate since it kind of has some odd angles.

I think that does it for all the details I wanted to add. Feel free to veto any if you think they add too much to poly count without adding much to the model.

Excellent, taking a look over all of it now, should probably have it all merged in a bit later today.

Changes/additions all merged in.

Gimballing/etc all rigged up for testing. Can get it all working without SMR by using some interesting constraints setup, depending upon the intended gimbal range. Might still setup an SMR for the main input lines (the big ones, top of each engine), but can get them working without it. We'll see how I feel after I get a bit further in the process.

The gimbal actuators still need two-axis constraints (on both top and bottom), but it doesn't appear to misalign things too badly. After I get things cleaned up a bit more I'll send you a rigged/constrained model to take a look at to see if you have any suggestions on how they could be better handled (though I think what I've got setup should be fine).

Should be moving on to unwrapping the various bits today, probably take a day or three to get it all unwrapped, and another day to get the UV layout figured out. During both of those I will be spending a bit of time figuring out what all needs to be adapted/changed/moved/adjusted to allow for the two derivatives to be created (-190, -170).

Aiming to allow for use of a single shared texture sheet for all three engines, re-using as much of the meshes and textures as possible. The one sticking point, as always, is the AO bakes -- going to be interesting getting a correct AO that works for all three models without using unique UV mapping or AO baking for each model.

BE-4 is possible now, perhaps (2400kN):

Thanks, I'll have to see if I can dig up any diagrams/schematics on it. It is also a methalox engine from what I understand, which would require new fuel types/etc (or is that the Raptor? IDK, I don't keep track of the modern in-development stuff very much).

Even at that, I would say that it would be at least 3-6 months out.

It is indeed methlox. There is also the Be-4U version that is vacuum optimized with a larger nozzle.

If I see any better images, I'll drop them here for reference. I saw your "complaint" about most being Russian and figured that at least this one isn't, plus it's right in the middle of your thrust range. The plus is that ULA will also be using this engine for Vulcan.

I've looked at the BE-4 a bit, and these seem to be the best images available. Based on the images Bezos posted, the third picture shows the final configuration (vertical pump assembly, fuel/oxidizer inlets/boost pumps vertical on either side. A lot of the older images show a horizontal pump assembly.

At least the 2nd and 3rd images are orthographic perspective -- they could be used in place of schematics fairly easily. And at least on this engine (unlike the Merlins) there is only one main model -- was a mess trying to find reliable information on each of the Merlin variants.

Well, UV unwrap is progressing fairly well for the RD-180. Everything has a basic unwrap done, working through cleaning up the islands and joining back together as much as I can. Unsure as to the size of texture that will be used, won't know that until I start doing the layout steps. It is a large engine though, so chances are it will be at least a 1024x.

Sadly I don't think I'll be able to re-use a single set of UVs/textures for the derivative engines -- nearly the entire turbopump (and a ton of plumbing) will need to be rebuilt for each the derivatives, as well has having substantially different AO maps needed for each one. At least a good portion of the geometry and existing work should be re-usable though (meshes, unwraps), so should save considerable time over doing the derivatives from scratch. Doing separate textures will also leave room for engine-specific decals as a possibility (not that I put much text/many decals on my parts, but would at least be possible).

Unwrap done. Working on UV layout and a bit more cleanup.

Uv's went from:

To:

Tested a quick AO bake to see if there would be any problems (due to mirrored meshes/shared UV mapping), most things looking good as-is.

Hoping to get the layout finished today/tomorrow, and possibly start on the texturing over the weekend. Might have to spend a bit of time doing an updated KSPWheels/KerbalFoundries release, so we'll see.

Working through the UV layout now.

Looks like I should be able to use a 1024x texture for 128px/meter for each of the RD-180 and -170 variants. The -190 might be able to get away with a 1024x512. Still a bit lower density than I would like, but anything bigger/higher-res starts eating into the memory use very fast.

Hoping to get this finished with the layout today, and then can start on the texturing (and the rigging, part export, Part-Tools run-through, part-config, initial in-game testing, and effects setup).

Glad to hear! Let me know if you want help making the necessary changes for the RD-171/191.

The gimbal rigging might also require a bit of experimentation in this case. Might need some odd look at constraints to get working, particularly since there's a piece that's only supposed to move on one axis. I can experiment with this if need be.

Yeah, that's not going to be too much of a problem. I have axis-locked constraints available in SSTU -- which limits rotation to rotate around a single axis. Combine two of those (on different transforms), and you can create the type of gimbal setup as seen in this engine (have used similar on a couple other engines... one of the AJ-10s I think).

Not going to be straightforward by any means, but I know it will be doable as I've had it fully rigged and working in Blender (and I already know that SSTU constraints are fully compatible with Blender constraints).

Updated render with a bit more coloring work on it:

Updated completely rigged model hierarchy:

The 'RD-180-Gimbal' transforms will be moved by the stock gimbal module. They have the thrust-transforms parented directly. There is a 'target' transform beneath each gimbal that the gimbal rings and engine bells use for a 'look at' target.
The engine gimbal rings use an axis-locked constraint to only rotate on a single axis. The engine bells then use a constraint to rotate on the other axis.

Will be doing the initial in-game testing this evening I think. Model is fully rigged and ready for Unity/part-tools setup and export. Doesn't look like any further UV changes will be needed, so should be able to use the rigging/model as-is for the rest of the process.

Gimbal Rigging -- got it all figured out. The 'floating' piece of piping can be joined into the 'gimbal ring' as a single mesh -- they both have the same constraints/axis of freedom. The only piece that is still a bit in debate is the upper fuel input line (the big one on top of the chambers) -- likely will use some look-at constraints on it, the other option being SMRs (which seem like overkill for such a minor piece).

Layout finished up, first-pass of 'official' AO baking done, starting on the general texture coloring (still very early/WIP).

Yeah, organizing the meshes is easy, the question is how to get it to rotate correctly - the engine gimbals on two axes, but that one piece should only rotate on one.

Updated render with initial specular and normal textures:

Wow, nice!

:)
Still working through a few things on the coloring and specular textures, but that is about as good as you can get 'silver/metal' textures to look using the legacy specular shader setup (WTB: PBR shader support for KSP!).

Not quite finished yet, few more noise layers to add, more normal-map detailing on a few areas (such as taking a look at the bolt-heads). Few more areas that need some color contrast. Mostly have been basing the color scheme on:

while trying to keep to the same color-pallet as used on the rest of the engines; so some of the colors are not exact, but are the 'SSTU-equivalent' as it were.

I did get it in-game and working last night. Gimbals all rigged up and working as they should. Settled for a very simple rigging for the upper-fuel pipe that required neither constraints nor SMRs; I'm sure you'll see it when the model is released.

On a fun note, spent a good 3-4 hours last night tracking down a mesh-tangent calculation issue between Blender and Unity. It was causing horribly visible seams on the engine bell mesh where it had been mirrored.

Apparently this was caused by not properly splitting the mesh / marking sharp the edges on the bottom of the engine bell (where the inside and outside of the bell meet at the bottom). Not sure yet if they need to be split, or can be merely marked as sharp in Blender (result should be the same on the output mesh).

This was causing Unity to calculate the tangents for the mesh improperly (needed for normal-mapping), as it would try to wrap the tangents around the edge loop of the bottom of the bell, and couldn't figure out how to match up those tangents along the mirrored edge/seam.

Splitting the inside of the bell from the outside (duplicating the vertices along the bottom edge loop) fixed the problem of mesh tangent calculation; no more seams, and the normal mapping looks much better as well.

Posting this here for reference, as I'm sure I'll run into the problem again (and need to fix it on a few other models), and want to keep this information accessible/archived.

Doing a bit more texture work, and hope to have this engine added into this weekends release.

I don't think marking them as sharp in Blender actually does anything unless you have an edge split modifier. Maybe the modifier existed on one side but not the other?

If you enable 'auto-smoothing' under the mesh tab, marking an edge as sharp will export it in the .obj/.fbx as if it were two separate edges, with vertex/normal/tangent data for each each of the duplicated vertices. The trick there is enabling 'auto-smoothing' -- with that, you no longer need the 'edge-split' modifier, and can just use the mark-sharp edge/face/etc tools.

I've never used the edge-split modifier in my modeling work; using 'auto-smooth' and manually marking sharp edges has always given better results with very little extra work (and much more control over how things are smoothed).

For this particular problem, it normally would not have been a problem as I would have normally marked that bottom edge as sharp; but it somehow got missed during the rest of working on the model (it was already rendering as a sharp edge due to the auto-smooth threshold).

To be clear -- this isn't anything that you did wrong in the model, or anything with your modeling process/setup. It was merely an edge that I missed during the sharp/smooth setup process on my end, that caused some -really- weird side effects. Which is why I'm making note of it, so in case I ever see it again, hopefully I'll remember this post/solution.

Oh cool, I didn't know about auto-smooth. That will save me a lot of modifiers going forward!

First bit of (real) work on the -170/171 derivative:

A few bits on the turbo that need to be cleaned up, and some fuel lines that need to be reworked a bit (to split them off to the extra engines. The top of the turbo needs to be redone for proper placement/angling of the outputs into the engine chambers.

So far it looks like I'll be able to get away with re-using the same textures. So far. I still have a tiny bit of unused UV space in case I need a few new unique pieces of geometry, but there is not much room available there so hopefully it is only a few small bits.

Edit:
Nearly every fixed up, blue stuff is new geometry that needs unwrapped and placed onto the texture somewhere (re-use/new), and that is about it. Might be able to get the geometry end of it cleaned up tomorrow. Looks like I'll be able to get away with using the same base texture. A few spots that might require a new AO map, but I'm investigating alternatives.

Nice!

Let me know if you want any help messing with the piping etc. I think I can mostly figure out where things are supposed to go.

Worth mentioning - based on the pictures and diagrams I've seen, I'm pretty sure the RD-170/1 has two preburners (one on each side). But implementing this would require re-doing a bunch of the piping and/or AO around the turbopump, so maybe not worth it. (maybe this sort of obsessiveness is why I don't usually model engines) Looked at the dev model, you nailed the plumbing 100%. Just a few things remaining to be adjusted, I guess

To clarify RD-170 vs RD-171, my understanding is that the RD-170 only gimbaled on one axis (since it was used as a booster on Energia, it only needed to move on one axis). The 171 was a later variant used on the Zenit series and gimbaled on both axes but pretty much identical otherwise.

Hmm, the scale of the turbopump assembly seems off, I feel like it should be bigger (looking at photos). But I'm having trouble scaling it in a way that doesn't cause the engines to clip into the high pressure oxidizer lines (big ones feeding the preburners) when they gimbal. Any thoughts on this?

I used the same turbopump scaling as on the -180 variant, wasn't aware there was supposed to be a difference in the size (thought they used the same base turbopump with a few modifications).

Yeah, trying to scale/move/adjust much in there will result in one thing or another clipping, its all a pretty tight fit.

Edit: In the end, I'm okay with taking a bit of liberty in the model if it means easier modeling / lots of time saved. Just as the turbopump adjustments that I did are... close to what was needed... but were the closest that I could get without reworking major parts of the model.

So, I have the -171 variant all put together and in-game (in the dev branch). Few minor texture updates to clean up some of the AO, but I'm going to consider the model 'done' for now.

However the -191 (-181?/193?) variant is giving me some problems figuring out how to re-use the geometry much/at all. I've got a bit of a start on it, but likely going to take a bit of time to figure some of it out / fix some of the meshes. Hoping to be able to make some good progress on it later this week/weekend (probably more on the weekend; weeks are still insanely busy at work, leaving me braindead in the evenings).

In the forum I threw out a pic I took of an LR-87 on the back of a titan II missile, but the LR-87 is a very interesting engine. It was actually tested using kerlox, hypergolic, and hydrolox. The last was submitted for the Saturn upper stage, but they elected to have the J-2 built from scratch, instead.

The thrust levels are obviously in a range already available (1087 kN in RL for the LR87-7 in the Titan II, which is 445 in KSP). Still, it is remarkable in being built for all three prop types typically in use, which I find pretty cool (even if the hydolox variant was never used, unlike the other 2). Short of a coded ability to ne prop agnostic, it could either have "variant' as tanks do (if that is a thing with engines), or 3 engines for the price of one.

On a related note, the M-1 was never built, but is also an option, I suppose, which JoseEduardo added with nova pack, the SSTU expansion pack, though I think he used a scaled up J-2 as a placeholder. None the less, it's at least a plausible engine (there is one up to the end of the upper engine bell sitting in a museum), and is 6670 kN in RL, a little below F-1.

Vacuum thrust on BE-4U (upper stage variant) is listed as 2850 kN on a new BO powerpoint (1167 scaled to KSP).

No info on Isp or TWR though (for either variant)

Fuel flow and exhaust velocity don't completely determine thrust, even in a vacuum. You need to know the exit pressure and area as well

True, but the current values in the SSTU engine spreadsheet are below the known, current Merlin 1D figures.

Wikipedia says that there were two upgrades, which matches what I remember happening. Without a lot of citation, it gives these numbers:

Maybe other sources (including other parts of the wiki article) give different numbers.

In KSP, this could maybe be done with part upgrades. I'm not sure if they would play well with the SSTU engine cluster module, but only one way to find out I guess...

Tom Mueller interview up on twitch has some interesting Merlin 1D info that seems to change assumptions about the engine that are floating around.

Looking at the spreadsheet, the Merlin 1D thrusts seem to be different than the wiki page currently shows as well. The wiki says that the SLT is 723, and VT is 825 (the spreadsheet has 654/742). In 2016, they said they'd increase those numbers to 845/914. The twitch interview last week says (indirectly) that the thrust should be more like 1100kN based upon fuel flow and exhaust velocity quoted! Have to see what the actual data is on Block 5.

Raptor image for future reference.

Blue Origin Engines.

BE-3U

BE-4:

Nice; glad to see their renders are getting more detailed :)

Hopefully one day 'soon' I'll be able to get back to creating a few more engines. Was a different sort of fun doing the modeling on them.

Will the methalox engines actually run on methalox or just a tweaked kerolox to avoid adding new fuels, etc.?

I am so looking forward to some BE-4 and Raptors in game.