[1.0.x] [V1.9f] Kerbal Foundries wheels, anti-grav repulsors and tracks

[lo-fi]

The dust was looking all fine and dandy for me! Thick, lustrous and plentiful. The white box under the repulsors is just a visible debug that needs turning off. The lights turning off I maybe did break; won't be hard to fix that.

[lo-fi]

Actually, I maybe did break the camera. I'll fix that later.

[Gaalidas]

Alright, I'll prepare to run another test of the dust myself later on then. With any luck, we'll be able to keep our release schedule.

[lo-fi]

Don't worry, I know what's wrong without even looking at the code. Won't be hard to fix

[Gaalidas]

show-off.

[lo-fi]

Right, I've got it. Repulsor lights were an easy fix.

For the dust colours, basically, the biome dust colours are really bold, while the camera colours are very subtle. For example: 0.75,0.75,0.75,1 is three quarters of the way to full white. The output from the camera has far lower values, so when the two are averaged, the biome colour is quite dominant. The whole thing is something of a compromise..

[Gaalidas]

Well, that leaves us with an unfixable bug then because there are areas around the KSC that are flagged as the incorrect biome. How can we get camera output less subtle? Unless I can make the camera usable on its own, then we're always going to have snowy particles, or default colored particles, in those improperly flagged areas.

I've been struggling for quite some time trying to figure out why the camera particles are so subtle that I can't even see anything when they're running alone, but the biome colors are super strong when used alone. They used to be moderately subtle before we introduced the camera, but now if I use them together I see very little effect from the camera because the errant flagged areas of the planet still display the wrong particle colors. The whole purpose of a camera was so that we could eliminate those issues. For that, we need a camera that isn't so subtle that the biome colors overpower it at every turn.

EDIT: okay, I was able to eliminate the subtlety by eliminating the division process of the colors on the camera, however I found that the camera only gave me a grey color. my theory right now is that is is being affected by the ambient light (I'm testing at night due to the repulsor lights) and spitting out the grey because it's only getting a dark grey color in the first place. In the end, we're pretty much stuck. If we can't sample the terrain color without the ambient light affecting the output, then I'm unsure how to make this really work properly.

EDIT 2: Nope, I tested it just now during the daylight and I must conclude that the camera is not working properly at all. Using only the camera to grab the color information, other than the alpha value which I'm pulling from the biome defines, all I get is a light grey. It seems that the camera will no longer output anything else. I don't see anything especially wrong or different than what it did before that would cause this, so I'm stumped.

Edited August 6, 2015 by Gaalidas

[*Aqua*]

Check what the camera sees. If it's right above the vessel or even clipping inside it, then you'll probably only see grey because most parts are grey.

[lo-fi]

I'm afraid it's a case of "it is what it is". The intelligent way to treat the problem is to tone down the difference between the two biome colours that are clashing. You can check the camera quite easily; just don't set it inactive after its done it's thing. You end up with an old GTA style top-down driving game. Except the craft will be invisible because of the culling mask. Yes, the dust camera is affected by lighting. To do anything else would need some shaded shenanigans, I believe.

[Bakase]

Funny you should mention that, nli2work did a cool POC of that, and was asking about syncing the legs. Sort of on the back burner until I have a flash of inspiration for how to do it

I'd love to! I think it just uses one of the stock sounds. What I think would be percect is the lovely soft turbine sound from the drone at the start of Interstellar. Submissions welcomed with open arms for sound clips, though!

Did you ever get a sound recorded for this? If not, I've got an idea I can experiment with after work today... Not promising any good results, though!

This idea just popped into my head at work now, a couple of months later... ¯\_(ツ)_/¯

[lo-fi]

Please feel free to send over I've got something that's better than the screech before, but it's not brilliant.

[Gaalidas]

Check what the camera sees. If it's right above the vessel or even clipping inside it, then you'll probably only see grey because most parts are grey.

Already nullified by setting the culling mask.

I'm afraid it's a case of "it is what it is". The intelligent way to treat the problem is to tone down the difference between the two biome colours that are clashing. You can check the camera quite easily; just don't set it inactive after its done it's thing. You end up with an old GTA style top-down driving game. Except the craft will be invisible because of the culling mask. Yes, the dust camera is affected by lighting. To do anything else would need some shaded shenanigans, I believe.

I realized some of my idiocy this morning while waking up. It's amazing what the brain can do when it's well rested. I'm thinking there has to be a way cull out the lighting conditions. Either that, or make the dust super subtle or super dark when running at night. I'm going to have another look at the culling masks, and/or look for a way to detect the overall lighting. Anyway, if all else fails I'll just go with what we have that's working on the repo... assuming that all works well enough still?

I think we can probably keep our tentative schedule and get this out to the people on say... Friday maybe?

EDIT: So, I actually discovered and witnessed the performance drop when using the camera. That thing really does cost some hefty resources. I'm running along with a repulsor craft (converted a rover into a repulsor and stuck 8 monoprop engines on the back) and I decide to switch off the dust effects and suddenly my FPS jumps up a bunch. So, I'm thinking we'll just have to include a disclaimer with the DustFX feature that accuracy of the colors depends on the accuracy of the biome definitions for the planet. If the planet has improperly tagged biomes that do not match the textures, then issues will happen.

Edited August 6, 2015 by Gaalidas

[lo-fi]

Yeah, let's do it. This stuff is just tweaks; nothing that has the potential to seriously break things if we change some of the maths later down the line. As it is, it works, the mod is pretty stable. And it fits fine with the "1.9 is last beta running up to 2.0 release" model.

I realised I can do repulsor light far better, so I'm just tweaking that. Beyond that, we've only got config tweaks and enhancements that live in releases to come. I think we'll go for a Friday evening release? Any objections?

[smjjames]

Just wondering out of curiosity how the dust colors work, do they take the color from the ground directly or do they use the biome map (which I think someone said that earlier), which has all kinds of colors?

[Gaalidas]

Yeah, let's do it. This stuff is just tweaks; nothing that has the potential to seriously break things if we change some of the maths later down the line. As it is, it works, the mod is pretty stable. And it fits fine with the "1.9 is last beta running up to 2.0 release" model.

I realised I can do repulsor light far better, so I'm just tweaking that. Beyond that, we've only got config tweaks and enhancements that live in releases to come. I think we'll go for a Friday evening release? Any objections?

No objections here. Something for you to look at when you get a chance though is the interaction between the water and the repulsor fields. As it turns out, the frictionless behavior of the repulsor doesn't work when over water. You actually slow down quite quickly, and you get splash effects when your ride height is below 50 or so (didn't actually look at it, might be more like 35).

I was just going to ask how I could adjust the light origin to not be at the collision point, but if you're working on it then I'll leave that alone. I still intend to do some more fiddling with the dust which I'll merge in when you've committed your light changes. It'll be a close call with a Friday evening release, but I think we'll make it.

- - - Updated - - -

Just wondering out of curiosity how the dust colors work, do they take the color from the ground directly or do they use the biome map (which I think someone said that earlier), which has all kinds of colors?

Good question, and I think I can answer. There are two modes that the dust colors can take. First mode, and this was the mode I built in to the DustFX class before merging with KF, is that the location of the vessel is taken and compared with the biome map. When the biome is identified it then compares the biome name with a set of predefined colors for the body and biome that the craft currently resides in, and then outputs the dust with that predefined color. The actual color of the biome on the biome map is not used if the predefined color is set properly, otherwise you'd get some really whacky colors.

The second mode is using a camera. In the original camera mode a 6x6 resolution image is taken every few frames, culled to show water and local scenery only. The colors are then indexed and added to each other and divided by the total number of colors present. This gives us an average of the colors present on the camera. We then create a new color based on that information and pass that to the dust.

There are two different ways of handling this data now that it's been passed to the DustFX class. The first one is that the camera color (a subtle representation of those colors) is added to the biome definition-based color for the current biome and then divided by 2 to get an average between the two, and then passed to the dust. The second option is to simply pass the camera colors directly to the dust, however I still set the alpha transparency to the current biome defined alpha channel. This is the mode I'm fiddling with right now actually, so the exact behavior is not yet set in stone... err... binary.

[lo-fi]

Oh, that's interesting. Something changed? I'm sure that never used to happen. Oh, hold on. May be the light transform it's seeing as being in the water. That'll be fixed anyway.

Edit: Ninja'd! Gaalidas' explanation is better.

- - - Updated - - -

Also, I thought I'd see what the hi-def versions of certain parts might end up looking like:

[Gaalidas]

Also, I thought I'd see what the hi-def versions of certain parts might end up looking like:

That's wickedly awesome. You wouldn't even need a normal map on that baby. You've got to get some high-def versions configured for us to try out. Especially considering KSP seems to be able to handle high poly counts rather well.

I especially like the vibrancy of the blue in the wheel rim.

[lo-fi]

I know, right. KSP could use a splash of colour here and there. The "Could you make it more stock?" brigade tend to make many things end up a dull shade of grey. I'l admit that wasn't deliberate, though; it's what 3D studio decided to assign it. Wait until you see it in-game decked out with compressing springs, flexing pipes, steering arms and all that sort of jazz.. The poly count isn't even that high!

[Darren9]

It looks incredible, how many poly's is it?

[lo-fi]

Just under 5k, so less than some of the tracks.

Neat, huh? I'll probably remodel it all again, that was just a few minutes messing around. Unity is pretty slick on anything remotely modern, so I'm always far less concerned with raw poly count than I am render calls or the use of mesh colliders.

Edited August 6, 2015 by lo-fi

[Gaalidas]

Love the musical selection on that one too. Those are awesome. Should definitely keep those around as a possible content-overhaul update in the future.

Just spotted your changes on the repository. I'd like to fiddle over the next afternoon (by the way, what time zone do you reside in?) and see what else I can come up with to fine tune things, but if your latest commit was featured in that video, then as far as wheels are concerned it looks great. my tests have been solely on the repulsors because of the greater distance between them and the ground where the dust is being spawned.

I do wonder if some of the directional stuff you did with the repulsors could be applied to the wheel dust so that we don't get as much of the dust particles intersecting with the physical models of the wheels/craft, but I don't want to touch any of that now just in case I break it again. I think for 2.0 of KF I'd definitely like to put more control into the configs to specify what happens when that specific wheel calls for a dust plume. For instance, I want parts like the screw-drive to occasionally throw up a CollisionFX-style spark out (complete with light and sound) as it travels over the terrain, as well as emitting dust plumes not only backward but also outward in a direction that would be consistent with its current rotation. So, in the future I expect to be swapping out the boolean "isRepulsor" for an enumerated list of possible part-types that will have modifiers based on that type. I also enver did really get a good hold on how I might add more watery looking particles when hovering over water, which would also be needed for when propelling through water with the screw-drive. I really hate the stock effect for water impacts.

Anyway, I think we're almost there.

As for the splashes of color thing... I love color, but there's just one problem with that: matching. The reason we stick to greys, blacks, and whites is because they can fit together rather nicely. When you introduce color you exponentially increase the complexity of making something look "right" in the context it is in. That's why i've been bugging a number of plugin authors that have implemented a form of color-switching to their parts to expand it into a revival of KerbPaint. KerbPaint works for some still, but for others it really has problems. it's mostly due to the restrictions the recent versions of KSP (0.90 and onwards) put on certain shader-based effects such as glowy-outlines requiring AA to be active, which kills my machine. Glowy-outlines never killed it, but AA does so I'm stuck without my glowy-outlines. The modding community here really needs a new spin on KerbPaint to be developed, and I ain't the one skilled enough for it.

Edited August 6, 2015 by Gaalidas

[lo-fi]

Ah, I often forget to turn the music off when I video capture. No doubt that one will get whacked by YouTube, then... This productions has been brought to you by Simian Mobile Disco. Just be glad I wasn't listening to This Will Destroy You...

Go ahead, though I realised I need to revert some changes which ultimately broke the camera dust colour. Won't need much. But go for it, I'm leaving the code alone for a little while apart from that unless bug whacking needs to occur. The directional stuff isn't too hard, so long as you've got a handle on vectors. That all sound great; I have some enhancement ideas too. Occasional sparks from the screws would be really cool!

Maybe look at what FireSpitter did to remove the stock splash effects? I've no doubt we can probably find the particle for the water splashes, which is actually quite nice, just not used well. If we can do that, splashes for wheels being used for propulsion and repulsors hovering over will be quite easy. We would just need to swap to that particle.

Did nobody pick up Kerbpaint? Shame!

Edited August 6, 2015 by lo-fi

[GDJ]

Hi!

I was wondering if you had the config code to add a parking brake to the tracks? The long tracks don't have a parking brake (GUI selection after right click that says "BRAKES ON/OFF).

[NoMrBond]

MOARdv made something similar to KerbPaint which was used in the KOSMOS-URM releases where you could set part RGB colours

If you want something for changing colours then you could ask them about that part of their plugin [github link]

[lo-fi]

Thanks, that might be interesting to look at.

Parking brake? Not sure what you mean.. Just click the icon and the brakes stay on until you hit the brake key or click it again to release.