Just added a check to the source that sets the transform position to 0,0,0 if it isn’t already and warns the user. Thanks for working out the issue and letting me know.
Imagine you have a mesh of say, a sphere, and you delete the vertices from around the equator. Now you have two hemispheres, but still only one mesh, with a gap in it. Meshes don’t have to be contiguous.
The only problem is occlusion culling - the skidmarks always draw, everywhere on the map, since they’ll all really one object.
I assume this does not work with HDRP?
I haven’t tested, but I don’t know any particular reason why it wouldn’t.
Works fine in HDRP. It’s just code. You will need to create a shader in Shader Graph though.
@Nition Thanks for this
In my case I had to have multiple skid mark controllers for this to work - one for each wheel (as I’m not using wheel colliders)
I found with the script as it was with one controller it failed to draw the skid mark meshes for all wheels, hence I had to separate.
Hope this helps someone.
Don’t want to cause a fuss or whatever but this looks like it was almost exactly copy and pasted into Realist Car Controllers skidmark system.
Not sure when he changed his but I’ve been going through that asset to fix it and saw that the Skidmarks script is not like his usual coding (this is a little more math/manual transform intensive and has comments…)- A quick lookup of Unity Skidmarks led me here and I figured I’d tell you that someone else put their “copyright” on what looks almost exactly the same as your work.
Thanks for the heads up. I released it under the BSD 2-Clause “Simplified” License which is very permissive, so they are allowed to use it in a commercial package.
They should have included the following licence text somewhere though, to cover the skidmarks source code: UnitySkidmarks/LICENCE at master · Nition/UnitySkidmarks · GitHub
If they haven’t done that and are just acting like they wrote it then they are breaking the rules.
Going through and reading it, there are slight differences but it’s almost the same - maybe it’s an earlier version of yours.
They don’t have the license text on it.
Thanks for the heads up, I’ll send them a message.
Just to update you @FeedMyKids1 ; I decided to buy the asset myself to check it out. I see what’s happened. We’ve both based our code originally on the skidmarks code that came with the old Unity 3 Car Tutorial. The similarities are just the parts that remained the same in mine from the old car tutorial version. So they’re fine - they’re not copying mine.
Having said that, if you’re using Realistic Car Controller I’d actually recommend swapping their skidmarks code out for mine, which should be pretty straightforward as they’re similar in how they work. Reason being that the old car tutorial code that Realistic Car Controller is using regenerates the entire skidmarks mesh from scratch every frame, which causes massive garbage collection spikes. Mine generates zero garbage so it’s a lot easier on the CPU.
Just picked this up - a great time-saver!
If you don’t mind me saying, it would have saved even more time but for an issue I had to find and fix:
The fudge in the main skidmarks script to discard connected marks over a certain length had me scratching my head for ages as to why the skidmarks just stopped working above about 40mph. The correct fix, in my opinion, is to put ‘lastSkid’ values returned to WheelSkid scripts into a ‘do not re-use’ list until they are a) passed back in as ‘lastSkid’ values when generating a new skidmark, or b) explicitly abandoned by the WheelSkid when setting ‘lastSkid’ to -1.
(EDITED: My bad - the other issue wasn’t strictly a bug. Unity’s wheel collider ignores transform orientation and instead works entirely off parent rigid body orientation. Depending on how your artist builds his wheels, you might end up with wheel transforms that don’t tally up with the wheelskid script’s assumptions about local X.
Yeah @Peeling that hack to fix the looping-around bug is the worst part of the skidmarks system I think. I only discovered the bug that it solves relatively recently and didn’t have a lot of time of my hands so it got a less polished solution. To be clear I mean this part:
// Fixes an awkward bug:
// - Car draws skidmark, e.g. index 50 with last index 40.
// - Skidmark markIndex loops around, and other car overwrites index 50
// - Car draws skidmark, e.g. index 45. Last index was 40, but now 40 is different, changed by someone else.
// This makes sure we ignore the last index if the distance looks wrong
if (distAndDirection.sqrMagnitude > MIN_SQR_DISTANCE * 10) {
lastIndex = -1;
lastSection = null;
}
Unfortunately I don’t really have the time to implement and test a better solution at the moment. If someone were to submit a pull request…
Thanks for the update.
The reason the Skidmarks class stuck out to me in his project was because it was so dissimilar to how he writes (There were comments and it’s a bit more organized in the Unity-based code).
I read through most of that project (RCC) - or at least 3000 lines of it - and I get a bit of PTSD thinking about going in to change anything else (I spent about 60 hours on it trying to both make it more efficient and more modular).
The thing is, RCC has the type of driving that I wanted - sort of a GTA V style. So I can’t really flame the guy further than I have.
I wonder if Edy’s Car Physics is any better.
I would like to use this system with sphere collider, can I just swap out every reference with wheel collider to sphere collider?
Yep, that should be fine. Since your collider won’t have the helpful GetGroundHit method that WheelColliders have though, you will need to do your own calculation of whether your collider is hitting the ground, and what the normal (the “up” direction) to the ground is at that point.
I feel like this applies to nearly every large code asset on the Asset Store. 
[quote=“Nition, post:36, topic: 664219, username:Nition”]
Yep, that should be fine. Since your collider won’t have the helpful GetGroundHit method that WheelColliders have though, you will need to do your own calculation of whether your collider is hitting the ground, and what the normal (the “up” direction) to the ground is at that point.
[/quote]
If its not too much trouble would you be able to add this option ? I’m not a coder but I love to use your system.
The asset I’m using for the sphere collider has a funtion for ground check, I dont think it had one for ground normal up direction, any tips on how that is called in unity?
My end goal is to have a texture for the skidmarks that represent a real tire mark, and has parts where the track is masked off.
You’d want to raycast from inside your spheres straight down, something like this:
RaycastHit hit;
// You'd have this raycast distance be just enough that the ray
// ends just below your sphere, so that if the raycast hits, you
// can consider it to be on the ground
float maxDist= 2.0f
if (Physics.Raycast(spherePos, -Vector3.up, out hit, maxDist)) {
// Sphere is on the ground if we get here
// You can use hit.normal to get the normal of the hit surface
}
Ive tried to remake your work, fitting to my physics model, which works with just 1 sphere for an arcade mode.
So, i had to change some lines to make it work, but it doesnt work correctly.
The Skidmark will not appear to the right time, and to the right place.
For test purposes i have leveraged a few things, lets come to the important lines:
// Skid if we should
if (skidTotal >= SKID_FX_SPEED) {
float intensity = Mathf.Clamp01(skidTotal / MAX_SKID_INTENSITY);
// Account for further movement since the last FixedUpdate
Vector3 skidPoint = wheelHitInfo.point + (rb.velocity * (Time.time - lastFixedUpdateTime));
lastSkid = skidmarksController.AddSkidMark(skidPoint, wheelHitInfo.normal, Color.green, lastSkid);
}
else {
lastSkid = -1;
}
I´ve changed this to my 2 wheels (because i do not have real wheels, just a sphere in the middle) with skidmark-pointers for the transform.
So i changed to this:
Vector3 skidPoint0 = carController.skidMarks[0].transform.position + (carController.rbody.velocity * (Time.time - lastFixedUpdateTime));
lastSkid = skidmarksController.AddSkidMark(skidPoint0, carController.skidMarks[0].transform.position, Color.black, lastSkid);
But the skidmark is:
a) to late, behaviour is not fitting to my drifting, it comes everytime much too late
b) the positioning of the skidmarks are misplaced…
So i dont really get the point about “rbody.velocity * (time.time - lastfixedupdatime) …” - i think this is the problem