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.

Having recently tackled this problem personally (and actually got it working in KSP), I can say the chances of KSP adapting the new shaders are low. The problems can be solved, and the shaders can work in KSP (with a bit of hacking) -- but all that means is that -every single existing stock art asset has to be redone- as the texture setup used by the PBR shader is completely different than the legacy diff/spec setup. You can't simply re-use the existing textures as the channel mappings are all wrong; there is also no simple ability to convert between legacy diff/spec textures and PBR textures -- each set would have to be manually reworked, and even with access to the original layered source files it would be a major undertaking. Combine that with the existing KSP art-style.... it really doesn't make any sense for stock to move to the new shader (might actually be harder to do the existing art style under the new shader setup). Would I love it if it were supported? Absolutely. But I don't personally think it is in SQUAD's plans (or really even in their best interest); there are more productive ways to spend their time than redoing already functional art. (I guess technically there is nothing stopping them from getting the shaders -working- in KSP; just because they are working/included doesn't mean they need to use them). @CobaltWolf -- if you are really interested in using PBR shaders in KSP, stop by the SSTU thread. I'll likely have them publicly available soon as a stand-alone mod/plugin. Pics in spoiler so as to not derail the thread any further...: I am personally interested if there are any wheel-physics fixes included with the updated Unity version. Namely the ability to arbitrarily rotate a WheelCollider relative to its RigidBody -- this was the single largest driving reason why I developed KSPWheel (U5 wheel colliders must be aligned with the axis of the RigidBody... and thus with the axis of the Part; makes so many things impossible to do in KSP with the U5 wheels).

I know of a few methods that could accomplish this setup, if it were something you were interested in (a single app-launcher button that would enable/disable the PAW 'customize' button for all parts). So the user would click the PAWS app-launcher button to enable it, the 'Customize PAW' button would then show up in the PAW for the parts. User clicks the PAWS app-launcher button a 2nd time, and the 'Customize PAW' button would no longer show up on individual parts. Requires setting up a KSPAddon to manage the single button (its a MonoBehavior that doesn't need to be attached to a part), and a bit of linking code to have your PartModule register itself with the KSPAddon (so that when the button is toggled, it can go through all of the 'registered' parts to update their 'guiActive / guiEditorActive' flags on the 'Customize PAW' button). Please send me a PM if interested in details / wanting help with implementation. BTW -- Just saw this mod and though -- 'wow, just what I need for my super-complex parts in SSTU'. Excellent addition to cleanup otherwise too-long-to-use PAWs

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

As I had posted in your other thread, this is likely related to manipulation of the 'landed' state. It is -super- touchy. Like absolutely neurotic. Seriously, if everything isn't done perfectly it'll blow up.

Glad you are enjoying it. And thanks @Nightside for the tech support

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

The code involving setting the landed state is... touchy. It took me a few days to get it working on KSPWheel, and I never could get it working for flying over the ocean. You can take a look at that code if you would like, though its a bit convoluted due to all the features it has to support -- https://github.com/shadowmage45/KSPWheel/blob/master/VSProject/KSPWheel/PartModules/KSPWheelBase.cs#L940-L1067 I also figured out how to do the ocean raycast handing analytically (no plane/collider needed) -- https://github.com/shadowmage45/KSPWheel/blob/master/VSProject/KSPWheel/PartModules/KSPWheelRepulsor.cs#L198-L277 . Might be of some use to you if you wanted to go that route; feel free to re-use / adapt any of that code if you want. The actual magic that does it is this function -- https://github.com/shadowmage45/KSPWheel/blob/master/VSProject/KSPWheel/PartModules/Utils.cs#L342-L359 rayPlaneIntersect(...). Allows you to define a ray, and it will tell you where it intersects with an arbitrary plane that you also define (through surface normal and point on the plane), and return the point hit by the ray, if any.

Hmm.. you might be able to hook into the physics easing stuff. Other than that... I'm not really sure. One thing that might work for you that I used on the repulsors in KSPWheel (basically a hovercraft type thing), was to add in code to manually set the craft to 'landed' state whenever it was supported by the repulsors. However as they were essentially wheels with invisible tire and suspension, it was a reasonable workaround. In the case of something that is supported by thrust alone (the typical hovercraft), that might not work as well. You might be able to still do something like that though; anytime the craft is within X meters of the ground and the hover-engines are enabled, set the part/craft to landed state. The reason this works is because when a craft is reloaded, and it was saved in a 'landed' state, it is placed into the same position it was previously. So if it was previously 5 meters above the ground, that is where it will be when reloaded (the wheel physics then kick in and start supporting it again). I'm not sure how that all relates to your exact problem. Does the 'hover engine' have some sort of spool-up time, or does it start outputting thrust the moment the craft is realoded? Or what method are you using to achieve the hovering effect? (more info on what is going on might let me offer better suggestions as to solutions).

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.

Hmm.. it is supposed to be called automatically by KSP code (through GameObject.SendMessage I believe). However it is likely not being called because your craft is not 'landed' during the game loading operation, and that code is specifically intended to handle vessels in the 'landed' state. Apologies, didn't really think that bit of it through when I put together my initial post (the function being for landed vessels). Is it called properly when your craft is initialized / launched from the editor into a regular landed state?

Test redux: Sketchfab @ManeTI -- seems to be working now. Thanks again

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.

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.