Jump to content

[WIP] Dangerously Shaded Stock Refresh


DangerouslyDave

Recommended Posts

@DangerouslyDave This is an answer about your normal-map decals problem. As it became a big wall of text, I've hidden it.

Spoiler

For 'normal-map decals', you will need a deferred shading pipeline. And a full blown one too, one that store the tangent-space normals in the G-buffer (they usually store the screen-space ones). The reason is you need to blend the 'background' and 'decal' normals in tangent-space. This is also the reason you don't see normal-map decals in most games.

You could get around that limitation by passing the object world matrix to the decal shader, maybe, that could work if the decal instance is meant to be applied only on a mesh instance. But that will lead to glitches if another mesh is caught in the projection area of the decal instance, so to speak. To solve that kind of things you will need an 'object-id' in the G-buffer.

The problems don't ends here, unfortunately. When the layout of a G-buffer is designed, one of the major constrain is bandwidth both in reading and writing the attachments. Normals are usually stored as 2 components in the map, as you can recover the third if you store them in tangent space. In the gbuffer instead, they get 'encoded' in an innumerable number of creative ways: spherical mappings, hemi-octagonal, etc. They may well be impossible to blend using the hardware blending equation, as you are trying to blend non-linear encodings possibly. Not to mention the shader start to become quite complex, overcoming the speed gains you had by not having a normal map in the first place.

Another problem: a G-buffer layer has usually 4 components, and you are going to apply the decals using blending. Blending assume the 4th component store 'alpha', and that is used in the blending equation. So you will have problems depending on what is actually stored in the 'w' component of the layer that store the normals.

Disclaimer: I know nothing about what kind of G-buffer unity is using, or even if it has a deferred pipeline, or if it does have it but KSP is using a forward renderer.

 

Edited by ShotgunNinja
Link to comment
Share on other sites

On May 14, 2016 at 1:01 PM, ShotgunNinja said:

@DangerouslyDave This is an answer about your normal-map decals problem. As it became a big wall of text, I've hidden it.

  Reveal hidden contents

For 'normal-map decals', you will need a deferred shading pipeline. And a full blown one too, one that store the tangent-space normals in the G-buffer (they usually store the screen-space ones). The reason is you need to blend the 'background' and 'decal' normals in tangent-space. This is also the reason you don't see normal-map decals in most games.

You could get around that limitation by passing the object world matrix to the decal shader, maybe, that could work if the decal instance is meant to be applied only on a mesh instance. But that will lead to glitches if another mesh is caught in the projection area of the decal instance, so to speak. To solve that kind of things you will need an 'object-id' in the G-buffer.

The problems don't ends here, unfortunately. When the layout of a G-buffer is designed, one of the major constrain is bandwidth both in reading and writing the attachments. Normals are usually stored as 2 components in the map, as you can recover the third if you store them in tangent space. In the gbuffer instead, they get 'encoded' in an innumerable number of creative ways: spherical mappings, hemi-octagonal, etc. They may well be impossible to blend using the hardware blending equation, as you are trying to blend non-linear encodings possibly. Not to mention the shader start to become quite complex, overcoming the speed gains you had by not having a normal map in the first place.

Another problem: a G-buffer layer has usually 4 components, and you are going to apply the decals using blending. Blending assume the 4th component store 'alpha', and that is used in the blending equation. So you will have problems depending on what is actually stored in the 'w' component of the layer that store the normals.

Disclaimer: I know nothing about what kind of G-buffer unity is using, or even if it has a deferred pipeline, or if it does have it but KSP is using a forward renderer.

 

@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:

7cuVCM9.png

y7uP7qQ.png

 

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!

Link to comment
Share on other sites

3 hours ago, DangerouslyDave said:

@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:

7cuVCM9.png

y7uP7qQ.png

 

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!

SSTU did it somehow.

Link to comment
Share on other sites

3 hours ago, DangerouslyDave said:

 

y7uP7qQ.png

 

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!

Depends what you mean by " it changes the entire part to be defined as a parachute. ".  The part's category should be whatever is set in the cfg file.  But, any given part can only have one staging capability.  So, if you have some other module that triggers staging (engines, decouplers, etc) then one module will over-ride the others.  I've had to build single decouplers as three parts before to get it to decouple from the upper stages, retro rocket burn, and then decouple from the lower stages.  It's just a "feature" of KSP.

Link to comment
Share on other sites

 

19 hours ago, _Augustus_ said:

SSTU did it somehow.

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.

Edited by DangerouslyDave
Link to comment
Share on other sites

@DangerouslyDave

Some initial feed back after futzing around the config and such, I haven't had the chance to try this in game, as my game currently won't load (nothing to do with your fine capsule, just an on going issue I'm having).

  • CoPOffset & CoLOffset listed twice and at different values (one set is copied from the MK1 pod I believe).
  • since you have the parachutes built in, consider maybe using the stagingIcon = PARACHUTES instead of COMMAND_POD that way you get the safety indicator.
  • blackBodyRadiationAlphaMult = 0 ...wut do?
  • I wanted to say something about the ablator, but I don't really know how to read the values, so I'll pass. I usually include a builtin ablator anyway in my MK1 pod, copied from the stock heat shield, but your's is different, and I don't know what to make of it. At first blush it looks like it deteriorates faster than stock? No idea really.
  • re:SSTU labs dependency. I'm a big fan of Shadow Mage's work, however that's a big dependency for just (at this point in time) one pod. Looking at the config, it looks like you can get away with just the parachute texture "SC-GEN-PAR-ORANGE-DIFF" and the plugin itself. If you go down the path of hard dependency with all/most your parts, maybe consider redistributing the relevant pieces (licensing/permissions allowing). Currently SSTU is 200MB+. I'm just thinking from an end-user perspective, ease of use. You get what I'm gettin' at I think. 
    • Not sure if possible for Realchute support going forward? Obviously this is minor, but all you really need is a cap/canopy name and deployment/predeployment animation names. I think.

All I have at the moment.

Cheers.

Edited by Deimos Rast
Link to comment
Share on other sites

1 hour ago, Deimos Rast said:

Some initial feed back after futzing around the config and such...

  • re:SSTU labs dependency. I'm a big fan of Shadow Mage's work, however that's a big dependency for just (at this point in time) one pod. Looking at the config, it looks like you can get away with just the parachute texture "SC-GEN-PAR-ORANGE-DIFF" and the plugin itself. If you go down the path of hard dependency with all/most your parts, maybe consider redistributing the relevant pieces (licensing/permissions allowing). Currently SSTU is 200MB+. I'm just thinking from an end-user perspective, ease of use. You get what I'm gettin' at I think. 

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?

Edited by DangerouslyDave
Link to comment
Share on other sites

2 hours ago, DangerouslyDave said:

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?

I would rather see new parts. I don't really use IVAs much myself. I know some people really really (really) like them, but it seems they take forever, and often times just sideline new content. There are a lot of quality ones out there and it's easy enough to throw an RPM standin in the meantime (since there is already an RPM patch that auto replaces your mk1podcockpit with an upgraded one on the pod for example).

Also, when loading the pod I got an NRE on the RCS module, but in honesty, I was messing around in the configs, so it could have been me (but I didn't touch the RCS). Is the thrustTransform on the RCS module "RCS" ?

---edit----

wasml has the proper answer:D

Edited by Deimos Rast
Link to comment
Share on other sites

4 hours ago, Deimos Rast said:

...when loading the pod I got an NRE on the RCS module, but in honesty, I was messing around in the configs, so it could have been me (but I didn't touch the RCS). Is the thrustTransform on the RCS module "RCS" ?

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.

Link to comment
Share on other sites

 

Probably a me issue then, as the Kraken itself has taken over my install. I wouldn't worry about it.

Grabbing the tanks now.

  • I compared their configs to their stock counterparts, and they match perfectly. (Perhaps too perfectly. I could be wrong about this, as I am about many things, but I believe if you look at the max/min drag values you'll find they should be flipped. Unless there is a reason why max_drag = 0.2 and min_drag = 0.3. To be clear, Stock does it this way, and does it a lot, and I don't know why. It's trivial, whatever, but it irks.)
  • Ah good, you took out the space in the folder name.

Hmmm, I bet a decoupler would go nicely with these tanks...too bad I have to slum it an use stock decouplers for...another day, or week, or whenever. The agony.:D

Link to comment
Share on other sites

Good News, Bad News, Boss. I took the Dragon Capsule for a spin (turns out the RCS works fine). I really like the heat shield texture by the way (see screenshot). Everything worked fine...except the parachutes never fired. I had them set to 2500m, and as I descended it kept saying "Packed-Unsafe." At 3500m it still said the same, so I nuts to this and hit deploy, at which point it switched to "Armed-Unsafe". Then I crashed (it never fired, even below 2500m). RIP Jeb.

Re:Fuel tanks. Not sure what I think about them. I really like the modeling, that goes without saying, and the crispness of the lines. I think it might partially be that so far everything (dragon/tanks) is basically white (although I like the white you've chosen). Also, the 400 tank's black doesn't match the 800 tank. I like the 800 the best, since the exterior of the others reminds me more of concrete. Let me repeat though, the ends are fantastic. As you mentioned though, they're not for the current shaders. But really, how exciting do fuel tanks need to be?

Looking forward to the next production.:)

Picture of the heatshield during re-entry; what's the text on the bottom by the way?

GXPzFbY.jpg

Edited by Deimos Rast
Link to comment
Share on other sites

  • 2 weeks later...
On 5/19/2016 at 0:59 PM, DangerouslyDave said:

@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.

 

More gores on the tank please and longer. I guess they can be shorter (are shorter, apparently, in the new SLS tanks) but definitely more please.

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...