Jump to content

Porkjet

Members
  • Posts

    568
  • Joined

  • Last visited

Posts posted by Porkjet

  1. 2 hours ago, blackrack said:

    What do these reflection probes entail? Can we just write a plugin to render cubemaps of the environment/sky and use those with the PBR shaders? Because I'd be down for it.

    Probably. Tho there are some difficulties due to the way the flight scene is composed. Also since we're stuck with Dx9, we lack some features that make realtime probes look better, smooth transitions between mip levels and 'edge fixup'. What's probably a better way is using premade cubemaps that are switched depending on situation (landed, low orbit, etc) perhaps even per biome. They don't really have to precisely reflect the surrounding, approximating the general colors of terrain and sky will do. However there's still the problem that 'up' and 'down' are quite relative in KSP, and the cubemap will be rotated depending on where you are on the planet. (at equator everythings on the side) It should be possible to modify the lighting model to be able to manipulate the cubemap 'rotation' tho. That's something I'll look into for the next update.

     

    2 hours ago, nli2work said:

    reflection probes are not absolutely necessary. A proper skybox for planets instead of the color gradient will make the biggest differece. Same transition point from planet to galaxy skybox. Probably make a noticeable different by changing Ambient Light source from skybox (unity default) to gradient in the Lighting setup, and match the gradient colors to the specific planet's atmosphere gradient. It would even make a noticeable difference to legacy shaders. Using reflection probes just to get ambient lighting for PBR is an incredibly wasteful.

    We can't use gradient ambient in flight scene because as mentioned above, there are no defined 'up' and 'downs' in the flight scene, at the equator of a planet the ambient gradient would be tilted 90°. Reflection probes aren't wasteful at all, we'll probably only need a single one in the flight scene, and ambient is only one part of the visual benefits it brings. There's no reason to switch to PBR at all without reflection probes.

  2. A new download with updated shaders will be posted any minute.

    LightWrapped/Specular basically does what the name suggests, it uses a custom lighting model that "wraps" light further around an object. It was used on some new IVA props as a cheap way to simulate light bouncing in interiors, but I probably won't use it any further and lightmap props instead. Might be useful for other things tho. Other uses include fake subsurface scattering like on skin, or other slightly translucent or soft materials

    fig16-02a.jpg

     

    ScrollingUnlit and Standard_Bumped are experimental and nowhere used yet

     

    25 minutes ago, Dr. Jet said:

    BTW, not exactly 1.1 question, but... how to set shaders for decals (FlagTransform) so that they are invisible in part list (before flag texture even applies)? Setting no texture results in disgusting white rectangles, setting fully transparent substitute "texture"... it will work... but Squad parts don't use that.

    Create a Tag "Icon_Hidden" and add it to the flag mesh

     

  3. @Eskandare Don't animate each flap seperately, it's easier to just put the animation on vane_center and animate all four at once from there.
    Having a gimbal and animation keyframes on the same object might cause problems. Try something different, put another child object under the Gimbal that rotates thrustTransform, move it a few meter away from the nozzle, then define an FXModuleLookAtConstraint in the cfg that points the vanes (Z+) towards the empty child. Might have to edit your model for the orientations or reorganise them under new empty transforms.

    name = FXModuleLookAtConstraint
            CONSTRAINLOOKFX
            {
                targetName = (empty child of gimbal)
                rotatorsName = (vanes here)
            }

  4. 31 minutes ago, Lilleman said:

    I didn't find a good way to use reflection probes in Unity's editor, it'll probably be too expensive to update reflection for each part, since none of them will provide a real reflection. Even without them, it makes a noticeable difference.

    Not really a good difference tbh. On very shiny surfaces the specular highlight becomes very small and cubemap reflection sharper and more pronounced. Without the cubemap it just looks wrong.

    In unity editor it's real simple to add a reflection probe. Just add the object, its in the lighting menu, and add the correct settings. Make sure the bounds are large enough to cover your objects and set it to realtime, play around with the settings, you'll notice when it works.

    There probably are ways to mod reflection probes in too. Whatever people use to get cubemap reflections for the windowshine mod, that might actually be useful for PBR. And realtime should be no problem for any half-decent PC really, if you somehow get it working. The challenge is to make it work with the complex scene and camera setup in KSP but it looks like modders have solved that already.

  5. 1.1 doesn't have reflection probes (cubemaps) yet, which are fundamental to this lighting model, so PBR is currently useless.

    256 values are more than enough for metalness/gloss/occlusion. But note that texture compression is also an important factor here. RGB channels are compressed quite heavily, while Alpha channel offers the best quality. Because of that it's best to store occlusion in alpha to preserve smooth gradients. Other maps are usally fine with any RGB channel.
    There's no correct way to do the masks, but there are calibration guides for various basic materials that really help get good results. For metalness generally you want either full white or black values. In-between materials are very uncommon, and you'll want mid-values only for transitions if anything, or stuff like a thin dust layer covering a metallic surface.
    Unity offers two workflows for PBR materials. Specular and Metallic. I plan to use the Metallic workflow eventually.
    Here are unity calibration charts for both workflows:

    Metallic: http://blogs.unity3d.com/wp-content/uploads/2014/11/UnityMetallicChart.png
    Specular: http://blogs.unity3d.com/wp-content/uploads/2014/11/UnitySpecularChart.png

  6. Not 100% sure if I can see the problem. Are you talking about the seemingly random contrast on the ribbing?
    Are you sure it actually did export mipmaps? Without mipmaps it tends to look pixely and aliased.
    Does gimp provide any MIP export options? I use NVidia texturing tools + PS, one can choose different sharpen/soften settings etc for mipmaps there on export.

  7. Drag cubes can be overidden yes, I could do that if necessary. But it probably really isn't that big of a deal I guess.

    @Gryphorim I guess in reality since they rely on pressure for structural stability, they'll allways need to have higher pressure on the inside. So at 5atm at eve sealevel they'd need ...6atm inside? Not a problem to do probably, but nothing we have to worry about in KSP anyway :)

  8. 3 hours ago, electronicfox said:

    When I did morph animations for an unfolding blimp part, I managed to bake the blend animation to a number of joints. It ended up being like 200 joints, but it didnt seem to affect performance too badly. With the parts I've seen for this mod, you could probably use a similar setup. 

    Alternaively, I believe these inflating animations can be replicated with just a few manually animated joints (If you'd be willing to send me just one of the models, I can confirm this for you). Its far cheaper than many joints baked from a blendshape animation, and I believe will have near enough to the same results.

    That was my original plan. It's easy enough for simple inflatables, but horror for complex stuff like centrifuges. And there's another problem. Scaling bones doesn't affect the normals of the mesh. So if I manipulate a spherical module wby scaling some bones to take up a cylindrical shape, the normals and way the mesh is shaded will still behave as if it was spherical. And normals in KSP aren't just a visual thing anymore, they also affect how drag cubes are generated. Faulty normals = faulty drag cubes. We learned that the hard way with the inflatable heat shield. Had to resort to folding it down with a bunch of radial bones rotating in like the spokes of an umbrella just to manipulate the normal halfway decently, that took many hours of nasty manual tweaking. I was hoping to be able to avoid those problems with the new part tools but looks like I'll have to stick to the nasty and time consuming bone workflow for now. At least slightly incorrect drag cubes aren't a big problem for these space modules i guess

×
×
  • Create New...