DangerouslyDave

Hmm, I'm not able to replicate that problem. Yes, the thrustTransforms on the RCS module should be "RCS". Let me know if the problem persists- I'll look back into the Unity project. On another note, I've added 1m fuel tanks to the repository. Please take these with a grain of salt, as they aren't built for the current shaders. On the bright side, they stack really well with one another. I've left markings on the 2 larger tanks, as I figure you can duplicate the 2 smaller tanks if you want a clean, seamless appearance.

You beat me to it! I've updated the repository to only include the necessary parts of SSTU, down to 2.2MB. Also switched the textures out to DDS and updated the CFG file for the pod. I should have a set of fuel tanks up this evening if life allows, and hopefully an engine or two over the weekend. Another question: Would you rather see more new parts (filling out the rest of the 1m parts and some new science parts) or IVA's for the existing pods?

Awesome, thanks for directing me their way, that was exactly what I was looking for! A humongous thanks to @Shadowmage for the use of their plugin! I finally got the first part working mostly/fully in-game. Here's a download link to the work in progress: https://github.com/DangerouslyDave/StockRefresh Please note that for now SSTULabs is required for some of the parts to work. Right now the only part available is the command pod based on the Dragon capsule. I'll be adding additional parts as soon as they're ready. Please let me know if you tried it out and encountered any issues.

@ShotgunNinja Thanks for the thorough explanation! The take away seems to be that deferred decals aren't possible in KSP. That's a shame but it makes sense. I'll have to be smarter about combining parts to minimize the performance impact. Looking at @Ven's project boggles my mind with its efficiency. I got some feedback from @Dragon01 that rang true to me, so I went back to revise some of the parts. To force forward progress though, I got the revised parts working in game. I'll be releasing some of the parts soon if people are willing to test these things (knowing that the PBR shading aspect is still waiting on 1.2). Let me know. Here's a couple of the revised parts to keep the image quota up: And another question to the room: Is there a way to add parachutes to a command pod part? It seems that if you add a ModuleParachute to the part's config file, it changes the entire part to be defined as a parachute. In the image directly above, I'd like to have the panels labeled "Contents under pressure" blow away and build in parachutes underneath. Not sure if this is possible. Thanks!

Hello again. Sorry for the long absence, but things are back in action. The 1m fuel tanks and 1m decoupler are now complete. The design of the decoupler loosely pulls from the separation points (excuse my ignorance of the correct terminology) on the Falcon 9 (see their official Flickr account for reference). I'm still working out the kinks in the materials, but I've finally landed on a 'space grey' with the right amount of specular breakup. This, and different shades of the same material, will be the backbone of future texturing endeavors. Please note that I'm using a new rendering engine that's a bit more noisy- it might be obscuring some of the detail in the shadows. In case you haven't been keeping track, with these parts complete there's finally a complete set that could put you in orbit and beyond (with no way of safely landed quite yet). Please excuse the tall image here, but I wanted to give a preview of what an assembled rocket might look like: @Zarbizaure Glad you figured it out! Sorry I didn't get back quick enough. I might make a longer post elsewhere about this and other workflow things if the other resources are well and truly gone. @CobaltWolf Is there a definitive answer on this now that 1.1 is out? I'd love to start getting these parts in engine. On another note, here's a question to anyone with experience writing shaders: Is there a way to get a normal decal shader working within KSP? Something like what's presented here: http://forum.unity3d.com/threads/how-do-i-write-a-normal-decal-shader-using-a-newly-added-unity-5-2-finalgbuffer-modifier.356644/ I know work has been done to bring other shaders into KSP in the past, but I have no idea what version of Unity 5 KSP is running on (I assume it's not as recent as 5.2). The benefits of a shader like this could be tremendous. Here's what I envision- a single normal map referenced by every part in the game. Details would all be handled as decals in this normal map, and all other shading would be handled by vertex normals. All of my parts already use vertex normals for 95% of their shading, but they still require giant, costly normal maps just for 1 or 2 details. It seems like a waste that could completely offset. Thanks for any information you can provide!

I'd argue you leave the side tanks like they are. You might get away with reducing the number of sides by a couple spans in each direction, but you'll only save a couple hundred polygons, tops, and you'll start getting some pretty severe faceting. Try to remove polys from places that are going to affect the silhouette the least (i.e. areas with the least curvature). If they're not already, reduce all the pipes and struts to 8 or even 6 sides. Like @CobaltWolf said, 5k should be just fine for an engine.

Docking ports are indeed on the long term list. I'm looking at the IBDM as a design guide. This is an awesome gem I hadn't seen before, so thanks for the ping. I wonder if the collider would be able to restrict the rotation to a specific degree of freedom. In the image above, for example, you would have to align the craft to within 120 degrees or so, and then fine tune once soft docked.

I was basing the design off of the reference I found for the 8096 with a vacuum nozzle. Most places that showed one in use on an Agena D has this style. Eg: I'm not sure what it's utility is though. I was thinking about doing just this! The mounting ring will probably be a second .mu (along with some sort of cover just above the Pistons), toggled on only if you use the lower attachment node. Question to the gallery, is it possible to have more than 2 nodes on a part?

Finally got some time to do a little more work on the LV909 refresh part. As suggested by @cfds and @GregroxMun, the nozzle has been extended and the combustion chamber has been shortened slightly to compensate. This is about as far as I want to push it, as I still want it to stay as close as possible to the form factor of the stock 909 below the mounting ring. Also took the opportunity to do a revised material pass, and the results are much closer to my target for these. All that's left is adding some hand-painted overlays to match the stock look closer. I'm sure once 1.1 is out, I'll have to re-calibrate everything again for the actual in-game appearance. The KSP shaders are night and day in how they look between the game and the Unity editor. Does anyone have an idea of how close things will look for the Unity standard shader? I'm calling this one complete for now. Behind the scenes, 1m fuel tanks are in progress as well as an optional shroud for the Redstone engine. Wings should be mountable on it, allowing for a rough approximation of the Mercury Redstone rocket. Once these are finished, I'm going to try to get all the parts finished so far into KSP. At that point I'd love to get some help bug testing if anyone's able to spare time.

This is one of the best looking models I've seen for KSP! Can't wait to see it textured up.

Those landing legs are fantastic! The lights are a great touch, too. I'd love to see these in action during a night descent.

After further thought, I'm kind of attached to the look of the full Bell engine. Once the cover is in place and/or its part of a larger assembly, it shouldn't look so long in the tooth. I've done a quick sculpt and normal overlay as a test for the cover when radially attached. Please ignore the seam, this is for mockup only. Whats the general opinion of something like this, versus something closer to a stock interstage look, as @sashan suggested?

This is a fantastic idea! The thought briefly crossed my mind but I didn't think it would be possible. I'll definitely be taking a close look at how do achieve this. Although I don't have much programming experience. Can you/anyone point me in the right direction? Thanks for the images, that's a helpful visualization of what NathanKell and ferram4 were describing. I'm definitely open to releasing the parts in branches. It's still pretty early in the process, and I'll need some help down the line with balancing the parts and figuring out how everyone wants things packaged up. I'm having a bit of trouble making out exactly what you mean, but the part is kind of locked in with regards to the outer ring, as I'm trying to keep the bounding box the same as stock. Your point about making more of the details visible makes sense, though. How's this as a compromise: Pardon the messy mockup, but it gets the idea across. Basically, I squash the engine vertically, bringing more of the details into the visible part below the ring. It moves things pretty far away from the RL analogue, though (especially considering I already had to move some of the upper assembly parts around to fit them between the stabilization bars). Thoughts? In the meantime, I went ahead and did a quick material pass on this guy: I don't know if I'm totally happy with this one. I'm having some difficulty breaking the parts up with materials while making sure everything reads as metal. I'm thinking I need to define 3 types of metal (varying glossy/matte,light/dark) and a couple glossiness levels of paint and stick to them. After this engine is at a good resting point, I think that's next (along with fuel tanks).

Thanks for the feedback! I agree that I may have missed the mark on the first outing trying to texture these things. In fact, one of the things coming up on my to-do list is to create a material library to use across all the parts so I can keep a consistent look. I'll post a set of images once I have something cohesive down to see what people think. I've been using heroicrelics, historicspacecraft, and b14643 as my main reference sources. They seem to show a variety of different materials, from matte to very glossy, even used on different builds of the same engine. I guess that's chalked up to aging and, as @TiktaalikDreaming said, some intervention on the museums' part to make them more archival. I may wind up reducing some of the detail even as I move on to more modern engines. My goal isn't to make photo-realistic parts, but to use the real-life analogues as a guide while preserving the stock KSP look. To my eye, that means simplifying some of the forms and doing away with some of the fine details. In general, I'll be trying to at least include the major fuel and exhaust lines. Here's the next engine I'm working on. A replacement for the LV-909 based on the Bell 8096. I'm looking for some feedback regarding the design on this one. As you can see, the combustion chamber and turbo pump extend well beyond the attachment ring. The stack node will be in-line with the ring, and the collision mesh will only include geometry from the ring down (the footprint is nearly identical to the stock LV-909). My idea here is that for designs where the engine is attached to a 1m fuel tank, the engine will look similar to stock, with only the nozzle showing. However, if you wind up attaching to something like a strut/girder segment, the engine will be visible. The only thing missing from the design at this point is some sort of foil/cloth cover so that you can't see the engine clipping through the fuel tank if it's stacked directly below one. I can't find clear reference of the bottom of an Agena stage. Any suggestions as to how the cover should look? (Keeping in mind that the engine will gimbal while the exhaust will remain stationary.)

The hit on performance won't actually be as bad as you think. Without knowing the details of the KSP shader, map for map the performance of a PBR shader should be pretty much the same as a traditional specular shader. You're essentially just trading diffuse/gloss/specular/normal maps for albedo/gloss/metalness/normal maps. So in comparison to the KSP shader specifically, you'll need an additional 1-2 maps, but as @*Aqua* mentioned, the hope is that the gains from moving to 64bit will offset that requirement. Also, with smart re-use of texture maps between parts, you can really get away with a lot lower resource footprints. Allegorithmic has a fantastic PBR primer online for anyone interested in learning more. Photorealism isn't so much the goal as supporting things like reflective materials and the ability to blur reflections. The main benefit of a PBR shader over a traditional one is that it reacts correctly to drastically different lighting conditions. So whereas a traditional shader might only look great under a specific lighting scenario, a PBR shader will look great whether it's midday on the launch pad or in orbit on the darkside of the Mun.