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

[Gibster]

Hey I came here from this post and have to say, this is a nice looking mod you got here,  personally really interested in the fuel tanks. That said I do have a bit of a selfish question: Is it possible to isolate the fuel tank parts from the rest of the mod? I already have a few mods that add all the engines and command modules I need (Near Future Tech and Space Y) and I kind of want to keep less clutter in my parts list (and try not to overwhelm my computer). If not (at least if its not easy), its alright, I'll manage. Thanks!

[Shadowmage]

Hmm... got the in-orbit reflections to include EVE clouds.  The solution, as are many in Unity, was to use 'MAOR SHADERS!!'.  No, seriously, all I had to do was write a post-process shader to overwrite the alpha channel on the rendered cubemap, and suddenly all of Eves cloud problems went away (apparently the EVE shadow-shaders do wierd things and write 0's into the alpha channel when rendering).

 

And now that I've spent all this time getting the shiny reflections working, I decided it was time to make them blurry (specular environment map convolution), which gives the proper 'not-quite-a-mirror' reflection properties to the chrome tank texture:

And which also gives very nice subtle effects like the 'colored ambient light' from the planet (who needs planetshine?):

(nom, nom... such tasty shading...)

Getting closer.  A bit more work on it and I'm going to call the solution 'working'; nearly all of the initial problems have been solved in one fashion or another.

The next set of issues that I'll be tackling is proper specular convolution of the cubemap (currently its a giant hack).  I'm really not sure how Unity does it -- supposedly it uses the GPU, but compute shaders aren't available on all platforms, so even that must be some sort of hack (convoluting to 6x render texture outputs, one per side, and recompositing back into a cubemap?). 

My options are:

• CPU based convolution, which will be slow (scene must be rendered, sent from GPU to CPU, processed, and uploaded back to GPU).
• GPU based convolution, which would be much like posted above -- use a shader and process each face of the cube as a separate output rendertexture, and combining those back into a full cube-map.
• Evolution of the current hack that I'm using -- render into a RenderTexture-Cubemap, assign that texture/material to an object/skybox, and let the ReflectionProbe capture -that- reflection and do the convolution internally.

None are ideal or fast, but one or the other will be necessary.

 

[Jimbodiah]

Send it to the GPU, less lag on the game (moar cpu loading) that way which is already pushing it in some cases. My GPU at the moment is wondering if it needs to go into sleep mode, it's not being used much by KSP.

[Theysen]

8 minutes ago, Jimbodiah said:

Send it to the GPU, less lag on the game (moar cpu loading) that way which is already pushing it in some cases. My GPU at the moment is wondering if it needs to go into sleep mode, it's not being used much by KSP.

I melt as soon as I have scatterer installed. my game dies fps wise. I can’t actually tell you if it’s gpu or cpu bound to the point where I neglect installing it. 

Id prefer the hack. 

[gmiddlemass]

1 hour ago, Jimbodiah said:

Send it to the GPU, less lag on the game (moar cpu loading) that way which is already pushing it in some cases. My GPU at the moment is wondering if it needs to go into sleep mode, it's not being used much by KSP.

I have to side with Jimbodiah on this one. I think generally the GPU isn't doing much at all with Kerbal whereas the CPU is reasonably loaded already with the game physics.

[Shadowmage]

1 hour ago, Gibster said:

Hey I came here from this post and have to say, this is a nice looking mod you got here,  personally really interested in the fuel tanks. That said I do have a bit of a selfish question: Is it possible to isolate the fuel tank parts from the rest of the mod? I already have a few mods that add all the engines and command modules I need (Near Future Tech and Space Y) and I kind of want to keep less clutter in my parts list (and try not to overwhelm my computer). If not (at least if its not easy), its alright, I'll manage. Thanks!

Possible -- absolutely.  Easy -- very much not.

There is so much inter-linking of the models/configs/textures that trying to trim down the install is not easy.  The basics of it are to keep the part configs from SSTU/Parts/ShipCore/Tanks, keep all of the models that are used (SC-TANK-XXXX), as well as their textures.  You'll also need all of the models for the adapters that are used in the tanks (many and various), as well as their textures and texture-set configs.  Trying to find each specific model, config file, and texture needed would be... difficult (WTB KSP-config-node IDE where I can go 'show references'....).

Thankfully one of SSTU's biggest 'selling points' is part-list-clutter reduction (or at least I would like to think so).  About the only thing that might seem cluttered from SSTU parts would be the engines, and even then there is quite a bit of built-in clutter reduction (via the built-in clustering and mount selection options).  I would say to give the full install a try -- you might just find yourself not needing some of those other mods anymore (or trimming their parts rather than SSTU's).  I've never used Space-Y, but I know that I stopped even installing KW-Rocketry quite awhile back.  NearFuture is still quite useful for the electric propulsion options, but I've never tried out the lifters pack (cryo engines are mostly unneccessary with SSTUs HLOX selection).

 

In development news:

-Finally- found how to access a Cubemap-RenderTexture's alternate cube faces.  Only took the past 3 days of searching, to find a function call so buried in Unity documentation that it would be surprising if anyone else ever legitimately found it.

So now I can actually implement GPU based cubemap convolution.  After I learn how to implement it   (have all of the tools, just need to learn and write the functions).  Thankfully I've also been stashing links on the implementations that I've ran into over the past days of research, so I'm sure I'll be able to get something working.

Also got my 'hack' cleaned up quite a bit in case I need to use that method.  Render the scenery into a basic cubemap (no convolution/MIPs), apply that cube-map to a sphere using a special unlit/skybox shader, set the sphere to an otherwise unused/unrendered layer, and set the reflection probe to capture only that layer.  The probe then captures the interior of that sphere as if it were the actual surroundings and runs it internal convolution code to spit out the proper MIP-mapped cubemap to use for PBR reflections.

[Shadowmage]

2 hours ago, Jimbodiah said:

Send it to the GPU, less lag on the game (moar cpu loading) that way which is already pushing it in some cases. My GPU at the moment is wondering if it needs to go into sleep mode, it's not being used much by KSP.

 

2 hours ago, Theysen said:

I melt as soon as I have scatterer installed. my game dies fps wise. I can’t actually tell you if it’s gpu or cpu bound to the point where I neglect installing it. 

Id prefer the hack. 

 

1 hour ago, gmiddlemass said:

I have to side with Jimbodiah on this one. I think generally the GPU isn't doing much at all with Kerbal whereas the CPU is reasonably loaded already with the game physics.

I'll see what I can do about including some options for different update paths. 

• The GPU-based solution will be -much- faster, even on older hardware (potentially up-to realtime). 
• The CPU-based solution would severely limit the update frequency -- would only update the probes once per second / every few seconds.
• The hack-based solution would also use the GPU based setup, but it would be Unity's internal GPU setup, so I would have no control over quality / speed / etc.  It also is far-from-optimal as the reflection needs to be rendered twice (first by me into the 'skybox' sphere, a second time by the reflection-probe into the reflection map).  The reflection-probes internal render/capture should be fairly quick as it is only capturing a single simple sphere object, but it is still an extra step that needs to be taken.

In order of what I'll be investigating will be hack first (as it is far simpler to implement; development time is important...), then the GPU solution (more optimal), and finally a CPU solution.

One thing that I should mention is that I'll be including options for update frequency, including an 'only update once' (or use pre-baked maps) setting for performance-limited setups.  The reflections wouldn't be 'proper', but for most (non-mirror) materials, -any- reflection is good enough for much improved visuals compared to legacy KSP shading.

Edited October 18, 2017 by Shadowmage

[gmiddlemass]

5 minutes ago, Shadowmage said:

give the full install a try -- you might just find yourself not needing some of those other mods anymore (or trimming their parts rather than SSTU's).

This is exactly what I do now.

SSTU has totally spoiled  me and I find myself trying to trim more and more parts from my install with each SSTU update, hopefully the Dragon capsules will be added soon (pretty please ) and that will be another load of parts that can be trimmed back. Presently I'm using the Kerbalized Spacex mod for the capsules (which seems to fit well with SSTU when rescaled down in size) but I just can't wait for the flexibility and look of the SSTU versions when they arrive.

Most of the other mods I use now are for visuals or gameplay "quality of life" enhancements rather than parts.

[Shadowmage]

Initial performance testing (on desktop), using 54 identical tanks sitting on the launchpad, each around ~7k tris (~375k tris in the scene in the tanks alone).  All render settings at max, v-sync and frame cap off, 8x AA.  128x128x128 environment map.  EVE and scatterer disabled.

SSTU/Masked Shader = 179 fps
SSTU/Standard Shader (no reflection update) = 175 fps
SSTU/Standard Shader (60 frame interval update) = 174fps
SSTU/Standard Shader (near realtime update, 1 face per frame) = 156fps

Will do some more serious performance testing on a few different machines to see how it handles on lower spec / older hardware, including a round of testing with Eve/scatterer installed.

So yes, there are performance differences between the PBR shader and the classic shaders, which was to be expected.  It is however quite minor on the system used for testing (~2.5% of fps), and a very acceptable trade-off for the improved lighting.  The reflection updates however can be far more costly, but that was to be expected.  The reflection cost can also be reduced substantially if updated incrementally and/or in larger intervals.

Currently the update speed is tied to frame-rate; lower FPS situations will naturally update the reflections slower so that they don't bog things down even further.  Will also investigate a purely time-based solution, as well as a time + altitude + velocity solution (intelligent updates; no need to update often when sitting still or you know the scenery won't change much).

One final thing to note on the subject -- I can make the entire PBR system optional and run alongside the existing textures and shaders.  The new textures can be treated as additional texture sets for the parts, and the existing texture-set code used for everything already supports switching shaders and assigning arbitrary shader property values and texture names.  Could even offer the entire thing as an optional download/expansion pack.

 

The refined hack is working very well so far (refl probe inside a sphere with the raw cubemap).  Allows me to control the layered rendering, but still take advantage of the reflection probes gpu-based convolution (which I really didn't want to write).  Certainly not the most efficient, but if updates are kept to a minimum it should be acceptable (hopefully just until a more proper solution can be found).

More glamour shots -- these aren't renders, but in-game screenshots.  I actually enabled in-flight switching on the texture-switch module so I could do this sort of testing.

Bonus - Eve orbit, showing the natural colored ambient light handling

2nd Bonus - Dark side of Laythe, showing a bit of half-lit Jool in reflection

 

Seems likely that I'll be putting out a testing release for the new shader(s) sometime this weekend.  Everything is working well in testing so far, and I would say the visuals are exceptional.  The initial test release will only contain the single non-functional part and will serve for compatibility testing purposes only -- need to ensure that the features that I'm using are widely supported, especially across OS and graphics APIs.

The next bit of development work that will be done on this feature will likely be trying out a few more models and textures/materials.  Would be nice to see what a full rocket would look like.... or possibly a lander?  Also considering the PBR assets from the PorkJet reworked 1.25m parts for some quick additional testing parts/models.  Now that I've determined it is doable, I need to determine if it is viable and worthwhile.  I have a feeling it will look a bit out of place in a stock game, but would fit in very well with the full eve/scatterer/sve/svt/realplume setup.

 

 

[vossiewulf]

12 hours ago, Shadowmage said:

My options are:

• CPU based convolution, which will be slow (scene must be rendered, sent from GPU to CPU, processed, and uploaded back to GPU).
• GPU based convolution, which would be much like posted above -- use a shader and process each face of the cube as a separate output rendertexture, and combining those back into a full cube-map.
• Evolution of the current hack that I'm using -- render into a RenderTexture-Cubemap, assign that texture/material to an object/skybox, and let the ReflectionProbe capture -that- reflection and do the convolution internally.

None are ideal or fast, but one or the other will be necessary.

 

One thing I'm pretty sure of and that is this game needs no help loading the CPU, while the GPU is mostly hanging out down at the pool and drinking mojitos.

[vossiewulf]

And it looks better by the day. I suggest you play with generators in SP and see if you can bring across the procedural subtle surface modifications you can get with ripples that are correct for riveted aluminum and scratches at least, but also the various grunge generators designed to work in recesses and the ones for paint dings.

I also think you should look at the camo-pattern generation generators, not that you would use them as is but to see how they work; unfortunately that would require Substance Designer, just remembered that. The reason is that from my own looks those generators can be quite powerful in generating patterns and multiple color versions of patterns, but are also straightforward enough that you don't need to get out your textbook on the physics of electromagnetism to understand. I have a feeling you'd figure it out fairly quickly and it could be another powerful tool for you in generating textures, although maximum utility would probably involve going bitmap over your procedural recoloring.

Also, crashes continue for me entering or exiting the VAB, and didn't even get logs last several times, even though overall log much much cleaner now. I finally got a log with this last crash, there are two sets of exceptions, one is JSI/RPM and the other is where Ferram apparently doesn't like some of your procedural object modification tools and it fails trying to build its own mesh of some kind. I'm still 1.30 with KSP and SSTU and Ferram. 

Spoiler

[MechJeb2] Loading Mechjeb 2.6.1
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

NullReferenceException: Object reference not set to an instance of an object
  at FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.RebuildAllMeshData () [0x00000] in <filename unknown>:0 
  at FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.GeometryPartModuleRebuildMeshData () [0x00000] in <filename unknown>:0 
UnityEngine.Component:SendMessage(String, Object, SendMessageOptions)
UnityEngine.Component:SendMessage(String)
SSTUTools.SSTUModInterop:onPartGeometryUpdate(Part, Boolean)
SSTUTools.SSTUModularFuelTank:updateModels()
SSTUTools.SSTUModularFuelTank:initialize()
SSTUTools.SSTUModularFuelTank:OnLoad(ConfigNode)
PartModule:Load(ConfigNode)
Part:LoadModule(ConfigNode, Int32&)
ShipConstruct:LoadShip(ConfigNode)
ShipConstruction:LoadShip(String)
FlightDriver:Start()
 
(Filename:  Line: -1)

NullReferenceException: Object reference not set to an instance of an object
  at FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.RebuildAllMeshData () [0x00000] in <filename unknown>:0 
  at FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.GeometryPartModuleRebuildMeshData () [0x00000] in <filename unknown>:0 
UnityEngine.Component:SendMessage(String, Object, SendMessageOptions)
UnityEngine.Component:SendMessage(String)
SSTUTools.SSTUModInterop:onPartGeometryUpdate(Part, Boolean)
SSTUTools.SSTUModularEngineCluster:initialize()
SSTUTools.SSTUModularEngineCluster:OnLoad(ConfigNode)
PartModule:Load(ConfigNode)
Part:LoadModule(ConfigNode, Int32&)
ShipConstruct:LoadShip(ConfigNode)
ShipConstruction:LoadShip(String)
FlightDriver:Start()
 
(Filename:  Line: -1)

NullReferenceException: Object reference not set to an instance of an object
  at FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.RebuildAllMeshData () [0x00000] in <filename unknown>:0 
  at FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.GeometryPartModuleRebuildMeshData () [0x00000] in <filename unknown>:0 
UnityEngine.Component:SendMessage(String, Object, SendMessageOptions)
UnityEngine.Component:SendMessage(String)
SSTUTools.SSTUModInterop:onPartGeometryUpdate(Part, Boolean)
SSTUTools.SSTUModularFuelTank:updateModels()
SSTUTools.SSTUModularFuelTank:initialize()
SSTUTools.SSTUModularFuelTank:OnLoad(ConfigNode)
PartModule:Load(ConfigNode)
Part:LoadModule(ConfigNode, Int32&)
ShipConstruct:LoadShip(ConfigNode)
ShipConstruction:LoadShip(String)
FlightDriver:Start()
 
(Filename:  Line: -1)

NullReferenceException: Object reference not set to an instance of an object
  at FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.RebuildAllMeshData () [0x00000] in <filename unknown>:0 
  at FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.GeometryPartModuleRebuildMeshData () [0x00000] in <filename unknown>:0 
UnityEngine.Component:SendMessage(String, Object, SendMessageOptions)
UnityEngine.Component:SendMessage(String)
SSTUTools.SSTUModInterop:onPartGeometryUpdate(Part, Boolean)
SSTUTools.SSTUModularEngineCluster:initialize()
SSTUTools.SSTUModularEngineCluster:OnLoad(ConfigNode)
PartModule:Load(ConfigNode)
Part:LoadModule(ConfigNode, Int32&)
ShipConstruct:LoadShip(ConfigNode)
ShipConstruction:LoadShip(String)
FlightDriver:Start()
 
(Filename:  Line: -1)

 

Also going to ask in the RPM thread, not sure which of these, if either, are involved with the crashes. It may be something else I guess, but these are the only exceptions I see now.

[Shadowmage]

CM is a WIP.  SM is partially converted from existing textures.  Figured out that I could easily extract the existing details from my textures and use them as masks in SP to speed up the process of reworking additional sets.

Sadly I found out that certain high-metallic materials have problems under dx9 due to ??  that causes seams in the blurred/mipped reflection probe textures.  DX11 looks great though (SS above..).  OpenGL seems fine as well.  I guess I finally have a reason to use dx11?

 

1 hour ago, vossiewulf said:

and the other is where Ferram apparently doesn't like some of your procedural object modification tools and it fails trying to build its own mesh of some kind. I'm still 1.30 with KSP and SSTU and Ferram. 

Please open an issue ticket on that (otherwise I'll forget about it as I already have a few times=\);  I recently had to fix a similar issue in KSPWheel.  The solution is 'simple', delay FAR updates until Start();  changing all of the places it is used might take some doing though.

This ^^^ could be causing quite a few other problems with parts, as it is crashing out halfway during initialization (but Unity/KSP still calls the update methods on them afterwards; yuck).

 

 

[vossiewulf]

Latest screenshots are like I said, it looks better every day  Also #585. Also also, I like that you've already started documenting the shader work on the wiki. Hopefully it can be made easy enough for most of the major part mods to make use of it, would increase the visual quality of KSP so much you'll get a triple length extra double super special episode of KSP mods where Scott Manley asks if he can marry you.

 

Edited October 20, 2017 by vossiewulf

[Jimbodiah]

Oh, shiny! Me want shiny!!!!

[Shadowmage]

13 hours ago, vossiewulf said:

And it looks better by the day. I suggest you play with generators in SP and see if you can bring across the procedural subtle surface modifications you can get with ripples that are correct for riveted aluminum and scratches at least, but also the various grunge generators designed to work in recesses and the ones for paint dings.

Yeah, certainly still some improvements that can be made to the textures.  For now I'm concentrating on getting the rendering bits all sorted out -- the textures are good enough for that.  Seems like I've nearly got it worked out though, so this next week will be more modeling work on the reworked LC fuel tanks (they are nowhere near finished), and additional texture-work / learning of SP while adapting some existing models/textures.

 

13 hours ago, vossiewulf said:

I also think you should look at the camo-pattern generation generators, not that you would use them as is but to see how they work; unfortunately that would require Substance Designer, just remembered that. The reason is that from my own looks those generators can be quite powerful in generating patterns and multiple color versions of patterns, but are also straightforward enough that you don't need to get out your textbook on the physics of electromagnetism to understand. I have a feeling you'd figure it out fairly quickly and it could be another powerful tool for you in generating textures, although maximum utility would probably involve going bitmap over your procedural recoloring.

Heh, I've been getting the feeling that I'm going to need SD in order to get the most use out of this system.   I've got a good head for technical work, and am already familiar with a vast array of noise functions and procedural generation techniques (having implemented many myself over the years), but it would be one more license to pick up, and more time needed to create the new substances/effects/etc.

Using the textures/materials/effects created by others is fine (and the work well for the most part), but you are limited to what is available.  Things that I would consider simple like a 'radial tile generator' (for generating the tile pattern on a pod heat shield) are... missing?  Seems like I'll still be having to do work in GIMP to create the masks to feed into the existing SP generators/filters.

 

1 hour ago, Jimbodiah said:

Oh, shiny! Me want shiny!!!!

   That is only the beginning....

 

I should note that just because I have a PBR shader doesn't mean my texturing (or modeling) skills will get any better (SP will help... but I simply don't have a head for 'art').  I also don't (currently) intend on changing my texture style much on the PBR sets -- textures will still be fairly 'plain' and simple, with noise/etc mostly being used to generate surface detail.  I probably won't be adding very much scratches/rust/wear/weathering as I feel it simply doesn't belong on parts that are supposed to be 'new, right from the manufacturer'.  One thing that might change would be the addition of more texture-based surface details (greeble) to some models/textures (paneling lines, ports, vents and whatnot) -- with the ability to paint things in model-space (and using generators to help doing so), doing these becomes so much simpler.  Not going for 'photo-realistic', but more aiming for a look of 'a very well done scale model'.

For this weekends' 'testing' release I'm working on getting a mostly full Saturn-V stack to be usable with (basic/simple) PBR textures sets.  F1, J2, AJ10-137, MFT, ISDC, IPA, SC-B-CM/SM/BPC.  CM and SM are started, BPC/ISDC/IPA will be quick, MFT shouldn't be too hard either -- its really the engines that might take awhile.  Initial testing setup for PBR textures will not support recoloring as I have not yet developed that feature in the new shader -- want to make sure everything else is working first before I start mucking about with its internals.

[Jimbodiah]

Gold plated engines for the win!

Really looking forward to seeing how this looks. My dreams of a completely golden Saturn is within reach!

 

[Temeter]

2 hours ago, Shadowmage said:

For this weekends' 'testing' release I'm working on getting a mostly full Saturn-V stack to be usable with (basic/simple) PBR textures sets.  F1, J2, AJ10-137, MFT, ISDC, IPA, SC-B-CM/SM/BPC.  CM and SM are started, BPC/ISDC/IPA will be quick, MFT shouldn't be too hard either -- its really the engines that might take awhile.  Initial testing setup for PBR textures will not support recoloring as I have not yet developed that feature in the new shader -- want to make sure everything else is working first before I start mucking about with its internals.

<3 <3 <3

[Shadowmage]

Today has seen a bit of plugin/code work (cleanup some FAR incompatibilities hopefully), as well as a bit of getting back to work on the LC fuel tank geometry (as the stuff used for testing the shader is far from finished).

 

 

The major changes were to finalize my decision on an 8-tank layout, finalize my decision to get rid of external bracing, work on some fuel lines/routing, and some poly reduction in the fuel tanks themselves (down from 8k > 6k tris, even with fuel lines).

Basic tank:

 

And with all braces for the standard circular-interface adapter (including fuel lines that match up with the existing MFT and engine mount tank caps):

Basic hollow variant:

Capped hollow variant (hollow attach plate, for engines/legs/whatnot) (might bevel the edges on the exterior of the top/bottom caps a bit)

Paneled hollow variant:

 

 

The geometry for all of these is -nearly- finished.  Some bits to cleanup, but that is basically it (mostly fuel line stuff); I don't think I'll be adding too much new geometry beyond some small weld-points/endcaps where the braces converge.

[Sudragon]

This...this is most excellent.

[vossiewulf]

5 hours ago, Shadowmage said:

Using the textures/materials/effects created by others is fine (and the work well for the most part), but you are limited to what is available.  Things that I would consider simple like a 'radial tile generator' (for generating the tile pattern on a pod heat shield) are... missing?  Seems like I'll still be having to do work in GIMP to create the masks to feed into the existing SP generators/filters.

Yeah there are excellent free things available, and some odd gaps still. However you could do it pretty quickly non-procedurally, just cover whole thing in ablative material, add a new layer and do your panel lines with circular line brush stamps and straight lines, mask it and give the panel lines a darken/color burn filter and a procedural dust set to very dark. You think considerably more procedurally than the average artist does, or at least your case requires you to do so.

Creating a full generator for it would certainly make future variations a breeze, but not sure if it's worth the effort unless you know you can port the actual procedural generation logic compiled into a .sbr to KSP. If that's the case then buy SD tomorrow as you could solve many procedural issues that way.

 

5 hours ago, Shadowmage said:

I should note that just because I have a PBR shader doesn't mean my texturing (or modeling) skills will get any better (SP will help... but I simply don't have a head for 'art').  I also don't (currently) intend on changing my texture style much on the PBR sets -- textures will still be fairly 'plain' and simple, with noise/etc mostly being used to generate surface detail.  I probably won't be adding very much scratches/rust/wear/weathering as I feel it simply doesn't belong on parts that are supposed to be 'new, right from the manufacturer'.  One thing that might change would be the addition of more texture-based surface details (greeble) to some models/textures (paneling lines, ports, vents and whatnot) -- with the ability to paint things in model-space (and using generators to help doing so), doing these becomes so much simpler.  Not going for 'photo-realistic', but more aiming for a look of 'a very well done scale model'.

Your textures are clean, I don't see any much better in the game.

Weathering - yes you do want to use them and learn how to use them. You won't, of course, use them to the level I did for giant metal robots running at speed cross country, but there is no such thing as a perfectly clean surface unless someone washed it literally 60 seconds ago. Anything that's been in the sun for any length of time will start to see differences in value between the high spots with high ambient access and the low spots that don't get as much light. And I'd be willing to bet that even the Apollo 11 Saturn V had a few chips of paint from the large movements induced by huge thermal gradients and pressurizing/unpressurizing tanks. All of these subtle things add much more realism than you'd first think.

So learn them, they're easy to use once you do. Experiment with subtle, understated wear and dust and paint dings. I'm sure you'll think the result was worth the effort.

Greeble/details, yes look at the hard surface normal stamps. Go download more. You can very quickly add all sorts of panels and lines and raised areas just stamping them into the normal map and that keeps your geometry light and poly count low.

 

[tater]

With the exception of reusable craft, there is no weathering to speak of, every flight is the first and only flight of most spacecraft, so I'm not keen on weathering in many cases. 

Unrelated, but I found this image of the ATK Liberty capsule interesting (composite competitor to Orion):

 

[vossiewulf]

Click for full size.

[Temeter]

That's the picture that really made me want reflections in KSP. Didn't actually think it would happen^^

[Jimbodiah]

FASA used to have a reflections plugin that was used on their Apollo version, but it got borked in KSP 1.1 or 1.2 I think.

Edited October 21, 2017 by Jimbodiah

[Theysen]

7 minutes ago, Jimbodiah said:

FASA used to have a reflections plugin that was used on their Apollo version, but it got borked in KSP 1.1 or 1.2 I think.

Raidernick preserved e.g. the reflection on agena and Apollo iirc via texturereplacer if I am not mistaken, same with windowshine. 

Since I have no clue - those are purely reflections and not real pbr right?