lo-fi

Hmm, I've never seen PartTools look like that.. You're using correct Unity and PT Try creating an empty GameObject in the scene and adding PT to it. Get the same thing?

Normal service will resume when I recover... Thank you for your patience... Oh, and I devised a new grip model while diving today!

I'll get back to you guys more fully later - far too busy nearly killing myself on horseback and getting drunk to do much else. There are no special cases made for anything at the moment, so dust is thrown if wheels are grounded and moving. The code I used is meant for taking screen shots - hence the references, and I used commented out sections as an aid to fighting out if the camera was working. It does no saving or writing currently, would be far too slow! I'm sure it can still be optimised though.

Ah, of course! I just got it to write out the new file for reference, and I'm glad it didn't overwrite the existing one. Was just to check the names really, as I knew you'd pondered how the writer worked a few posts back. I'm still sure the error lies in the logic, as there are many checks that set default colour, rather than spit errors out. Which is great, but not helpful finding the fault. Some debug statements printing what the plugin thinks its doing throughout the process ought to reveal the offending line. I know you want to learn, which is why I haven't gone too far at each step. You get into the branch ok, and understand what I've done there? I'll add some comments when I get a few minutes

Also, I've just added a regenerated biome def file. The KFDustColorFileWriter class is a MonoBehaviour. It's there, but like a PartModule, it won't do anything unless it's called by something. Adding the [KSPAddon(KSPAddon.Startup.SpaceCentre, false)] attribute (?) to the class causes it to be run when entering the Space Centre, at which point it spits out a new file. It looks like the biome names are OK, but the original has some rounding applied. Given that, I suspect some kind of logic snafu in the code that deals with grabbing either the biome name, or the colour. It's defaulted in the code, so changing the defaults will allow you to prove that. Adding in some debug.log lines ought to be able to reveal the rest. I'd advise refactoring the code with the KF prefixes again to prevent issues with the CollisionFX classes of the same name.

It's all in the dev branch of KF_plugin Awesome stuff! Yeah, I can't leave well alone... The changes are principally: KFModuleWheel: grabs hit info from the colliders, then calls a method in KFDustFX KFDustFX: No longer triggers with OnCollisionEnter and OnCollisionStay VesselTools: ModuleCameraShot has been created which takes care of the camera colour grabbing stuff. KFDustFX grabs the colour info from it, rather than the biome dictionary.

Doh! I just realised the wheel configs won't work without a previously unreleased version of the plugin. That, and they all need torque and rolling resistance updates. Oooops.

If you can handle Blender, you'll be able to work with Unity! Good work, its something I've been meaning to do for ages.

That's exactly what the existing code does

We're a little limited by bodging a stock effect, so that's just how they are. Looks like the fade out, such as it is, is built into the effect. So it is.... Anyway, I've got some interesting tools for measuring performance, so I'll be doing a little testing of both methods.

Looks like a great tool. I find Blender hard too - hat's off to those who manage with it! What are the UVmap / unwrapping tools like in Daz?

Oh, I've been messing about with all kinds of stuff. I think that was set to update every twentieth render frame, which is the cause of the delay. There are emitter options for fade, aren't there? I'll have a poke at it next time I'm in front of the PC.

Yeah, anything is possible really

You'll get used to it, Unity really isn't difficult for the tiny bits we use making KSP parts. By the way, this actually works! That's using a camera set to render a 6x6 texture. I'm currently wondering if just setting it to a size of 1x1 makes Unity do all the hard work averaging for us.... I'll experiment. I'm kinda leaning towards mixing this method up with the biome colours. The "live data" could be mixed with the master biome colour, which could lead to some awesome effects. Either way, I'll need to optimise and smooth the updates somewhat, but I think we're onto a winner Any tips on optimisation welcome...

So I've got some really rough POC code with a camera: public class ModuleCameraShot : VesselModule { private bool takeHiResShot = false; private int resWidth = 128; private int resHeight = 128; public static string ScreenShotName(int width, int height) { return string.Format("{0}/screen_{1}x{2}_{3}.png", Application.dataPath, width, height, System.DateTime.Now.ToString("yyyy-MM-dd_HH-mm-ss")); } public void TakeHiResShot() { takeHiResShot = true; } //[KSPEvent(active=true,guiActive=true,guiName="Take Shot",name="Take Shot")] public void Update() { takeHiResShot |= Input.GetKeyDown("k"); if (takeHiResShot) { var _vessel = GetComponent<Vessel>(); var _cameraObject = new GameObject("ColourCam"); _cameraObject.transform.position = _vessel.transform.position; _cameraObject.transform.LookAt(_vessel.mainBody.transform.position); _cameraObject.transform.Translate(new Vector3(0,0,-10)); Debug.LogError("created camera"); var _camera = _cameraObject.AddComponent<Camera>(); RenderTexture rt = new RenderTexture(resWidth, resHeight, 24); _camera.targetTexture = rt; Texture2D groundShot = new Texture2D(resWidth, resHeight, TextureFormat.RGB24, false); _camera.Render(); Debug.LogError("rendered something..."); RenderTexture.active = rt; groundShot.ReadPixels(new Rect(0, 0, resWidth, resHeight), 0, 0); _camera.targetTexture = null; RenderTexture.active = null; // JC: added to avoid errors Destroy(rt); Destroy(_cameraObject); Color[] texColors = groundShot.GetPixels(); int total = texColors.Length; float r = 0; float g = 0; float b = 0; for (int i = 0; i < total; i++) { r += texColors[i].r; g += texColors[i].g; b += texColors[i].b; } Color averageColor = new Color(r / total, g / total, b / total); print(averageColor); takeHiResShot = false; } } } I'm sure it could be more efficient, but it actually does what's required. I see what you mean, xEvilReeperx. The current code does what it's supposed to, but it's not in my nature to leave well alone, so I feel compelled to see where the other path takes me, even if it turns out just to be an intellectual exercise. As Zodius points out, it's far easier poking about in the Unity model to finalise the node positions. I usually (if I'm not just guessing) just plonk an empty GameObject under the root of the model and take the relative position from that. The stuff in there doesn't change often - certainly not enough to affect the node positioning.

Awwww, look! I can create tiny, pixelated screen grabs with dynamically created cameras: This may be a long road ahead....

To the rescue again! Thanks for the tips, though probably a little out of my depth... GPU seems to get less of a hammering that CPU, so I guess it would make sense to attack it from that angle. How difficult are pixel shaders to work with? Seems like a promising avenue to pursue if it can be made to work - I guess I better do some reading!

I've not had the flipping over bug? Now you know how I felt when I was first trying to mess with wheels: I didn't even know that PartTools didn't export the scripts I was creating in Mono, and that I needed to get something to spit out a .dll to get loaded as a plugin.... As Tyren says, wouldn't be fun if it was easy! There's some code knocking about to iterate over pixels in a textures - I can probably adapt that. We could use the new VesselModule to aim a camera at the planets surface for each vessel, take a snap, average the colour and leave DustFX to grab that. Code here takes care of how to get the camera to grab an image. We'll get away with quite a small grab, and it'll be quite nice to have some variation in the colour as a small sample will average quite differently to the next. I was going to explain, but I might as well just get on and do it...

It happens "Work fast and break stuff"

Yeah, it's going to take a bit of figuring out. Makes a heck of a difference to the dynamics, though. No damage model as yet.

*grin* There's lots of stuff to break... And to address a point made above that I forgot about, the mass of a vessel is now correctly passed to the wheels, so they don't accelerate at the same rate regardless of how heavy a vehicle they are propelling. Strap powerful wheels to a light vehicle with the default torque settings, and chaos will ensue. Or strap small wheels to a heavy vessel and you'll go nowhere fast. The config stuff all needs balancing, as it's now all over the place, though. Suggestions welcome! Tracks should just about be OK - I haven't even touched wheels.

I've got a feeling they've changed the names in 1.0. I don't recall seeing landed at crawlerway before, for example. Also, dust used to change brown when driving off the slope at the side of the runway. Looks like it's not getting an expected name and defaulting, but I've not looked any further. Unless you're looking for the NullRef you may well miss them. Only used to happen when deleting a part in the editor, or changing scene to space centre. Hoping it's fixed now anyway You might as well ignore the experimental modules, they will be all over the place. I might start marking as such or you'll end up tidying stuff that will never see the light of day!

Gaalidas, I've created myself a branch for the new DustFX stuff called DustFXDev. I'm slowly unpicking and simplifying the code - so far so good. Results shown here What I'll do is hack all the methods down, then hand over to you for tweaking. That's all driven from KFModuleWheel, using the hit info from the wheel colliders. So much simpler you're not going to believe! The current method works just on speed, but I'll create one that works on slip and another for impact. If you can leave the DustFX stuff in the master branch alone while I'm messing with this stuff it'll make it a lot easier merging it back. I'm only really working on DustFX.cs - the rest is absolutely fine as-is (I think) EDIT: I can't see why the biome colours aren't working any more. Any ideas?

I guess you never know what's going to happen. Kinda cool knowing we're keeping people entertained while we go about our work.... Funnily enough, I've just been filling the offending module with just that! Though I think there's a subtle logic error (the code is full of funny double negative boolean checks), so it's going to be a pig to track.

ARRRRGGGGGGHHHHH damn merge conflicts!!!!! Made a right mess this time