lo-fi Posted May 16, 2016 Author Share Posted May 16, 2016 I might start testing the new wheel collider as a repulsor, see how it goes. They don't need grip, torque or anything like that, so probably an ideal part to start using them on. 17 hours ago, Shadowmage said: Had some unforseen ...'obligations'... pop up that took up a bit of my time this weekend, but I've synced up my repo and have started looking into what you've done so far. Should hopefully have an understanding of all that later today and be able to start working on the rest of the missing bits. Might have something to show for it sometime tomorrow (have tomorrow off from work and should be able to devote a fair chunk of time to wheel dev work) RL takes precedence Link to comment Share on other sites More sharing options...
Shadowmage Posted May 16, 2016 Share Posted May 16, 2016 (edited) 3 hours ago, lo-fi said: I might start testing the new wheel collider as a repulsor, see how it goes. They don't need grip, torque or anything like that, so probably an ideal part to start using them on. RL takes precedence Tried using the script that you had in the repo, but I could not get it to do any suspension forces; the 'wheels' would act like they wanted to suspend something, and then fall off entirely. Likely is a hierarchy setup error on my end. So, I did a bit more work on the force-based setup that I had; have the spring damper working well enough, and the friction model is no longer doing strange things Turns out it was a silly mistake of allowing negative spring-force values, which was causing some...bad... things to happen when that down-force was used to calculate the lateral friction. Smooth as butter now, no longer getting flung off into space or having wierd torques on jumps, and it is overall responding as I would expect (given the simplistic friction model). Still need to implement a custom constraints solver and the sticky friction setup, as well as solve the punch-through issue (which should be solvable through some simple colliders in the model, or even with the constraint system). But.... progress Playing around with it a bit they exhibits excellent dynamics regarding the forces at play on the vehicle. Crank the friction way up and roll-overs become possible, but they are very predictable and not spazzy like the old KSP wheels were... you know these are coming, and you can watch the vehicle suspension to tell you when it is near (from the body-roll and/or inside tires leaving the ground ). With a better (more curve-based) friction model I think this system could really shine. Edit: Sorry for the low-rez video, didn't realize it would come out so... terrible (and was still ~500mb...) Edited May 16, 2016 by Shadowmage Link to comment Share on other sites More sharing options...
ComatoseJedi Posted May 16, 2016 Share Posted May 16, 2016 Progess is progress. Even if it was a low rez video @Shadowmage Link to comment Share on other sites More sharing options...
TiktaalikDreaming Posted May 16, 2016 Share Posted May 16, 2016 2 hours ago, Shadowmage said: the 'wheels' would act like they wanted to suspend something, and then fall off entirely. That's reminiscent of a car I had while a uni student, so seems perfectly realistic to me. :-) Link to comment Share on other sites More sharing options...
lo-fi Posted May 16, 2016 Author Share Posted May 16, 2016 5 hours ago, Shadowmage said: Tried using the script that you had in the repo, but I could not get it to do any suspension forces; the 'wheels' would act like they wanted to suspend something, and then fall off entirely. Likely is a hierarchy setup error on my end. I think I know what happened there - it's a quirk of how my test rig is set up, and how my script doesn't handle many eventualities. Call it a difference of construction on your part, and an error on mine! Lovely work your end, it's looking great! Link to comment Share on other sites More sharing options...
Shadowmage Posted May 17, 2016 Share Posted May 17, 2016 Going to start playing around with the sticky friction/constraints setup over the next few days; hoping to have something that might be usable by this weekend. Initially would likely be a super basic 'get it working' implementation, but gotta start somewhere. My current thoughts on those lines are to basically keep track of the current local velocity of the wheel and if has been below X m/s for at least X updates, flag it for 'sticky=true' for that direction (side or forward). When sticky friction is enabled it would take note of the axis-local positioning for that wheel and attempt to keep that wheel positioned within that plane. Currently I'm trying to think through how to handle the front/steering wheels with sticky friction; even when 'sticky' is enabled they still need to be able to impart some torque on the vehicle in order to facilitate the actual turning; -something- will be sliding as long as the vehicle is in motion. Honestly with what I got working yesterday it is nearly ready to be setup for use in-game. The only blatantly missing feature is the sticky friction; something to stop it from sliding on hills when sideways/brakes are engaged. Link to comment Share on other sites More sharing options...
SpannerMonkey(smce) Posted May 17, 2016 Share Posted May 17, 2016 I saw that he mentioned in-game, sounds promising, I know how delicate this procedure is so not got any expectations although I do have a folder with around 20 broken sets of wheels awaiting the arrival of correctly named transforms and colliders. I also have a small queue of people wanting my wackier off road suspensions working again, thanks to whatever madness overtook the stock wheels it's no longer possible to combine two wheel units on the same axle, or more annoyingly you can, it wont even throw an error, it will just show one wheel permanently blocked. So if all your magic includes that I'll be a happy bunny, i'm guessing it does as (conventionally modeled ) tracks would be a bit tricky without it. Keep up the good work, we can't rove without you Link to comment Share on other sites More sharing options...
Shadowmage Posted May 17, 2016 Share Posted May 17, 2016 (edited) 4 hours ago, SpannerMonkey(smce) said: I saw that he mentioned in-game, sounds promising, I know how delicate this procedure is so not got any expectations although I do have a folder with around 20 broken sets of wheels awaiting the arrival of correctly named transforms and colliders. I also have a small queue of people wanting my wackier off road suspensions working again, thanks to whatever madness overtook the stock wheels it's no longer possible to combine two wheel units on the same axle, or more annoyingly you can, it wont even throw an error, it will just show one wheel permanently blocked. So if all your magic includes that I'll be a happy bunny, i'm guessing it does as (conventionally modeled ) tracks would be a bit tricky without it. Keep up the good work, we can't rove without you Right now I'm concentrating on the base 'component' -- this is the bit of code that replaces the old U4 WheelCollider component. It will be done as generically (and stand-alone) as possible so that it may be re-used for any number of situations. So it won't be subject to any of the stock wheel whackiness; no limit to the number of wheels on a model, part, or vessel. No limitations to orientation compared to rigidbody (it will use whatever orientation the 'wheel collider' transform is oriented at; -including- animation handling). Am also aiming to keep it as close as possible to using the same interfaces as the old U4 wheel component; the same options/parameters should be available. However they will likely require a custom PartModule to 'drive' them -- to position the suspension transforms where they need to be, update visuals for the wheel/steering rotations, and supply input values. This is the bit that may need to be provided by mods' on their own; there is just no way for me to write a single module that could accommodate all other mods' potential model hierarchy and preferred methods for model setup; nor do I wish to impose any limitations on the use of the components. For instance lo-fi would use his existing PartModule code (slightly adapted to the new wheel component), and I would use my mods' existing PartModule code (or new stuff that I cook up just for the purpose). In the end the component -should- be compatible with all of the KSP 1.0.x various wheel-modules, with some adapatation to use the new component. For example the old FireSpitter wheel and leg modules -should- be usable with the new component with some minor code-changes. I -might- include a generic PartModule whose aim would be to be compatible (model setup wise) with the stock model setups, so as to enable a patchable replacement for the stock mess. Really won't know too much more until I start digging into it a bit more. Should have an update in a few days/later this week Edited May 18, 2016 by Shadowmage Link to comment Share on other sites More sharing options...
lo-fi Posted May 18, 2016 Author Share Posted May 18, 2016 12 hours ago, Shadowmage said: However they will likely require a custom PartModule to 'drive' them -- to position the suspension transforms where they need to be, update visuals for the wheel/steering rotations, and supply input values. This is the bit that may need to be provided by mods' on their own; there is just no way for me to write a single module that could accommodate all other mods' potential model hierarchy and preferred methods for model setup; nor do I wish to impose any limitations on the use of the components. For instance lo-fi would use his existing PartModule code (slightly adapted to the new wheel component), and I would use my mods' existing PartModule code (or new stuff that I cook up just for the purpose). Yep, that's where the KF plugin comes in. Great work! Link to comment Share on other sites More sharing options...
Madeiner Posted May 18, 2016 Share Posted May 18, 2016 So uhm, i understand this has no 1.1.2 compatibility for wheels. How about repulsors? Can i just use those in 1.1.2 for now, or will they break anything? Link to comment Share on other sites More sharing options...
lo-fi Posted May 18, 2016 Author Share Posted May 18, 2016 I'm afraid everything was based around wheel colliders, which are what's been causing so many problems, so everything is broken in 1.1.X until further notice. We are working on a solution. Link to comment Share on other sites More sharing options...
Gnoyze Posted May 19, 2016 Share Posted May 19, 2016 Will you guys be supporting 64x in unity 5 now? or still gonna hold off on that? Link to comment Share on other sites More sharing options...
0111narwhalz Posted May 19, 2016 Share Posted May 19, 2016 35 minutes ago, Gnoyze said: Will you guys be supporting 64x in unity 5 now? or still gonna hold off on that? I imagine that comes with supporting 1.1.x, though I have little to no idea. Note: KF still doesn't support 1.1. Yet. Link to comment Share on other sites More sharing options...
TiktaalikDreaming Posted May 19, 2016 Share Posted May 19, 2016 1 hour ago, 0111narwhalz said: I imagine that comes with supporting 1.1.x, though I have little to no idea. Note: KF still doesn't support 1.1. Yet. Mods will automatically support both 32bit and 64bit Link to comment Share on other sites More sharing options...
lo-fi Posted May 19, 2016 Author Share Posted May 19, 2016 There were a lot of people who used KF fine in previous versions of KSP 64, so I see no reason why there should be an issue going forwards. I used to offer no support for X64 because squad didn't (and it was flaky at best), but made no effort to stop people using it. My own experience suggests that 1.1.X is about as stable as a 6' jello tower, whether 64 or 32, so mileage may vary. Link to comment Share on other sites More sharing options...
Shadowmage Posted May 19, 2016 Share Posted May 19, 2016 @lo-fi Got to play around with trying to enable sticky friction a bit yesterday. It looks like your setup using kinematic rigidbodies + specially configured joints may be the answer there as well. Basically would be using these to cheat in some constraints. One bit I haven't quite figured out is how to align the joints to the wheel rather than the part/base rigidbody... but that's likely just some trig/vector math to set it up properly. The limited testing I did seemed to work...decently. Need to find a way to allow the joint to break when it is intended to switch to dynamic friction, and need to find a way to allow the wheels to steer while sticky friction is enabled. Joint breaking is likely just a joint configuration, and the steering torque... well.. I could merely convert the sideways-friction from steering into a torque on the rigidbody when side-sticky is enabled. I'm just hoping that all of the joint manipulation isn't too performance intensive. The current raycast and friction code is fairly good performance wise, likely faster than the mess of modules and code that runs the stock wheels, and would like to keep it as... lightweight... as possible. Some things have to be handled though, and joints might just be the best way to cheat around the sticky friction problems (other than implementing a custom constraint solver.... may still come down to that...). One other bit that I'm struggling with for the low-level component is how to allow it to be used in the editor / imported through KSP .mu model files. The struggle is that it cannot; part-tools only supports a specific hand-coded list of unity components; anything not on the list is ignored when compiling the model. So as far as use in KSP is concerned the wheel-collider component is always going to need a PartModule to instantiate the components and assign them to game-objects/assign rigidbodies; there is no way around it that I can see. The closest that could be done would be to have yet-more-special code in the PartModule that searched for the standard Unity WheelCollider, removed them and replaced that with the custom components (which is what the stock-replacement-module will do, but would rather just rely on transform-names for my mods' setup; I really hate dealing with stuff in the Unity editor if it can be avoided). Any thoughts on the best way to handle that issue? Link to comment Share on other sites More sharing options...
lo-fi Posted May 19, 2016 Author Share Posted May 19, 2016 A few - think I can help with most of that. I'll get back to you when I've got a few minutes for a full reply Link to comment Share on other sites More sharing options...
damerell Posted May 19, 2016 Share Posted May 19, 2016 I'm back from Leipzig and am following this with bated breath, since I'm no use at this stage. (To whoever asked about CKAN support earlier, however; since I am the one person involved who likes CKAN, I will do my meagre best to ensure everything works correctly.) Link to comment Share on other sites More sharing options...
Shadowmage Posted May 20, 2016 Share Posted May 20, 2016 (edited) On Thursday, May 19, 2016 at 4:04 PM, lo-fi said: A few - think I can help with most of that. I'll get back to you when I've got a few minutes for a full reply Yeah, whenever you have time is fine with me; my expected time-frame for getting this working is weeks-to-months; I'm not in any real rush. Would rather take my (our) time and do things properly the first time around On that note I've started laying out the basis for the 'stock replacement' wheel module. Will (hopefully) be doing some compiling and in-game tests of the existing stuff over the weekend. The wheel collider component is nowhere near finished, or even ready for general use, but I would like to make sure the existing functionality actually works in KSP before building on it too much more (sucks to find out it doesn't work when you are 95% done...would rather find out what works/doesn't while at the 20% stage). This will also let me become more familiar with the current stock wheel/gear/leg model hierarchy and get all of the mesh-positioning stuff figured out. Edit: Well, that was mostly painless: Obviously there are things still to be fixed, but in that image the pod is being suspended properly by the wheels, without any whackiness, twitching, launching into orbit, or any of the other 'bad stuff' that happens with the U5 wheel colliders. Progress! Edited May 20, 2016 by Shadowmage Link to comment Share on other sites More sharing options...
Shadowmage Posted May 21, 2016 Share Posted May 21, 2016 Initial tests on using configurable joints for sticky friction are giving some promising results. Need to do a bit more tweaking on them, cleaning up the validation on when they should be applied, but they don't seem to cause any strange behavior so far. So... yeah... more progress I've updated the repo with the latest in case anyone else is following the development and wanted to give things a try. The included Unity project should be setup to just click 'play'. Link to comment Share on other sites More sharing options...
lo-fi Posted May 21, 2016 Author Share Posted May 21, 2016 I've had no time to do much this week. Great progress, glad my work on the joints wasn't a total waste of time! Link to comment Share on other sites More sharing options...
Shadowmage Posted May 24, 2016 Share Posted May 24, 2016 @lo-fi No worries, whenever you have time Last night I did a bit more playing around with the integration into KSP; there are going to be some problems with the stock wheels due to them no longer using the WheelCollidersIgnore layer (all colliders in the model that I'm testing with are set to layer 0). So I might need to add a list of colliders to force-set the layers on. Alternatively I'm highly considering finding a method to just ignore any collider that is on the same vessel as the wheel (no same-vessel collisions sounds... proper). I'm just not sure of an optimal/efficient way to implement this (seems like per-tick iteration of every collider in the vessel would drag performance down). But.... its still looking good. Went into this knowing that there would be some hacks that needed to be done to work around some of the stock setup, so its not a huge surprise or anything. Disappointing, sure.. but not surprising. Spent a bit of time today integrating a sideways friction curve (rather than a constant), and tuning the sticky-friction detection and implementation routines. So far so good on those. I've implemented the friction curve as a mass-adjusted curve; e.g. you would normally specify your extremum and asymptote values dependent upon the mass the wheel is supporting; that kind of setup is a simple no-go for KSP as the mass will vary between vessels. Instead the curve takes input as the slip ratio, and outputs a value that acts as a multiplier to the current downforce; so you can still have extra-sticky wheels, while avoiding the spazzy behavior from a mass-dependent curve used incorrectly. After that came a bit of toying around with forward friction / wheel inertia / motor input torque. This is so that drive wheels can slip and spin out from motor torque and that the traction effects from those will work properly. Traction control could be implemented at the PartModule level to decrease input torque when excess slippage is detected. Its... working... at the moment, but not very clean; I don't think I've implemented it quite properly in this first pass... but that's what first passes are for It is still constant based at the moment, will also be adapting this to use a friction curve (which may be different than the sideways friction curve!). So, more progress. One bit at a time, but its all slowly starting to come together. Link to comment Share on other sites More sharing options...
lo-fi Posted May 24, 2016 Author Share Posted May 24, 2016 5 minutes ago, Shadowmage said: Last night I did a bit more playing around with the integration into KSP; there are going to be some problems with the stock wheels due to them no longer using the WheelCollidersIgnore layer (all colliders in the model that I'm testing with are set to layer 0). So I might need to add a list of colliders to force-set the layers on. Alternatively I'm highly considering finding a method to just ignore any collider that is on the same vessel as the wheel (no same-vessel collisions sounds... proper). I'm just not sure of an optimal/efficient way to implement this (seems like per-tick iteration of every collider in the vessel would drag performance down). Surely just cast a ray or two at the start of flight, see what it hits, force all those colliders to WheelCollidersIgnore layer if they're in the same part? Agreed - checking every frame seems like a bad idea. All sounds good! Link to comment Share on other sites More sharing options...
AdmiralTigerclaw Posted May 25, 2016 Share Posted May 25, 2016 Hey, @lo-fi Does the turbine generator work without needing any code changes? Link to comment Share on other sites More sharing options...
lo-fi Posted May 25, 2016 Author Share Posted May 25, 2016 I actually have no idea! I suspect probably yes, but it'll need investigating. Link to comment Share on other sites More sharing options...
Recommended Posts