lo-fi Posted July 3, 2016 Author Share Posted July 3, 2016 If I was playing, I'd miss functional wheels too. @Shadowmage I've created a branch, and working through the bits we've discussed. Do you mind if I move some code around between the classes? The wrapper seems to trigger some init stuff that I think ought to be in the wheel class itself. I'll rejig and see what you think, anyway. I'll also pull out the suspension stuff and pack some jointy goodness in, of course!! Link to comment Share on other sites More sharing options...
Shadowmage Posted July 3, 2016 Share Posted July 3, 2016 6 hours ago, lo-fi said: If I was playing, I'd miss functional wheels too. @Shadowmage I've created a branch, and working through the bits we've discussed. Do you mind if I move some code around between the classes? The wrapper seems to trigger some init stuff that I think ought to be in the wheel class itself. I'll rejig and see what you think, anyway. I'll also pull out the suspension stuff and pack some jointy goodness in, of course!! Go for it -- If you think it needs to be moved, by all means. I'm all for clean reading, looking, and functioning code. Excited to see what you come up with Link to comment Share on other sites More sharing options...
lo-fi Posted July 3, 2016 Author Share Posted July 3, 2016 Cool, I'll get something underway tonight. My back is finally feeling a little better, so I can sit in front of the pc for more than half an hour at a time! Link to comment Share on other sites More sharing options...
Madrias Posted July 4, 2016 Share Posted July 4, 2016 Sounds like things are moving along rather well. I've got an unmodified version of 1.1.3 standing by. Link to comment Share on other sites More sharing options...
TiktaalikDreaming Posted July 4, 2016 Share Posted July 4, 2016 1 hour ago, Madrias said: Sounds like things are moving along rather well. I've got an unmodified version of 1.1.3 standing by. Such a thing doesn't exist, surely? Link to comment Share on other sites More sharing options...
Madrias Posted July 4, 2016 Share Posted July 4, 2016 4 minutes ago, TiktaalikDreaming said: Such a thing doesn't exist, surely? I've got a couple different versions of KSP, both modded and unmodded. I have a bone-stock version of 1.1.3 set aside, as I have for 1.0.4 (sadly, I didn't think to do the same for 1.0.5...) and 0.90, and 0.25. I've also got modded versions of 1.1.3, 1.0.5, 0.90, and 0.25. And modded versions going back to 0.18... I archive a lot of stuff. Link to comment Share on other sites More sharing options...
Rushligh Posted July 4, 2016 Share Posted July 4, 2016 On 6/29/2016 at 2:21 AM, Madrias said: Tank steering, or is there a return-to-center mode on hinges in there? Might have to try it if it's the second. actually, the center of the wheels are made of KSPI reaction wheels. their own force keeps the wheels from wobbling with IF. they also help preform dynamic steering.(so yes, tank steering). you could implement more hinges, but that's quite unstable. Link to comment Share on other sites More sharing options...
Little Hyena Posted July 5, 2016 Share Posted July 5, 2016 This looks really amazing does this work with 1.1.3? Link to comment Share on other sites More sharing options...
TARDISES Posted July 5, 2016 Share Posted July 5, 2016 36 minutes ago, Little Hyena said: This looks really amazing does this work with 1.1.3? The move to Unity 5 back at 1.1.0 broke the mod. The rover body still works (in terms of resources) but the wheels and repulsors do not. If you had read any of the past several pages, you'd know that the main focus right now is to get them working again. Link to comment Share on other sites More sharing options...
Supergamervictor Posted July 5, 2016 Share Posted July 5, 2016 I am in no way trying to push or ask for an update.. But is it possible to try out the new system? I wouldn't care much if it breaks my game. If anything, I'll be helping in bug reporting. But reading the past post, I can see you guys are having great progress in making a whole new system and are close to finishing it I assume? Take your time to iron it out though. Link to comment Share on other sites More sharing options...
lo-fi Posted July 5, 2016 Author Share Posted July 5, 2016 I'm afraid close to finished would be an overstatement... A lot of work has been done, but there's a way to go before even a tentative public release. Link to comment Share on other sites More sharing options...
Rivvik Posted July 5, 2016 Share Posted July 5, 2016 Can't wait for this fantastic mod to be updated for 1.1.3! Been listening to Wipeout music alot again and have been hankering for the repulsors back. Do what you need to do, but you're no good incapacitated, so make sure you take care of yourself first! Link to comment Share on other sites More sharing options...
Cyrious Posted July 10, 2016 Share Posted July 10, 2016 On Tuesday, July 05, 2016 at 6:25 PM, Rivvik said: Can't wait for this fantastic mod to be updated for 1.1.3! Been listening to Wipeout music alot again and have been hankering for the repulsors back. Do what you need to do, but you're no good incapacitated, so make sure you take care of yourself first! Same, definitely want this mod going again, except for me to make my massively oversized mining crawlers. Yeah, there are better options for wheels, but having 4 clusters of 12 wheels holding up a 60 meter long mining crawler loaded with nearly 250 tons of freshly mined resources is awesome. Link to comment Share on other sites More sharing options...
Shadowmage Posted July 11, 2016 Share Posted July 11, 2016 (edited) A bit of personal investigation this morning revealed some interesting details regarding the U5 wheel colliders. They may not be totally unusable for our purposes... but they are -extremely- sensitive to settings changes and the set of RB's + joints must be put together -just perfectly- or the whole thing blows up, and the friction model is complete garbage and causes tons of... fun... errors. My test case for today was taking a standard vehicle asset, adding 4 additional rigidbodies with wheel colliders, and using fixed-joints to attach those RB's to the vehicle body. If the suspension is setup appropriately and the rigidbody masses are set appropriately, the whole thing is fairly stable. Friction would still have to be handled externally/manually, and I've not yet found a way around the rigidbody mass ratio wonkiness. But... this is just another of the 'possibilities' that needed investigation, and I don't really expect it to work out anyway. It also doesn't appear to solve any of the problems that -really- needed solving such as bump-stop and sticky friction... but it does give a method for suspension. In the end though, I don't think this will work out as it would require moving mass around between the actual parts' rigidbody and those rigidbodies created for the wheels to reside on. And due to the mass-ratio wonkiness... this becomes highly problematic as you need the wheels to have close to the same mass as the body they reside on, which is simply not the case in KSP (e.g. body may be 100 tons, with each wheel being maybe 1 ton... nowhere close to the 2:1 that the engine is looking for). Going to keep poking around at this for a bit to see if I can figure out exactly what those wheel-colliders are doing and if there might be a way to use them in game, and then I'll likely start working on learning all the various Unity joint options and playing with a joint-based implementation. Hopefully we'll be able to find some implementation that doesn't have suspension stability problems. Edit: After playing with the U5 wheel colliders a bit more... for like the 8th time... I've come to the conclusion that Lo-fi is 100% correct; they are about as stable as a stack of ping pong balls... on a freight train.. during an earthquake; in other words, absolutely terrible. I can get them to work(?), but only under very specific circumstances and settings... which obviously is not going to work correctly in KSP with its widely variable vehicle configuration(s). On to the good news: Unity's Spring Joint component seems to work well. An initial quick prototype/testing implementation is looking extremely promising. Not sure why these 'just work' while configurable joints were giving me hell... but I'll take the (potential) win. Using these still allows for use of the multi-mode suspension sweep method, so ray/sphere/capsule-casts are all still an option. It -appears- to work okay as far as bump-stop goes (for stopping overcompression), though I haven't tested it thoroughly, and it still doesn't give me access to the -actual- sprung mass (needed for friction) when bump-stop is reached. But.. progress is progress... at this point I'll take what I can get. Things were -so close- to working before I discovered the harmonics issue with the force-based suspension, I'm glad that there might still be a potential to get this all working. @lo-fi How are things progressing with your investigations? Should perhaps look into meeting up in IRC or something sometime this week to have some actual discussions; figure out what the rest of the requirements are, mull over ideas for how to implement them, share knowledge on joints, etc... Edited July 11, 2016 by Shadowmage Link to comment Share on other sites More sharing options...
0111narwhalz Posted July 11, 2016 Share Posted July 11, 2016 2 hours ago, Shadowmage said: you need the wheels to have close to the same mass as the body they reside on, which is simply not the case in KSP How...How is that ever the case? I can't imagine that has any basis in reality. Pretty sure I could name half a dozen single components heavier than all four wheels in a real car. Link to comment Share on other sites More sharing options...
Shadowmage Posted July 11, 2016 Share Posted July 11, 2016 (edited) 1 hour ago, 0111narwhalz said: How...How is that ever the case? I can't imagine that has any basis in reality. Pretty sure I could name half a dozen single components heavier than all four wheels in a real car. It is quite normal(?) for simulated physics constraints to 'blow up' when the relative mass between the bodies is highly disproportional; its actually one of Unity's 'avoid doing this' things. Sadly, video game physics does not mimic real life (or else this would have all been finished months ago...). The more I work with Unity... the more impressed I am that the KSP devs got the U5 wheels working -at all- given the intrinsic problems the wheels have with simulation stability and all the various implementation limitations that are in play. Oh.... and I figured out why me and most Unity joints weren't getting along very well... apparently you need to setup the joint secondary axis to be along the local negative Y axis (where it defaults to +Y). Now all of the limits/position stuff make a bit more sense and tend to explode less. Edited July 11, 2016 by Shadowmage Link to comment Share on other sites More sharing options...
TiktaalikDreaming Posted July 11, 2016 Share Posted July 11, 2016 On 05/07/2016 at 8:09 PM, lo-fi said: I'm afraid close to finished would be an overstatement... A lot of work has been done, but there's a way to go before even a tentative public release. I'm hoping nothing in 1.2 KSP causes issues. It shouldn't, seeing as this is a new wheel framework, but it still makes me nervous knowing there's an update coming. And seeing how much work has gone into this. Link to comment Share on other sites More sharing options...
Rushligh Posted July 12, 2016 Share Posted July 12, 2016 (edited) 4 hours ago, Shadowmage said: Now all of the limits/position stuff make a bit more sense and tend to explode less. I legit laughed. (not sarcasm, i mean it was funny) Unity tends to have a problem with joints in general sadly. I hope the next version of unity will have better wheel collides. I suppose an alternate option would be to use the Character pill colider as a translation colider and program the supposed friction as relative to the direction yourself, thereby bypassing unity wheel coliders as a whole. I don't know if that's an option based on how KSP is built; im only familiar with stock Unity. Edited July 12, 2016 by Rushligh Link to comment Share on other sites More sharing options...
damerell Posted July 12, 2016 Share Posted July 12, 2016 (edited) 9 hours ago, Shadowmage said: It -appears- to work okay as far as bump-stop goes (for stopping overcompression), though I haven't tested it thoroughly, and it still doesn't give me access to the -actual- sprung mass (needed for friction) when bump-stop is reached@lo-fi I'm sorry about @-tagging lo-fi but the blasted new forum edit box won't let me edit it out of the quote. Could we live with the assumption that the sprung mass can be assumed to be that which the spring compression would suggest? At a rough guess this will happen for two reasons. We've just hit a bump too fast, in which case the situation is going to be ephemeral - we'll BANG down on the springs for one tick but then bounce back up again. An underassessment of the contact force for that one tick isn't going to matter - if the wheels were slipping for that one tick, they're slipping during the not-bottomed-out ticks too. The vessel is much too heavy and the springs are constantly bottomed-out. This is a very bad design anyway - eg we'll probably have a hefty penalty to rolling resistance for ticks where the springs are bottomed-out - and the loss of the "correct" friction will probably only become significant if the vessel is a few times the weight the suspension is designed for, a design that ought not to work anyway. Sure, there's a marginal case where the vessel is nearly too heavy and keeps bottoming out the springs... but then the friction was nearly-right anyway. Edited July 12, 2016 by damerell Link to comment Share on other sites More sharing options...
CarnageINC Posted July 12, 2016 Share Posted July 12, 2016 Im curious, I've been following all the wheel collider shannegans for a bit now. Has anyone from Squad assisted the community with any sort of documentation or advice? I would of hoped they would of passed on their hard earned lessons to these great group of modders for KSP. If they haven't, should we all ask them to do so? I know it not necessarily their job to provide such information or help but it would be nice to see them provide some guidance. Link to comment Share on other sites More sharing options...
Shadowmage Posted July 12, 2016 Share Posted July 12, 2016 13 hours ago, damerell said: I'm sorry about @-tagging lo-fi but the blasted new forum edit box won't let me edit it out of the quote. Could we live with the assumption that the sprung mass can be assumed to be that which the spring compression would suggest? At a rough guess this will happen for two reasons. We've just hit a bump too fast, in which case the situation is going to be ephemeral - we'll BANG down on the springs for one tick but then bounce back up again. An underassessment of the contact force for that one tick isn't going to matter - if the wheels were slipping for that one tick, they're slipping during the not-bottomed-out ticks too. The vessel is much too heavy and the springs are constantly bottomed-out. This is a very bad design anyway - eg we'll probably have a hefty penalty to rolling resistance for ticks where the springs are bottomed-out - and the loss of the "correct" friction will probably only become significant if the vessel is a few times the weight the suspension is designed for, a design that ought not to work anyway. Sure, there's a marginal case where the vessel is nearly too heavy and keeps bottoming out the springs... but then the friction was nearly-right anyway. That is mostly my current thinking behind it. I'm going/was going to use a regular collider to act as the bump-stop (with zero friction on it), and the suspension force used will be that given for fully compressed springs. The only 'edge cases' it runs into are much as you describe, with pretty much the exact symptoms you've outlined. This prevents overcompression and provides a very solid 'bump stop'; about the only bad bit I've run into while testing is that sometimes this collider can 'snag' on the edges of other colliders in unpleasant ways when bump-stop is momentarily reached (for example when running high-speed onto a ramp the springs are compressed far beyond normal). Of course that was all with the force-based suspension model which has proven to have harmonics issues with joints at low simulation frequencies (~50hz, you know.. the frequency range used by unity physics updates). Hmm.. thinking on that... I wonder if adding a second joint between the wheel part and the body its attached to would help eliminate/reduce the microjitters? That is certainly something that could be done by the wheel module code, and would allow for use of all of the existing work on the force-based suspension (which really was working quite well aside from that and the other unsolved features). Re: 1.2 will have zero impact on the work that Lo-fi and I are doing, except perhaps a positive impact if they happen to actually fix the U5 wheels with Unity 5.4. However, reading through the Unity patch-notes, they have done no such thing. Unity has made very minor improvements/fixes to the wheels, but absolutely nothing that will change our need to come up with a custom solution. So, don't worry about 1.2, it will have no impact on our wheel efforts. It -might- bring some slightly better stock wheels (less buggy due to clipping), but it will not solve any of the other problems that we are trying to solve (arbitrary wheel orientation, proper spring/damper physics, non-jittery friction model). Link to comment Share on other sites More sharing options...
damerell Posted July 12, 2016 Share Posted July 12, 2016 34 minutes ago, Shadowmage said: Of course that was all with the force-based suspension model which has proven to have harmonics issues with joints at low simulation frequencies (~50hz, you know.. the frequency range used by unity physics updates). I suppose the idiot question here is, can't small displacements just be thrown away somehow to eat oscillations? Link to comment Share on other sites More sharing options...
Shadowmage Posted July 12, 2016 Share Posted July 12, 2016 (edited) 32 minutes ago, damerell said: I suppose the idiot question here is, can't small displacements just be thrown away somehow to eat oscillations? Umm... not really sure what you are trying to express there. The oscillations happen on microscopic timescale and are a direct result of the Unity joints in relation to their parent body (e.g. one tick it moves up, the next tick it moves down, with the other sides' wheels doing the opposite each tick, repeat til tired of watching it jitter). No amount or method of adding more forces to the body will correct it, and will in fact only make it worse, as it is the unity Joints causing the oscillations. Reducing the forces applied will only act to reduce the suspension forces. It basically comes down to 50hz is just not fast enough for high-fidelity spring/damper simulations given the limitations on joints and wide mass ratios. 500hz might be, but that is 10x the normal physics rate and would absolutely cripple the already low framerates experienced on large vessels. 1000hz is what is recommended for spring/damper simulations for springs smaller than several meters in length or for anything that requires millimeter precision (which we do); which is unfortunately not a realistic option for most video game physics setups. I've experimented with adding in a 'smoothing' function for suspension forces, but in the end it ended up acting like an additional damper, slowing overall suspension response. Might be more that can be done with it, but it would require altering the rest of the suspension parameters to account for the changed dynamics. I never did investigate the smoothing function as a fix for the harmonic jitters; I was testing them out as a fix for the 'hit a tiny bump in the road at high speed and get insane spring force from instant compression'... but I may take another look at it as it concerns the harmonics problems. Edit: The reason we started investigating joint-based suspension setups as a solution to the harmonics is because Unity has access to internal sub-step integration for its own joints and constraints; I believe the default is 4 sub-steps (for an actual update frequency of 200hz). However user-created scripts have no access to physics sub-step integration, so it is not an option to use that method for force-based suspension (Unity only calculates accumulated user-added forces and integrates them once per FixedUpdate; so even if I were to do my own sub-steps, I have no information on how the rigidbody would have actually changed during the last sub-step, and would have to use the same 'start' state for each sub-step... which amounts to no change vs. the current setup). Edited July 12, 2016 by Shadowmage Link to comment Share on other sites More sharing options...
damerell Posted July 13, 2016 Share Posted July 13, 2016 I think the problem is this, which I'm writing down so you can tell me if I'm wrong. Suppose our vessel is sitting still. There is a "rest spot" where gravity exactly balances suspension force, and it ought to come to a rest there. However, if it starts slightly below it a tick's worth of net upward push (which ought to diminish during the tick, but doesn't because of the granularity of the ticks) may leave it slightly above the rest spot so a tick's worth of net downward push will leave it slightly below the rest spot - perhaps even further below than where it started. A smoothing function sounds like might help with that. (I also wonder how much people will notice jitters when driving over a rough surface). Link to comment Share on other sites More sharing options...
Shadowmage Posted July 13, 2016 Share Posted July 13, 2016 15 minutes ago, damerell said: I think the problem is this, which I'm writing down so you can tell me if I'm wrong. Suppose our vessel is sitting still. There is a "rest spot" where gravity exactly balances suspension force, and it ought to come to a rest there. However, if it starts slightly below it a tick's worth of net upward push (which ought to diminish during the tick, but doesn't because of the granularity of the ticks) may leave it slightly above the rest spot so a tick's worth of net downward push will leave it slightly below the rest spot - perhaps even further below than where it started. A smoothing function sounds like might help with that. (I also wonder how much people will notice jitters when driving over a rough surface). Yep, that is pretty much exactly what is going on. But with more wheels involved each side of the vessel can be on the opposite side of its 'swing', so it doesn't just bob up and down a bit, but rapidly jitters with a left/right/forward/backwards roll as each wheel independently manages its suspension force. Add in the Unity joints to the situation, and you quickly get into a harmonics problem where the left wheel will push up, which pushes the right wheel down; next tick the right wheel pushes up, which pushes the left wheel down; repeat until forces are changed from external interaction. And that is why increasing the simulation frequency appears to eliminate the problem (in reality it doesn't; it merely decreases the severity of the problem so that it is no longer noticeable or large enough to have any real impact). Smaller physics ticks = smaller forces = less overshoot = appears stable and smooth Link to comment Share on other sites More sharing options...
Recommended Posts