Geschosskopf Posted May 31, 2016 Share Posted May 31, 2016 1 hour ago, Kenobi McCormick said: I raise you the Kettenkrad. Sure, but it was designed from the start as a halftrack so had such nifty features to assist steering. It wasn't a temporary, seasonal conversion of what was normally a wheeled vehicle lacking such features. That's the point I was trying to make. Tracks without crossdrive are inherently bad at turning, and doubly so if they also lack a clutch-brake system. Temporary conversions usually fall into the latter category. Link to comment Share on other sites More sharing options...
lo-fi Posted May 31, 2016 Author Share Posted May 31, 2016 2 hours ago, Shadowmage said: the problem with KSP is that a vessel configuration is not static. I'm not sure what the issue actually is here? Why do the wheels raycasts need to ignore the vessel? Surely if they're contacting bits of the vessel, it's simply bad design (user error). Is there something I'm missing? Link to comment Share on other sites More sharing options...
Shadowmage Posted May 31, 2016 Share Posted May 31, 2016 (edited) 20 minutes ago, lo-fi said: I'm not sure what the issue actually is here? Why do the wheels raycasts need to ignore the vessel? Surely if they're contacting bits of the vessel, it's simply bad design (user error). Is there something I'm missing? I would mostly agree - bad vessel design is an end-user problem. Mostly this problem can be solved by applying forces both to the wheel's rigidbody -and- to the collided rigidbody (if present); if both of these are on the same vessel the net-force should be zero (though this is untested; part-to-part joint constraints may mangle these forces a bit), and if they are not on the same vessel... the response is still appropriate (equal and opposite forces). However leaving this kind of setup enabled at all is just asking to create the next Kraken-drive; phantom-forces are a bad thing, more-so when they can be intentionally created/used/abused; would prefer to avoid that situation entirely if possible. For raycasts its not too much of a problem; its fairly obvious if the wheel would be blocked when designing the vessel. For spherecasts it will be / is much more of a problem, as the spherecast may hit colliders that would not visually be blocking the wheel for skinny wheel meshes (e.g. wheel width < diameter). I could not find any method to force the sphere-cast to only pickup collisions within a specific width of the ray; even using SphereCastAll does not return enough information to remove invalid collisions as there is no way to tell if one of the 'invalid' collisions it picked up would be valid within the width of the wheel at a greater length. Edit: Just realized/remembered that the old stock wheels (1.05) actually still had the same-vessel/phantom-forces issues, which were quite exploitable for some wheels (deployable ones mostly I believe, never tried personally, nor ever ran into any problems on actual craft I designed). So perhaps this really isn't as big of a deal as I'm making it..... if its good enough for stock, its good enough for a stock-replacement module Edited May 31, 2016 by Shadowmage Link to comment Share on other sites More sharing options...
lo-fi Posted May 31, 2016 Author Share Posted May 31, 2016 If there's one thing I've learned, it's that you can't cover all the bases. Check the ray (or sphere) for rigidbody; if it's null or kinematic, ignore. Otherwise, apply one equal and opposite to the suspension. Job done. If people do stupid stuff, that's their problem. Granted, there's an annoying issue with skinny wheels and sphere casts, which I'll think on. Link to comment Share on other sites More sharing options...
ss8913 Posted May 31, 2016 Share Posted May 31, 2016 Might it be a good idea to release just the repulsors/other non-wheel parts as a separate mod so that we can start using those before the wheel issues are resolved? I've been told on the ALG thread that the wheel issues will require another Squad patch to address, so.. perhaps the repulsors and other non-wheel stuff could be separated out? Link to comment Share on other sites More sharing options...
lo-fi Posted May 31, 2016 Author Share Posted May 31, 2016 Been discussed many times before. Not going to happen - please read the thread back a few pages. Squad's wheel issues no longer apply to us; sadly, I doubt they'll ever manage to fix them anyway. Link to comment Share on other sites More sharing options...
Shadowmage Posted June 1, 2016 Share Posted June 1, 2016 (edited) @lo-fi Got the low-level collider code cleaned up, commented, and API-ified. Will be merging the changes into master branch shortly, and should be ready for initial external use/developemnt. I don't foresee needing to change the API much/at all (other than perhaps exposing a few more things); the remaining not-yet-implemented features should all be internal to the WheelCollider and not need any external interfacing. I'll be moving on to working more on the stock-replacement-module and patches from here. Still a few things to do in the WheelCollider class (sticky friction mostly), but the basic suspension and friction model seems to work well so far, and I've still got a lot of work to do on figuring out all the quirks to get this stuff working well in KSP with the stock parts/models. And.... tested sphere-cast wheels versus vertical/nearly vertical walls. This setup would be... nearly impossible... with raycast wheels, but sphere-cast wheels perform mostly logically. Ever wanted tracks to climb up vertical surfaces? Now they can (Note that sphere-vs-raycast is a simple toggle in the WheelCollider class, and can even be changed at run-time (let the user select in editor?); some wheels may need raycasts due to model setup, others may be able to use spherecasts without problem (wider wheels)) Edit: Fixed video so you don't have to listen to the FFDP I had playing when recording it... =\ Edited June 1, 2016 by Shadowmage Link to comment Share on other sites More sharing options...
lo-fi Posted June 2, 2016 Author Share Posted June 2, 2016 Awesome, that's exactly what I was hoping for with the sphere casts! I will get some time to start experimenting with your module - I'm afraid work and life in general has been mental the last few weeks. Link to comment Share on other sites More sharing options...
SpannerMonkey(smce) Posted June 2, 2016 Share Posted June 2, 2016 I've just got to comment as i can't like that little video more than once, if that behavior can truly be brought to the game I'm gonna have so much fun, even before the U5 issues, that was only possible with some serious collider and cfg trickery. one truly appreciative fan and guaranteed customer here Link to comment Share on other sites More sharing options...
V8jester Posted June 2, 2016 Share Posted June 2, 2016 What he said ^^^^^^^ Link to comment Share on other sites More sharing options...
Shadowmage Posted June 2, 2016 Share Posted June 2, 2016 6 minutes ago, SpannerMonkey(smce) said: I've just got to comment as i can't like that little video more than once, if that behavior can truly be brought to the game I'm gonna have so much fun, even before the U5 issues, that was only possible with some serious collider and cfg trickery. one truly appreciative fan and guaranteed customer here Hehe I'll do some in-ksp vids of it soon... using engines for downforce for some true wall-climbing. Mostly it comes down to if the wheel can use sphere-casts. Also note that the front tires in that video are slightly angled; only a degree or two is needed to enable the 'friction from the front of the tire' functionality (if the WC were parallel to the wall it would not detect any collisions / not detect them properly); a limitation of doing ray/sphere-casts.... but a workable one I think, as a degree or two will not noticeably impact the rest of the suspension performance and would hardly be visible for most models; in tracks the front- and rear-most wheel colliders could include that angle automatically, regular wheels would need to be offset in the editor (or have it built into the model). 4 hours ago, lo-fi said: Awesome, that's exactly what I was hoping for with the sphere casts! I will get some time to start experimenting with your module - I'm afraid work and life in general has been mental the last few weeks. No worries, I understand how it goes, RL (and work) always must take priority. I know that balancing act far too well No pressure from me on this, just making sure that I keep you up-to-date so that when you do have time you know where it all stands. Will likely have some initial 'stock replacement' testing releases here in a few days / this weekend. Few more features to implement and functions to clean up (both in the WheelCollider and PartModule), but we're getting closer Link to comment Share on other sites More sharing options...
SpannerMonkey(smce) Posted June 2, 2016 Share Posted June 2, 2016 1 minute ago, Shadowmage said: Mostly it comes down to if the wheel can use sphere-casts Good job I'm a big fat tyre kinda guy then Spoiler Link to comment Share on other sites More sharing options...
damerell Posted June 2, 2016 Share Posted June 2, 2016 1 hour ago, Shadowmage said: Mostly it comes down to if the wheel can use sphere-casts. Also note that the front tires in that video are slightly angled; only a degree or two is needed to enable the 'friction from the front of the tire' functionality (if the WC were parallel to the wall it would not detect any collisions / not detect them properly); a limitation of doing ray/sphere-casts.... Call me stupid, but surely a spherical collider is necessarily parallel to the wall? Link to comment Share on other sites More sharing options...
Shadowmage Posted June 2, 2016 Share Posted June 2, 2016 (edited) 32 minutes ago, damerell said: Call me stupid, but surely a spherical collider is necessarily parallel to the wall? A sphere isn't parallel to anything; however if the -ray- that the sphere is cast along is parallel to the wall it will never detect a collision (also, if the sphere is in collision with something when the sphere-cast starts, it ignores whatever it was already in contact with; hence you need the angle to make sure the sphere is not in contact with the wall at the start of its raycast). Edit: Add terrible graphical explanation; please not that this is a limitation of Unitys ray/sphere-cast system, and not some arbitrary limitation that I'm imposing... I - might - be able to implement some workarounds (and will be investigating them)... but that is a big maybe. I went into this project knowing nothing about wheel physics, and has been a learning process the entire way, so... yeah... might be able to come up with something Edited June 2, 2016 by Shadowmage Link to comment Share on other sites More sharing options...
TiktaalikDreaming Posted June 2, 2016 Share Posted June 2, 2016 3 hours ago, damerell said: Call me stupid, but surely a spherical collider is necessarily parallel to the wall? The limitation isn't about how a sphere would collide, but with how a Unity sphere-cast collides. If these things made sense, the wheel collider's raycast would be fine. But in both cases they attempt to model the wheel/sphere and the suspension in a single fudged approximation. Or at least that's my take on it. Link to comment Share on other sites More sharing options...
lo-fi Posted June 2, 2016 Author Share Posted June 2, 2016 4 hours ago, Shadowmage said: I went into this project knowing nothing about wheel physics, and has been a learning process the entire way I went into the project knowing a lot about wheel physics and nothing about writing code! Similarly a learning process the entire way. Do you use the . normal property of the ray/sphere hit? I haven't looked at the latest code. It might help, if you aren't already. Link to comment Share on other sites More sharing options...
damerell Posted June 2, 2016 Share Posted June 2, 2016 Oho, I understand now. Thanks. Link to comment Share on other sites More sharing options...
Shadowmage Posted June 2, 2016 Share Posted June 2, 2016 1 hour ago, lo-fi said: I went into the project knowing a lot about wheel physics and nothing about writing code! Similarly a learning process the entire way. Do you use the . normal property of the ray/sphere hit? I haven't looked at the latest code. It might help, if you aren't already. Yep; suspension forces are applied along the hit.normal. Tire friction forces are applied perpendicular to the normal with the exact axis determined through some dot/cross functions (so that the friction forces lie along the plane of the surface hit). Link to comment Share on other sites More sharing options...
lo-fi Posted June 2, 2016 Author Share Posted June 2, 2016 Cool, I was actually wondering if you were applying the traction forces according to the hit normal. I really should look at the code Link to comment Share on other sites More sharing options...
OrbitalBuzzsaw Posted June 2, 2016 Share Posted June 2, 2016 Can someone translate this into Normal Human English from Techno-Babble? AKA How close to release? Link to comment Share on other sites More sharing options...
lo-fi Posted June 2, 2016 Author Share Posted June 2, 2016 1 minute ago, OrbitalBuzzsaw said: Can someone translate this into Normal Human English from Techno-Babble? AKA How close to release? It's technical. SoonTM Link to comment Share on other sites More sharing options...
OrbitalBuzzsaw Posted June 2, 2016 Share Posted June 2, 2016 lol? Link to comment Share on other sites More sharing options...
Temeter Posted June 2, 2016 Share Posted June 2, 2016 Oh god, it's Blizzard Speak. Link to comment Share on other sites More sharing options...
lo-fi Posted June 2, 2016 Author Share Posted June 2, 2016 (edited) Honestly, it's hard to say. Shadowmage is making incredible progress creating a simulation of a wheel (far better than the garbage Unity is currently shipping with), but there's a fair amount of testing and finessing to be done before putting it out into the wild. Progress has been rapid, so at this stage I think we're talking more weeks rather than months kind of timescale. Hehe. Sorry, Temeter, couldn't resist Edited June 2, 2016 by lo-fi Link to comment Share on other sites More sharing options...
Shadowmage Posted June 3, 2016 Share Posted June 3, 2016 8 minutes ago, lo-fi said: Honestly, it's hard to say. Shadowmage is making incredible progress creating a simulation of a wheel (far better than the garbage Unity is currently shipping with), but there's a fair amount of testing and finessing to be done before putting it out into the wild. Progress has been rapid, so at this stage I think we're talking more weeks rather than months kind of timescale. Hehe. Sorry, Temeter, couldn't resist Yep; more than a few days, less than a few months... somewhere in that range Certainly still work to be done, even at the lowest-levels of the code, but it is progressing. Sorry there is not a more definite time-frame... but I can't say how long it'll take to solve problems that I don't already know the solution for, nor do I even know how many more 'problems' need to be solved (often solving one exposes others...). Sometimes it may take a few minutes to find a solution, sometimes it takes days (or more) to figure it out. For example; the current 'problem' I'm working on solving, is accurately calculating the mass supported by each wheel (for an arbitrary number of wheels, and arbitrary COM layout)(solving for a normal 4-wheeled vehicle is simple..). I have (currently) no idea how to solve this problem, so the first step of course is research and... more research (i.e. lots of reading, learning, and inevitable headaches ). Eventually I'll find a solution that I understand, an already-existing implementation that I can work from, or even some other work-around to the problem entirely; how long that will take is completely unknown. Link to comment Share on other sites More sharing options...
Recommended Posts