[RELEASED] uPhysics & uPhysicsPro

Hello there, we will have uPhysics promoted on the 24Hour deals soon. We'll try to get it released until than!

 

Hi, what is the difference between the pro and non pro versions?

 

Hello, what's the status of the update?

If the final version of the update is not available, is it possible to receive an alpha or beta version of the update?

 

No worries, it wont take much longer. If you wish so, I can aswell message you as soon as I upload v2.2. You'd be able to catch it directly from the shared dropbox repository. (If you've received your access already via our Support)

 

Thanks, good news, I'll e-mail you with my invoice one the update is available.

 

When is the 24 Hr deal?

 

This month. Aint it more fun if I dont tell you the exact date?

 

I dropped you a mail with some questions. thanks!

 

Interested in uPhysics? Check out the 24 hour deal! Off by 50% only for a limited time!

(I've always wanted to say such a thing hehe)

 

Hi @Sharp Development, does it have a demo version? Is possible to create a Crane with your physics joints without having problem with the joints (for heavy cargos)?

 

Hallo there,

The roadmap and plan was to have uPhysics v2.2 ready by the 24 hour deal. However, there has been lots of stuff and new requests over the last couple of weeks, including unity 5, therefore we couldn't really stick to our targeted release date.

Why I tell you this?
Well, webplayer demos and demo content are subject to v2.2 so I unfortunately have to tell you that at the current time there simply is no demo for the active version.
Furthermore, uPhysics currently only implements constraints, not joints itself, which are aswell content of v2.2.
Last but not least, in the upcoming release cycles of uPhysics there will be a seperated rope editor which not only works for this physics engine but aswell for unity.

Even tho this answer is kind of vargue and not really satisfying as of now, I still hope you keep your interest.

You might aswell be interested in the upcoming feature set described on the initial post of this thread.

 

Couple of questions.

How tightly is this coupled to Unity? How much work would be involved to run it under a newer version of .net outside unity?

If that's possible, can the existing concurrency be disabled?

I'm the author of game machine (https://github.com/gamemachine/gamemachine), which targets large scale virtual worlds and a physics engine that works well with lots of physics objects is very interesting. But It would have to run server side under a newer version of .net, and be adapted to use the task parallel library, which is easy enough for me to do assuming that uphysics is thread safe. But I would need to disable whatever concurrency model is currently being used.

 

Ha! Good question!

The current version is still tightly coupled to unity. However, with v2.2 I've been abstracting the system to a degree that its fully functional outside of unity. Conditional compilation does the trick I guess. To summerize, I've been doing this due to the same idea, I want uPhysics to be useable as standalone plugin which aswell includes support for newer .net versions.

However, I've not yet did the conditional port to .net 4.5 which would have the framework run on tasks and async patterns. Tho, im still not absolutely sure about this either since the actual currently implemented threading in uPhysics is highly optimized for the system, something which would ultimately make tasks a bad choice due to them implying a greater overhead. On the other hand idle times, waiting for the current workset to finish could be reduced due to async.

Now to answer your questions. Those answers resolve around v2.2, not the current version.
- It'll be compilable for standalone and newer net versions.
- Threading can be disabled to a certain degree. Every threaded system has a singlethreaded counterpart. Implementing tasks (if I dont do that for v2.2 myself already) aint much of a work.

As a reminder, I like your project, but implementing uPhysics wouldnt be possible due to it being open source. Tho, you can still message me. I guess we can come up with something great.

 

I checked out the links for both uPhysics and uPhysics Pro above and couldn't tell what the difference is, besides the name and the price. Can you explain what the differences are please?

Looks like a great system, btw!

 

Thanks for the response!

As far as the open source bit, I'm actually working on some modular additions that make use of commercial stuff from the asset store. It will be up to the end user to purchase and install the commercial dependencies. Anyone making a game at the scale that would benefit greatly from uphysics, isn't going to have a problem purchasing it.

 

Hello there,

Previously uPhysics was a compiled version and uPhysicsPro shipped with the full source. We decided against this approach so now both packages ship with the absolutely same content, means full source. The other difference is, one package is on sale while the other isnt.

Thats acctually a great idea! I really like it, we should stay in touch!

 

Thank you, I guess you already said that as well, I just didn't put the two together.

So my next question is I am using a voxel terrain creation tool, Ultimate Terrains, do you think the uPhysics engine would work well with it, maybe speed up terrain generation a bit? Or am I looking at a logistical nightmare trying to get the two to work together well?

I guess as a follow up question I'd ask who would you say the target audience is for uPhysics?

 

Short answer, yes it COULD work with Ultimate Terrains. However, to give a more accurate answer I'd need a bit more of information as of how the system works. Are the voxels accessible as actual meshes? Is the terrain only accessible as a huge mesh? How do you access the data of the tool and what data do you access?

Those are critical questions. I guess you currently generate a physical behaviour by assigning a mesh collider to some kind of data which gets generated by the tool. In that case it wouldnt be a problem to just exchange that mesh collider with the one of uPhysics. Tho, this requires an actual TriMesh collider which is once again content of v2.2. Unfortunately. I guess I have to write this way to often...

As of terrain generation, uPhysics might only speed up the collider generation of the terrain, not the actual terrain generation itself.
Additionally, with uPhysics you have always the chance to implement a special collider ontop of an existing one. The source is included so you can optimize for your corner cases as much as you wish.

Audience? Previously uPhysics was targeted towards servers, especially MMO ones or RPG games in general. Tho, this changed alot. By now uPhysics audience is everyone who wants to have a custom physics solution for a 3D game.

 

So Unity5 has been around for a while, are there any new benchmarks (Unity5 Physics vs uPhysics)?

 

Hi, Sharp Development this asset sounds very interesting and promising let alone it is version 2.11 so we can expect some mature and tested product. BUT! No website, no documentation, publisher website link leading to major german web portal? Just a support e-mail and thats it? Did you think this is proper presentation of a product which require deep customer commitment?
You product may be incredible but how the people will know that? What I can expect for support when you dont even have time to make a proper presentation and documentation of you product functionality?

 

I think this package was mostly applicable in Unity 4, seeing as how Unity 5 has major improvements on the PhysX front.

 

Hello there, we've been heavily optimizing for unity 5 due to new possibilities via the profiler. We aswell already did several benchmarks showing nice results. Expect to see them coming along with the webplayer demo of version 2.2!

Good point, nothing to say against it since every single word is true. Expect to see this being changed in the near future. We are working hard on getting uPhysics to a point where it receives the meta it deserves.
All I can say is that im sorry about the current state.

Hello there, this is just partly true. Infact uPhysics still offers performance increases in unity 5. Especially due to load balancing which is (with uPhysics v2.2 and unity5) aswell applicable to unity components.
We are heavily integrating new systems for both engines, PhysX and uPhysics so this product serves aswell as a physics toolbag. Not to mention that PhysX 3.3 brings alot of bugs and unwanted behaviour to unity, aka wheel collider and broken joints. After all this product includes the full source, means you can just go on and integrate whatever you need without relying on PhysX to eventually get fixed. Not to mention that uPhysics runs at least equally fast as PhysX, in close to all cases faster by an order of magnitude.
Last but not least, with uPhysics you dont rely on unity at all. A costy factor which makes most mass scale integrations costy is moving a gameobjects transform. uPhysics gives the possibility to decouple your code from unitys components, making them run in a virtual fashion. This especially speeds up server simulations and similar systems which dont require a direct representation for the user.


Cheers and thanks for the feedback guys!

 

Within the realm of applications that do need physics at some scale, there is actually a need for something like uphysics that's written in a higher level language then C++ and designed more for simulations. I've been trying to find a 'good' solution for server side physics for large virtual worlds for a couple of years now, and there are none that are reasonably priced for the indie market. C++ doesn't work well for this problem area because it's extremely difficult for the end user to modify and fit into existing architectures and concurrency models. And server side raw language performance isn't really a bottleneck like it is on the client. Object creation/garbage collection is an issue with managed runtimes, but it's solvable and I'd rather solve that problem then have to deal with the issues that come with C++.

 

Exactly this.

Furthermore, most physics engines written with C++ will aswell not work out for a mainly managed simulation/server since by design it'll push you into massive interop. Let alone if you would write a wrapper for bullet or alike, the massive P/Invoke costs would be noticeable since every single bit of data is effectively stored on the native site. Would you want to do 10000 P/Invokes just to fetch positions of objects on the managed site? Doesnt sound like a good idea. Thats effectively the exact issue unity has with its transform hierarchy. You simply cannot move thousands of objects in unity with a reasonable FPS. Further systems, like uPhysics LoadBalancer or a fully virtualized simulation decoupled from unity need to be brought in place here.

To mention this, there are several open source physics solutions written in C#. Tho, they are either damn slow or just lacking functionality and/or stability. uPhysics tries to solve this lack and hopefully v2.2 will deliver/solve it even more.

Last but not least, every standalone framework written in a managed environment should aswell implement means of garbage reduction like allocators and caches. Otherwise the whole point of having such a framework written in a managed language falls apart. GC aint cheap, meh.

 

Properly written native physics plugin wouldn't incur 10K P/Invokes per frame since you will batch all position updates in one raw P/Invoke call. However uPhysics still shields the hit from 10K Unity transform components updates per frame, which is great. I'm wondering how the multi-threaded PhysX 3.3 in Unity 5 deals with the transform components update. Since both PhysX and Unity transform components are implemented at the C++ side in theory they could short-circuit the transform updates and not go through the managed / C# side at all. If they do that, they "should" outperform uPhysics in the test case of 10K rigid bodies free-fall into a pile that need no transform updates from the C# side, right ?

For anything that need massive game objects transform updates or transform query or spatial query from the C# side, no doubt that uPhysics will be a great boost to the performance.

Is it easy to configure uPhysics to function in a "transform cache" mode ? By that I mean only the load balancer, multi-threaded transform deferred updater and probably the spatial query and narrow phase trigger/collision events are used. Another way to ask the question is can we easily disable the "dynamics simulation" of uPhysics and use the rest function with other dynamic engines ?

A.P.

 

Another question: does the load balancer have sensors for the current CPU loads on multi-cores and balance more loads to the idle CPU cores ? Or, is there a way to simply "force" most uPhysics task to non-main thread since we know the main thread is very likely slammed under heavy stress ? Maybe if Unity does a good job in low-level task scheduling the above is unnecessary assuming uPhysic utilizes Unity's existing task system to schedule multi-threaded work ? Thanks!

 

Hello , i want to have 1200 moving objects at the same time that collide , the gameobjects have a script that just changes their velocity,
I am getting 100-150 fps could this asset improve the fps of my cpu ?
This app is meant to be used on a single core device.
(This is a test for an online application so please answer me)

 

The reason behind the 10k P/Invokes wasnt about the fact of batching being usefull but more about common c++ physics libraries not being layed out for a proper C# wrapper. There are of course certain optimizations which could reduce P/Invoke pressure, however, they are most of the time not present directly.
Just take unity as an example. Every property call which fetches some kind of data is forwarded to native code. This can bite your back in a heavy scenario.

Coming to PhysX short-circuiting updates. Yea, it most probably does. The question in place is how it does it. uPhysics calculates the whole transformation matrix for changed objects on another thread and just updates the local position on the mainthread. PhysX most probably uses the unity implementation which does the whole calculations on the mainthread. Thats one factor.
Another factor is that transforms can be load balanced over several frames, which reduces pressure alot.

Considering 10k transforms falling into a pile, it really depends on the things mentioned above but the tests I run so far still showed better performance for uPhysics while using a load balancer. I've not yet came to test the non load balanced case.

The LoadBalancer and uPTransforms are completely decoupled from the rest of the system. That component acctually has nothing to do with physics itself so yea, you can use it as standalone system for anything you want.
As of shutting down the solver, so the dynamic part, is kinda hard to answer. In v2.2 this is definitely fully possible.
In the current version its kinda hard since under the hood, normal colliders use constraints to solve their interpenetration on collision. This requires the solver.
Triggers, however, can simply be used in a standalone fashion since all they require is the broadphase and an overlap test in the narrowphase without having to solve anything.
In the end, you have the full source included so there is always the option to change the system to whatever you like.

uPhysics by default offloads every single bit of work to other CPU's/Threads exactly because the mainthread shouldnt be stressed. Tho, this is only true for code which doesnt rely on unity directly which is like 99% of the system.
The load balancer shifts the work to other threads aswell. An actual sensor which CPU is currently in idle mode is not needed, the CLR and OS schedule threads themself and care for CPU's not being in idle mode while there are multiple threads doing work. In short, the CLR/OS handle thread scheduling, so every available CPU resource is used.

 

uPhysics is designed to be run in a multithreaded fashion. With just one core its kinda hard for uPhysics to utilize this. Yet, the actual LoadBalancer of the system will definitely improve your FPS.

So in short, on a singlecore CPU its hard to get a better performance. You will most probably only experience a speedup while using a loadbalancer.

 

Thank you for the insight on those factors, I'll keep a close eye on your package as it develops,
as my team is in pre-production right now and we can't jump the gun yet on what we'll go for as our physics platform.

 

Quick(-ish) questions:

I have pondered to swap the Trainwreck that is PhysX with uPhysics for some time now, but the last time I asked important features were missing.

Now, with Unity 5 and the newer PhysX version, PhysX turned from bad to unusable, because the PhysX developers in their unending wisdom decided to disallow non-convex mesh colliders on non-kinematic rigidbodies... which means Unity fires tons of errors in my direction because of my setup.

My damage system uses a bunch of non-convex mesh colliders to emulate the armour sections of a vehicle. As armour should be a thin layer, and should match the vehicles visual form as closely as possible, I use non-convex mesh triggers for that (because non-trigger colliders messed up physics until now).
There really is no simple solution to make such a system work with the current PhysX version in Unity 5, save from having a shadow object that is not in the same hierarchy as the vehicle so the rigidbody will not interfere, and then set the shadow objects position and rotation from script every frame. Would work, but is so ugly I rather not do that.


Thus my questions:
a) can I use uPhysics alongside of PhysX? I eventually plan to abandon PhysX for good, but I am not sure if I really want to do that in one big migration. Would be good if I could just rip out and replace what isn't working and do the rest later.
b) does uPhysics support such a setup? non-convex mesh colliders on a non-kinematic rigidbody I mean? Is it also possible to make sure the collider is only used for raycasting?


Thanks for any help

Gian-Reto

 

What is the StarMath.dll in uPhysics package ? Is it a native DLL or a C# compilation ?

 

Your problem is unfortunately still content of uPhysics 2.2. However, we are finally in a state where we will not let you guys wait any longer.

a) You can use uPhysics along PhysX. However, there is no direct collision between the two systems. I've been seperately implementing a unity emulator component which basically creates a uPhysics collider depending on the unity colliders present on an object. However, since PhysX is nearly unaccessble, its kinda hard to archive a direct interaction.
b) Yes its fully possible to have TriMesh colliders on kinematic rigidbodies. You can let them collide with everything. Furthermore, TriMesh-TriMesh collision is something PhysX doesnt allow/implement, uPhysics does. You can set them to triggers, of course. As of it only being used for raycasting, thats simple aswell. uPhysics basically works with the unity collision matrix, with which you can aswell filter that an object will never collide with anything else and only raycasts can hit it.

Hope this helps you with your problem, let me know if there is anything more you'd like to know.

The StarMath.dll is a managed C# dll implementing some double precision math stuff used for the convex hull algorithm. Its not native.

 

Sounds great... I just didn't got the meaning of the first sentence... so what you describe below does or doesn't work with uPhysics 2.2? Is uPhysics 2.2 not out yet?

No problem about the interaction between PhysX and uPhysics... I was pondering if I should leave the physical collision and movement physics in physX and just move the damage system to uPhysics... the damage system is completly seperate from the normal physics even now as I use much more detailed colliders for that, and raycasts that should only collide with the damage system.

1) Of course that would mean having both a PhysX and a uPhysics collider on some objects... is that a problem?
2) Are there uPhysics colliders for terrain yet?
3) last question concerning the trimeshes, I need to get the normal at the collision point, which waspossible in PhysX. Does your trimesh colliders also offer this option?


Regards

Gian-Reto

 

Hallo there,

Im sorry, I aswell noticed I missed a word in the response of this morning. The answers I've been giving were meant for version 2.2 so they are not yet implemented. This means TriMesh colliders and raycasting.

Now coming to your new questions:
1) Having a PhysX and uPhysics collider on an object aint a problem. Thats technically how uPhysics does the "interaction" with PhysX aswell.
2) Version 2.2
3) Sure thing. In uPhysics you get a quiet similar collision response like you know it from PhysX, this of course includes the normal and contact point.

 

Hello ,I bought uPhysics last week but I still don't know how to use it.
Please give me a sample thank you!.

 

Hello there, I've answered your mail!

 

So after tinkering around with the PhysX 3.3 Wheel Collider I have to say: F. U. Nvidia (yes, like Linus Torvalds some years back)!
They managed to make something bad worse! (I realize that the PhysX 2.8 Wheel colliders were so unusable that Unity went and fixed them, so yes, its partly Unitys fault for not realizing that the PhysX 3.3 Wheel colliders are still unusable).

So many more parameters exposed, yet its even more impossible to get any correct behaviour from them.

Thus my question: Wheel colliders are in you roadmap... will they be ready in 2.2? Can you give a rough ETA for 2.2?
Also, how will the Wheel Colliders be implemented? What parameters are exposed, what do they do?
And will you be able to update the Manual for 2.2?


If you ask why the PhysX Wheel colliders are unusable to me (might be interesting for you), it is mainly 1 thing: the suspension behaviour is weird, and for some reason, no matter how you set the parameters, they have no influence on that:
The suspension behaves like there is little air / oil left in it. As soon as the vehicle is stopped at a slope for example, the suspension that has to carry more weight now is sinking down to the lowest possible position. While driving, that results in a very wiggly behaviour, which also looks off.
That, to me, is not like a normal suspension should behave, at least not until you release most of the air or oil from it.


I had to add additional hacks/fixes in my code to make the PhysX 2.8 Wheel colliders behave more realistic ... I have no problem to continue using hacks, but these hacks should work with your physic engine:
- sliding in corners instead of toppling over (transfering force from one suspension to the other to simulate rollbars, decreasing the stiffness to make the wheels slide)
- Correct behaviour on slopes to prevent the vehicle from continuing driving up steep slopes (increasing air resistance and decreasing stiffness)
- Correct Behaviour on different ground materials (to prevent the ground from feeling like bouncy concrete when it should be sand, I apply a configurable counter force at the point of the wheel collider to counter bouncing of the vehicle).


If you can provide wheel colliders with better behaviour by your 2.2 release, and that release is not too far off, I will happily abandon PhysX 3.3 earlier than planned!


Regards

Gian-Reto

 

I feel your pain. I generally prefer not to use a black box "wheel collider" offered by physics engines to make my vehicle games because underlying what they did was a bunch of ray cast to "fake" the math models of a simplified suspension. With my own APE physics engine I built vehicle suspensions using primitive hinge/prismatic joints plus motors myself. This way you can draw inspiration from true mechanical engineering of real world car steering/suspension and build whatever vehicles you want. You do need a solid joint engine to do that and PhysX's "soft" joint doesn't hold things together for complex mechanisms. I had a very primitive demo video of a "monster truck" built that way in the APE thread:

http://forum.unity3d.com/threads/ap...for-robust-joints-and-powerful-motors.259889/

 

I'm confused now. is uPhysics using APE? Or are two independent physics engines? If so, why? I mean, why to develop and distribute two different engines? Which one to choose then?

 

Sorry for the confusion. uPhysics and APE are two independent projects developed by different people with different focus. uPhysics offers great optimization for C# side acceleration for massive transform updates and broad/narrow phase collision/spatial query with an optional full dynamics simulation within C#/managed side. APE is a native C++ physics engine optimized for robust joint and strong motors and it specifically addresses PhysX "soft joint" problem. I probably shouldn't post APE information in this uPhysics thread which caused the confusion.

 

Thank you. That clarify it.
I really wish you could continue to develop fast uPhysics and implement also a proper wheel collider. Consider also the option to have a circular collision of the whole wheel and not just a vertical ray casting that behaves very bad on off road simulation.

 

I appreciate the heads up, articulatedPhysics... Your APE Project certainly looks promising, but as far as I can tell its not available yet. Also, I would say discussion is somewhat OT in this thread as its a different product.

Any answer on my question from the uPhysics guys? I really need a solution as soon as possible, and I am somewhat relucant to go with solutions like Edys Vehicle physics, which seem to be a wrapper around PhysX (which I would have to wrap again with my hacks to make it behave the way I want)... working from scratch either with physics or a different solution and abandoning the wheel colliders altogether would be a solution, but then that would be an awful amount of work, so if I can avoid that, I will.

 

hello?I still couldn't run it. I reply and attach a small project ,please help me.

 

Hello there!

Just going to summerize this in points:

1) Will WheelColliders be available in v2.2?
- Yes im pushing hard to get them done in v2.2 simply because of them being broken in unity5. To be accurate, they were broken before aswell. So yea, there is a huge demand for it and I definitely want to include it in the upcoming release.

2) What parameters will the WheelCollider expose?
Since we only implemented the basics of the wheel collider so far, I'll not be able to accurately answer this question. I guess I'll be able to give more info on this in short.

3) Unity's WheelCollider behaving weird...
- I've not yet tested the wheel collider in unity5 but it really sounds as if the stiffness of the spring is either setup in a false way or just poorly implemented in PhysX. Wouldnt really wonder if its the latter.

4) When will uPhysics v2.2 be released?
- This is a really good question. You guys should know by now that our time management over here somewhat sucks to speak plain words. However, we are planning to release it by the beginning/mid of June.

5)
a) Sliding in corners instead of toppling over (transfering force from one suspension to the other to simulate rollbars, decreasing the stiffness to make the wheels slide)
- This shouldnt be a problem at all. Rollbars are either way a feature which would be nice to have so there is a good chance uPhysics will ship with it.
b) Correct behaviour on slopes to prevent the vehicle from continuing driving up steep slopes (increasing air resistance and decreasing stiffness)
- This is a problem of friction between tires and ground. With a properly implemented wheel collider and overall system this shouldnt be a problem at all.
c) Correct Behaviour on different ground materials (to prevent the ground from feeling like bouncy concrete when it should be sand, I apply a configurable counter force at the point of the wheel collider to counter bouncing of the vehicle)
- This is something I still have to think about. It'll be nice to have different chunks of a bottom mesh / terrain be able to hold different physics materials in order to give different areas different physical properties. The respective material settings should make it possible for you to simulate every possible ground behaviour.

Last but not least, uPhysics includes the full source, so you can always just continue and change or implement stuff to your likings. So if you'd need a hack, you could tightly integrate it.

Im sure uPhysics will deliver a better WheelCollider. Optionally, Edy is aswell working on a completely new vehicle project which sounds quiet promising. His old one was technically just a fix for unity 4 and lower, his new project includes a standalone solver I guess.

 

Very interesting features

What about the collision detection on the whole wheel surface and not only on a single ray casted point?

 

I wouldnt really call raycasting wheelcolliders to be fake. It doesnt really matter if you use a CylinderCollider, RayCast or Capsule/CylinderCast. They all just deliver a contact point(s) and thats it. Furthermore, building the whole system with joints might be a good idea foir clarification, since what you said holds true, its similar to mechanical engineering. However, properly implemented wheelcollider just wrap the joint math.

What really matters is the solver used. Close to all physics engines use interative constraint solvers which generates gaps and jitter in heavy constraint setups. To counteract this uPhysics will aswell provide several more accurate MLCP solvers and featherstone in order to provide stability where its needed.

Ps: Your APE engine looks fantastic!

 

I could definitely provide several implementations which use a) Cylinder colliders, b) RayCast(s), c) Capsule/CylinderCasts which will all have their respective benefits.

 

That sounds promising... mid June is still some time away, but seems like the wait would be worth it. In this case I will wait for your solution before experimenting more on PhysX... time sitting on the beach would be better spent than trying to use PhysX

To point 5):
I merely was interested if you see any roadblock to using my hacks with your solution... if they are no longer needed, even better! Sounds fantastic.
If you implement different behaviour on ground materials directly in your wheel collider, don't forget us poor souls who are still using unity terrains... solution is quite simple though, its just an array of materials with a small lookup routine.


About Edy's, I am sure he does a fine job. As said, I will have abandon PhysX for the damage system anyway, so to prevent having to run two physics systems in parallel, his solution is just not the right one for me as long as he is using full fat PhysX in the background.
Though his new system using something that simulates the full wheel contact area sounds quite promising.


what mcmorry meant most probably was not to just change the raycast to a shapecast.... he was talking about using a different system than raycasts. So that the full wheel area can make contact, for example when going offroad, your wheel might contact the ground AND a rock in front of it.
Current simple PhysX Wheel collider will ignor the rock, until the raycast hits it. Having the wheel geometry clip into the rock. Then the Wheel collider will have a hard time simulating realistic behaciour when the raycast hits because it might hit at an almost 90° angle.

While in reality, the front of the wheel rounding might hit at a very gentle angle because it is a large wheel, making it a very slight bump if the suspension is soft enough.


While talking about suspension systems with joints: it would be fantastic if your wheel collider could simulate suspensions with more contact points / degrees of freedom.
Current PhysX wheelcollider just simulate a single spring, to make the suspension look more realistic, you have to animate it in a more complex way.
A two / three spring/joint solution will certainly look better, and might also behave more stable (don't know)...

Not something you couldn't work around with procedural animation if using so many physical springs is too complicated or resource hungry though, as long as the wheel collider behaviour is accurate enough.