Jump to content

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


Shadowmage

Recommended Posts

23 hours ago, Mike` said:

As was found out some time ago, low/zero boiloff tanks are really efficient when only used for hydrogen, while another tank is used for oxygen. Now, this is rather inconvenient to do in practice, and you always have to scale the tanks equally if you need a different amount of fuel.

So i wonder, would it be possible without too much hacking to have the low/zero boiloff modifiers only affect the hydrogen part of an mft tank, while the oxygen part remains a standard tank?

Alternatively, what about the possibility to configure it per resource in the "configure containers" dialog (maybe via a dropdown per line or something)? That way, one could make the hydrogen-part low/zero bo, while one could also choose whether the oxygen part should be a standard or lightweight variant. In that case the durability of the tank would need to be determined by the weakest part. It would eliminate the need for an additional tank and would make scaling such a rocket much more convenient.

Having the 'tank modifier' affect a specific resource would be... massively painful from a coding perspective.  The entire system would need to be redone to support per-resource-tank-types, which is 'only' a few thousand lines of code to go through, effecting nearly every SSTU modular part.  It would require that every resource added to a tank also have a list of applicable tank types for that resource, and the user would have to set these up manually for every resource in the tank.  Really not something I'm prepared to implement anytime soon.  You even brought up one of the major problems that would be encountered -- how to set the stats for a part with a tank with multiple and various tank modifiers (e.g. heat and impact tolerance).


I think that part of this 'problem' might come down to intended use-case.  The ZBO options are mostly intended for use on pure LH2 tanks -- for long-term propellant depots or for nuclear propulsion.  In most of the cases where you would choose a LH2/LOX engine, being ascent/lifters and kerbin/earth ejection burns, the ZBO tanks make far less sense due to the short duration of storage -- minutes or hours, where the loss is negligible.  The ZBO tanks however make perfect sense for long-duration nuclear propulsion setups.

 

21 hours ago, Nightside said:

Alternatively you could change it so oxidizer suffers boiloff too, as does liquid oxygen in real life.

I think there was a patch floating around somewhere...

...Oh yeah, it was SRP-0


+SSTU_RESOURCEBOILOFF[LqdHydrogen]:AFTER[SSTU]
{
	@name = Oxidizer
	@value *= 0.0216189// LOX hsp/LH2 hsp * LOX density/Oxidizer density, probably not right but should do it.
	@cost *= 0.1650114 // Oxygen boiling point/Hydrogen boiling point * LOX density/Oxidizer density, probably not right too but gameplay-wise its serviceable.
}

 

^^^

I think that is probably a better 'solution' to the ZBO tank-modifier problems.  Let it cool the oxidizer as well :)  (of course, then you need to be prepared to stop using standard LFO engines for long-duration missions unless you also use the ZBO tanks).

 

 

20 hours ago, Jimbodiah said:

Does boil-off work at high-warps at all; i.e. empty tanks for no reason on zbo tanks?

As others had hinted, it entirely depends on how much EC reserve you have (due to KSPs timewarp resource handling).  Basically you need to have enough EC reserve for the largest processing tick for all subsystems; at 1000 and 10000x warp rates, this can be quite a bit of EC (thousands).

The best method is to un-focus the craft.  Make sure you have adequate EC income, and go back to the space-center for timewarping.  I've deliberately left the simulation... un-simulated... for unfocused craft.  If you had enough EC income when you were last in control, it assumes the EC income was sufficient for the duration of the uncrontrolled period, and processes boiloff accordingly (so if it were ZBO, you should have zero loss).

 

 

In general development news:

As the geometry (models) for the new LC fuel tanks is nearly finished, I've started working through the textures a bit.  Also continuing work on getting the rest of the PBR testing pack ready (F1/J2/SC-B/MFT-AB), and should hopefully have it available this weekend.

This is the point at which I need to determine what my 'texturing style' will be for the PBR texture sets.  Working with Substance Painter I have the opportunity to make my textures amazingly consistent between the different models -- consistent texture resolution (texture detail), consistent amounts of grunge and wear, and consistent coloring/materials.  I just need to determine what level of each to use, make some notes, and get to work (well, and more practice with using SP of course... still learning).  Throughout this week I'll be working on some samples of the tank textures to post up for feedback -- will be determining both what material types to include for standard texture sets (metals/foams/paints/foils), as well as the specific 'details' in the textures (wear/grunge).

Another opportunity I have with the PBR textures is to increase the overall texture resolution used on the models.  With Substance Painter it extremely simple to output higher-res textures (whereas with GIMP you pretty much have to author it at the intended resolution).  Combined with the availability of 64-bit clients and the constant increase in RAM on gfx cards, and doubling the texture resolution for the PBR textures would seem entirely reasonable.  The PBR shaders also -love- higher res textures... the higher the better; this is where a large majority of the surface detail comes from (high-res normal maps).  I feel that I also have to point out that the PBR textures will be put released as a separate stand-alone expansion to SSTU... so those with less powerful systems (or simply wanting the old aesthetics) can continue to use the standard/legacy textures.  -I- want high-res textures and nice looking parts, and have a computer that can handle it (the graphics/textures at least), so that is most likely what I'm going to do.

I intend on continuing to use and create textures for the existing 'recoloring' shader to be included in the base SSTU distribution.  The number of options will likely decrease for most parts though, with only 1-2 basic texture/mask sets being available that use the legacy shader (e.g. the existing MFT tanks would go from ~12 sets down to ~2 or 3).  This should result in a much smaller release file size and faster load times with fewer textures to load.  Many of the textures that simply don't look right under the legacy system will be removed entirely (gold, silver; both being moved to PBR only), with the majority of the remainders being the standard colored/painted textures and perhaps an orange-foam option for some parts.


Recoloring PBR -- still working through exactly how I want to put the system together.  I would like to keep it as close to the existing recoloring setup as possible -- for re-use of existing code, and consistent user-interface and experience.  Looking at the textures that I'm getting out of SP so far, it doesn't look like it would be too much of a problem for very basic texture setups (being mostly a flat diffuse color).  The problem comes with the details -- grunge and wear.  These both add inconsistencies to the diffuse texture as far as highlights/shading, but the real problem is that they can often change the actual diffuse base color -- something that the recoloring system cannot easily cope with (it only handles a single color with minor saturation/value adjustments).

Potential solutions to the 'detail' problem include adding yet another diffuse texture slot to confer the detail coloring (or using the Unity Standard Shader 'detail' texture slots), or simply living with the tinting of the details whenever the base texture is recolored (e.g. brown dirt would have a blue tint on a 'blue' colored tank).   Possibly even just assuming the 'diffuse' texture is the detail texture, and applying that over-top of the masked texture?  (seems like that would still result in tinted details).  None of this is a problem with the current recoloring solution as it truly is a one-color setup;  the color the user specifies is the color used for that material -- the 'detail' is purely highlight/shadow based with zero change in color from the grunge or wear.

Another potential solution might be to use the mask texture itself to determine the detail input from the diffuse texture.  Currently most masks are either R,G,B, or Black, with little-to-no intermediate values.  This doesn't necessarily have to be the case.  Take the R channel for example -- if the R channel for a pixel is 1, it means that 100% of the coloring for that pixel comes from the users specified 'Main Color'; but what if it only had a value of 0.7?  That would represent that only 70% of the color comes from the users 'Main Color', with the remainder 30% coming from either the main diffuse texture or another user-color-channel.  If I were to do some...interesting... math in the shader, I should in theory be able to use the user-specified color as the 'background' and apply the diffuse-texture as an overlay on top of the user-color by assuming that the diffuse-textures' base-color is a 'transparency' (or even use an actual alpha channel..?).   Hmm....

Yeah, big wall of text; seems about usual for my development posts, eh?

Link to comment
Share on other sites

RE: boiloff on the stock oxidizer. 

I don’t think it is a good addition bending the little Realism stock resembles with the fuel resources even further. Understanding it as something in the realms of Aerozine / NTO which are used because - well - they don’t boil off in the real world. Then I’d suggest argumenting loss over time with bad valves :P

Link to comment
Share on other sites

25 minutes ago, Theysen said:

RE: boiloff on the stock oxidizer. 

I don’t think it is a good addition bending the little Realism stock resembles with the fuel resources even further. Understanding it as something in the realms of Aerozine / NTO which are used because - well - they don’t boil off in the real world. Then I’d suggest argumenting loss over time with bad valves :P

I get what you're talking about. It could a modulemanager patch to replace Oxidiser with LqdOxygen and LiquidFuel with Kerosene for SSTU engines (and related verniers/other engines in stock) instead,  to ensure stock behaviours of LFO tank parts are untouched for compatibility reasons, while maintaining the 'realism' aspect of Kerolox in SSTU.

Then again, it is an unofficial patch by fans so it's not really a thing Shadowmage has to worry about implementing into the mod itself.

Edited by T-10a
Link to comment
Share on other sites

My favorite part from this mod is the reentry orion esk capsule.  It is all in one command module which is easy to use and is all in one.  

My favorite part though is the parachutes being set to trigger at altitude not pressure.  Honestly I would adore having some parachutes and drogue shoots that are stand alone as having them trigger at an altitude makes them so wonderful to use.  You can arm them during reentry and not spend a year waiting to land.

Link to comment
Share on other sites

53 minutes ago, captinjoehenry said:

My favorite part from this mod is the reentry orion esk capsule.  It is all in one command module which is easy to use and is all in one.  

My favorite part though is the parachutes being set to trigger at altitude not pressure.  Honestly I would adore having some parachutes and drogue shoots that are stand alone as having them trigger at an altitude makes them so wonderful to use.  You can arm them during reentry and not spend a year waiting to land.

You might want to check out REALCHUTE by stupid_chris

Not only does it add new chutes almost all parachutes can be adjusted after installation of this mod.   IE material, Altitude vs pressure  deployment, what altitude you deploy at etc.   Designed so parachutes will function close to real life.

 

Edited by Pappystein
Link to comment
Share on other sites

16 hours ago, Pappystein said:

You might want to check out REALCHUTE by stupid_chris

Not only does it add new chutes almost all parachutes can be adjusted after installation of this mod.   IE material, Altitude vs pressure  deployment, what altitude you deploy at etc.   Designed so parachutes will function close to real life.

 

True but I honestly don't want or need all the other features of REALCHUTES.  In addition I have a bunch of mod added parachutes that don't have configs for REALSHUTE

3 hours ago, Temeter said:

You can setup deploy altitude and arming for stock parachutes too.

Yes but the issue is them deploying.  The pressure setting for that is hugely annoying to deal with and if you come down on high alt terrain it'll kill you.  Just having it all set at an altitude above the ground works a lot better and easier.

Link to comment
Share on other sites

Getting closer.... (A/B fuel tank basic striped PBR textures, experimenting with some wear and weathering)

q7nfN1U.pngvRoEfhq.png

Mounts/fairings/decouplers do not yet have Standard-shader enabled setups, but should be able to come up with something for them, at least for a few test pieces.  Contrast the shading on the white fuel tanks vs. the white fairings... quite the difference.  Also a fairly notable difference even on the black striping, though some of that is probably due to me not matching up the colors very well.

 

Today's code-and-config dev work was spent splitting off all of the shader loading code and a large portion of the texture-set code into a separate plugin.  As it was all so deeply integrated into the texture-set handling code, the recoloring system also found its way into the stand-alone shader plugin.  The in-dev name: KSPShaderTools -- but I need to come up with something better before its official stand-alone release.  It will be included in all future SSTU releases, and in fact the SSTU plugin now depends on it in order to load (linked/referenced).

It will include the following functions, available to any mod who wants to include the KSPShaderTools.dll (no extra code required):

  • Loads asset-bundles containing .shader files. 
    • The asset bundles are specified through config file, and should be capable of loading standard KSP asset bundles with custom extensions.
    • Supports loading of per-platform bundles, or 'universal' bundles -- either can be specified in the config.
    • Shaders are made available through the GameDatabase.shaders(sp?) list once loaded, and other mods can retrieve them from there without compile-time references/linking.
  • Apply specific shaders/textures/TextureSets to models in the GameDatabase
    • Config file based - highly configurable - uses TextureSet syntax and config node layout (see below)
    • Basically does what TextureReplacer does... but only for part models.
    • No in-editor texture-switching supported for this method; intended for stand-alone texture/shader replacement patches
  • Supports using special 'icon' shaders to fix part-icon rendering for non-KSP shader setups. 
    • The mapping of these is defined through config files and applied automatically to all parts using the specified shaders.
    • Icon shaders should be supplied by the author of the corresponding part shader. 
    • Icon shaders have/will be included for the legacy and pbr masked/recoloring shaders.
  • Included Shaders:
    • SSTU/Masked 'Recoloring' shader.  This is the current recoloring shader available in the SSTU releases.
    • SSTU/Standard shader.  Direct port of the metallic/gloss Unity Standard shader (PBR). 
      • Only a single variant is currently available (with NRM and MET maps enabled, GLOW disabled); additional named variants will likely be made available.
    • SSTU/StandardMasked shader.  Recolorable version of the Standard shader. (WIP...)
  • Configurable ReflectionManager -- updates ReflectionProbe cubemaps.  Needed by the Standard shader variants in order to effect proper lighting.
    • Resolution, frequency, and other quality/performance settings can be adjusted through config files (possibly in-game config GUI / KSP-mod-config menu)
    • Can be provided with pre-rendered environment maps to disable runtime reflection updates (none included, must be provided by user/other mods) (WIP)
      • In the future this may be enhanced to allow for situation-dependent switching of pre-baked environment maps (performance optimization, but lose real-time reflection updates)
  • TextureSet system - config based texture set definitions
    • Supports loading of arbitrary texture slot names - any target texture slot name can be specified, not limited to those used by KSP shaders
    • Supports use of any shader that is currently loaded, including the standard KSP/Diffuse and other common shaders.
    • Supports shader property assignment - such as Color or float property values in shaders (e.g. _Shininess or _SpecularColor).
    • Each texture set can have multiple texture/mesh specifications, fully supporting complex texture sharing setups or use of different shaders for specific meshes in a complex model.
  • KSPTextureSwitch PartModule -- loads config-defined texture sets and applies them to model, with user capability to switch sets in editor/flight.
    • Supports multiple texture-switch modules on a part; each may be responsible for different meshes/sub-models.
    • If recoloring is used, each texture-switch module gets its own 'section' in the recoloring GUI (with its own main/second/detail channels).
    • Nearly an exact port of the SSTUTextureSwitch module (used on the ShipCore pods).
  • KSPRecoloringGUI PartModule -- adds the 'open recolor GUI' button to a part.  Needed in order to use the recoloring features.  Only available in the editor (WIP - make it usable in flight through config)
  • Short list of color presets for use in the recoloring system, which can be easily expanded or adjusted through additional configs or patches.

When used as a compile-time dependency (as an API) it additionally includes a few utility interface and allows access to the TextureSet system and through that the recoloring system.  Additional plugin code would be required for external mods to use the system in model-switch setups or to use the more advanced functions of the recoloring system and texture set system.

It will not include any textures or config files beyond the basic framework for recoloring and reflection setups.  It is intended as a lightweight mod/API that other mods may include in their distributions where they are supplying the 'content' (textures/more shaders/etc).

Link to comment
Share on other sites

14 hours ago, Shadowmage said:

The in-dev name: KSPShaderTools -- but I need to come up with something better before its official stand-alone release.  It will be included in all future SSTU releases, and in fact the SSTU plugin now depends on it in order to load (linked/referenced).

Maybe call it KSPUmbrella or something along those lines? Because umbrellas (or parasols) can provide shade, and your tool provides shaders to other modders.

Link to comment
Share on other sites

A coding question regarding SSTUVolumeContainer, more specifically this line in VolumeContainer.cs in SSTUTools/Util and every other value that is derived from it, related to how configs or players can define unit ratios in a given tank:

        /// <summary>
        /// Current user or config specified unit ratio for this resource
        /// </summary>
        public int unitRatio { get { return ratio; } }

Why did you use int instead of float for those? Is there a performance or stability reason for not supporting decimal values there?

I know it is not really a big deal. Just curious.

Link to comment
Share on other sites

On 10/31/2017 at 10:57 PM, Shadowmage said:

Getting closer.... (A/B fuel tank basic striped PBR textures, experimenting with some wear and weathering)

q7nfN1U.pngvRoEfhq.png

It will include the following functions, available to any mod who wants to include the KSPShaderTools.dll (no extra code required):

  • Loads asset-bundles containing .shader files. 
    • The asset bundles are specified through config file, and should be capable of loading standard KSP asset bundles with custom extensions.
    • Supports loading of per-platform bundles, or 'universal' bundles -- either can be specified in the config.
    • Shaders are made available through the GameDatabase.shaders(sp?) list once loaded, and other mods can retrieve them from there without compile-time references/linking.
  • Apply specific shaders/textures/TextureSets to models in the GameDatabase
    • Config file based - highly configurable - uses TextureSet syntax and config node layout (see below)
    • Basically does what TextureReplacer does... but only for part models.
    • No in-editor texture-switching supported for this method; intended for stand-alone texture/shader replacement patches
  • .............
  • Short list of color presets for use in the recoloring system, which can be easily expanded or adjusted through additional configs or patches.

One, looks officially Rave Burger double bacon and cheese awesome. Two, I gotta really be careful with these suggestions. I think I mentioned that you might want to think about making it available to other modders, and you haven't just made it available but built a slew of features to make it easy for folks to use and made it all config-driven. You're pretty close to it making sense to make it at least shareware, and considering it will make someone's mods MUCH better with a minimum of work and potentially transform the appearance of KSP, some consistent contributions would be pretty justified for all the R&D.

Link to comment
Share on other sites

9 hours ago, NotTheRealRMS said:

A coding question regarding SSTUVolumeContainer, more specifically this line in VolumeContainer.cs in SSTUTools/Util and every other value that is derived from it, related to how configs or players can define unit ratios in a given tank:


        /// <summary>
        /// Current user or config specified unit ratio for this resource
        /// </summary>
        public int unitRatio { get { return ratio; } }

Why did you use int instead of float for those? Is there a performance or stability reason for not supporting decimal values there?

I know it is not really a big deal. Just curious.

There -was- a reason behind it, which is no longer valid.  It could likely be changed to a float and probably wouldn't have too much impact.  Would have to do some deep code analysis to know for certain though.  (feel free to play around with it; PRs welcome)

History:  Originally I had intended it so that the fuel tanks would only ever hold resources in discrete whole Unit chunks.  Using an integer ratio greatly simplified the code-side math needed to find the closest matching resource unit quantity for any given tank volume; but more importantly it let it work with multiple resources in a very clean and simple fashion.  Much more of a simplification than an optimization (though integer math generally is very fast; unsure on the difference between int/float math under modern processors; used to be int was magnitudes faster).

 

2 hours ago, vossiewulf said:

One, looks officially Rave Burger double bacon and cheese awesome. Two, I gotta really be careful with these suggestions. I think I mentioned that you might want to think about making it available to other modders, and you haven't just made it available but built a slew of features to make it easy for folks to use and made it all config-driven. You're pretty close to it making sense to make it at least shareware, and considering it will make someone's mods MUCH better with a minimum of work and potentially transform the appearance of KSP, some consistent contributions would be pretty justified for all the R&D.

:)  I believe in 'everything should be configurable'.  This is both for my benefit, and for the end-user (or other modders).  The more config-driven the setup is, the less often you will find yourself needing to recompile for simple changes.  Recompiling (moreso the restarting of KSP) to test changes can eat up a ton of time.  Is also why I do my models and texture setup the way I do (with lots of configs) -- I'm really not a fan of using the Unity editor, and have built in every method I can think of to avoid its use as much as possible (e.g. config-defined emissive animation module).

Now just need to find some other modders who are onboard with using PBR textures/shading, so that my parts aren't all alone with their shiny new look.  I'll possibly work on converting KerbalFoundries myself... though that one will be difficult as I don't have the sources for the existing textures (er.. maybe?  will have to look through what I have, pretty sure its just finished textures).

 

Link to comment
Share on other sites

YxOymYC.png

First pass of testing a 'recolorable' PBR shader.  This is a flat plane using a 'gold metallic' base texture, with a fairly strong layer of light-brown dirt noise applied to it.

Bottom-Left = Unity-Standard shader - standard texture; color baked into albedo/diffuse map (same texture as top-left).  Control sample.
Top-left = SSTU-Standard shader - standard texture; color baked into albedo/diffuse map
Top-Right = STU-StandardRecolorable shader -- gray base texture, color added through shader to match the standard texture output
Bottom-Right = STU-StandardRecolorable shader -- gray base texture, color added through shader - recolored with red tint, colored stripes added to base texture (stripes are flat colored; the variations are caused by the differences in MET/SMOOTH maps).  There is a slight undesired tinting to the colored stripes that I'm unsure I'll be able to completely remove (note the blue stripe looks slightly purple), but I've got a few ideas to investigate.

The most noticeable differences in the samples compared to the Unity Standard shader are mostly from the lighting angle.  As long as the inputs are setup appropriately, the recoloring shader does allow for adding of colored dust/etc effects, while mostly maintaining accuracy towards the original texture colors.

 

1 hour ago, CobaltWolf said:

Sorry, as much as I love and respect ShadowMage's work on this I can't see myself remaking everything for a PBR workflow unless it was generally adopted. 

 

 

1 hour ago, Beale said:

See above.

PBR is awesome, (seriously @shadowmage nice job), but it's more work than I can handle right now.

 

 

Pretty much the responses I was expecting -- I'm under no illusion that PBR will be widely adopted in KSP until/unless it is supported (and used) by the stock models/textures.  Creating textures is a ton of work; PBR textures potentially even more so.  I fully understand the reasons to stay with the current KSP shaders and texturing process, and can't hold it against anyone.  My intent is not to 'push' this system on anyone, but merely make it available to those who wish to use it.

 

Link to comment
Share on other sites

@Jimbodiah Didn't cost anything. And who knows, maybe one day they will see the light! 

As said, it is a considerable amount of work to convert everything. The people tagged have a long long list of part in their inventory. I can't imagine how much work it is to maintain whats already in place, let alone upgrading everything. Maybe with allot of help... I have a little more hope for brand new mods. 

 

Link to comment
Share on other sites

One of the red and one of the silver panels are done using the recoloring shader.  Which one is it?  (the others were exported with specific colors and use the Standard shader)

FuIfFkK.png

Spoiler

Red = center was recolored, silver = left was recolored


While its not 100% accurate... I think this will be acceptable, especially given that most of the textures that SSTU will use are black/white/gray/silver based.  Need to find a way to restore the 'saturation' of the dust layer though; something about how it is blended renders it mostly grayscale looking.  Sadly to do this it required that I export the albedo texture as a detail mask (trasparent background), and apply it through alpha blending in the shader.  Not sure how easy it will be to use that method in SP in the long run, and I know for certain that it will result in far less interesting/detailed textures and result in textures that are unusable with any other shader setup.  Have one or two more ideas to try..

Is seeming like I'm going to end up going very simple/old-school on the recoloring setup for PBR.  Create the base textures in whatever fashion is most appropriate for the texture, and use standard color tinting to effect the recoloring.  This will of course render some textures more suitable to recoloring than others.... (silver/white will recolor better than gray/black; textures with a base color will not tint well at all, details in textures will become tinted), but I didn't do all the work to get the PBR shaders working just so I could not use a large portion of the capabilities and spend a bunch of extra time in a non-standard workflow to create non-standard textures just for recoloring.  I already have a very functional recoloring shader which will continue to be around -- so if you want to recolor your rocket, use the legacy recoloring shader; if you want nicer looking shading, use the PBR shaders.  If you want to tint the colors on the PBR shader.. that will likely be available as well... but will be entirely secondary to having nice looking and detailed textures when not tinted.

One final bit that I'm going to investigate... and this would be the real 'holy grail' for my purposes.... is Unity's use of Substances at the game-engine level.  From what I understand you can import a substance-material into Unity and use it to generate the textures for the PBR shader at runtime.  If specific parameters can be exposed properly from the substance (such as base-color), and it supports an entire layered material stack as setup in substance-painter.... it means I could simply design the materials themselves, expose the color inputs/etc to UI code, and actually generate the properly colored textures from the ground up, right at runtime.  This will likely be my research project for the day, and probably should have been one of the first things I looked at.

Link to comment
Share on other sites

@ShadowmageYou probably already know that. But color can't be the same, its not a technical issue, its the nature of the process. One sides have coloring imput that the other do not have. So, say you match the color in VAB, well they will not look the same if you take it to the moon. So don't fight it.

Link to comment
Share on other sites

Did a fair bit of research into the use of Substances in Unity and it looks like they are not very well suited for use on character models/props, being more intended for use for terrain and large tiled spaces.  What I might be able to use them for would be the fairing/decoupler/probe core textures.  As my current focus is on the regular part textures I'm going to look into this more in the future after I've become more familiar with the PBR workflow and use of Substance Painter/Designer.  In the interim I am going to make up some PBR textures for them but they will likely be simple/static setups (not much interesting stuff that you can do with a flat plane).

On the subject of fairings... last weeks' KSP dev notes stated that there will finally be a fix for the strange UV mapping that the stock fairings use coming with KSP 1.4 -- meaning that I'll finally be able to use the striped/patterned textures on the stock-fairing based parts as well.  Yay for progress :)

 

Hoping to put together an updated PBR test release over the weekend, as well as the first SSTU release with the shader loader split off as a separate dependency (boo for more folders inside GameData... but unavoidable).  Should contain updated F-1, J-2, SC-B, a few engine mounts, and MFT-A/B textures for a mostly complete Saturn-V stack for testing purposes.  Should also contain the 'finished' models for the reworked MFT-L fuel tanks and a small selection of sample textures.  I should note that the textures in the current/upcoming PBR 'test release' are only a crude representation of what the finished textures will look like; I'm still rapidly learning how to use the new tools and refining my processes and procedures (as well as still working on the shader and recoloring systems).  Should be able to start finalizing the look of the initial parts here in a few weeks; from there it will just be the long grind to re-texture 'all the things'.

 

Link to comment
Share on other sites

8 hours ago, Shadowmage said:

it means I could simply design the materials themselves, expose the color inputs/etc to UI code, and actually generate the properly colored textures from the ground up, right at runtime.

DingDingDING we HAVE a winner! That's definitely the workflow you want, I hope you can make it work.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...