Nothing good in life is for free

Some people just spend to many time complaning, and to few looking for solution.

I would say, this look like your average CryDev user.

Not entirely true, have a look at Flex, you’ll see it caters to much more than just fluid dynamics - it also handles soft bodies, cloth, rigid bodies, destructibles. The core idea of Flex is that everything is a system of particles connected by constraints. But that does not mean everything is a fluid. Even solid objects are constructed of particles in Flex and are used to simulate rigid bodies, soft bodies, cloth and fluid all within the same solver.

There seems to be a lot of misconception to how much work the PhysX engine actually does behind the scenes in Unreal. It’s not just the vehicle simulations or whatever, it handles ALL of the collision code for the entire game whether an object is simulating physics (use that term loosely) or not, it calls back into the line/ray tracing code, it handles the destruction etc.

A lot of the other physics engines being posted are much more specific. Bullet is fairly feature complete, but I wouldn’t say it’s fast nor easy to use.

My only potential complaint, is that Complex Collision in UE4 is pretty slow. A couple of hundred skeletal meshes that are simulating physics and have complex collision bring my framerate down to around 30 in an empty level. I believe there’s room for improvements on that part.

Second that! This is my major complaint. When you look at the task manager to see how many cores are used, you will see there are quite a few unused.
Collision detection is also not the most robust, at least as compared to Havok (CCD and all included). When things start to move fast, physics bodies will penetrate each other and things gets messy.

But Caaaarl… Bullet does not need a sales person cause it is free) So the problem is elsewhere.

Well, PhysX 3.4 is promised to have “significant changes and significant speedups”

PhysX also supports CCD, maybe not as good as Havok though.

Also, I like how gently Havok resolves initial inter-penetrations of rigid bodies and stuff like that (like dynamic RB being squeezed between kinematic RBs), would be nice to see it it PhysX too.

UE4 is not free, like open-source free projects, where developers dont even have money for buying bread for breakfast. UE4 has some different situation, you have to pay 5% royalty to Epics, or you have to buy UE4 for 1.000.000$+ if you dont want to pay 5% royalty. It is free only if you are making trash game, and upload it for free for everyone. Free to play basis games are not free, you have to pay to Epics 5% of all ingame market buys.

So, UE4 developers are not working for free, they are working for money. So UE4 can not be bad, just because its called Free, because its not Free. I would call UE4 - “free for develop” model, where you do not have to pay for UE4 while developing, but you have to pay when you’re selling your product.

But, if we are talking about PhysX, then yes, you’re right, its completely free, and cannot be compared to Havok etc, because Havok is not free and thus better than PhysX.

UPD:
Also i want to add, that proprietary engines of big titles can be better than UE4 indeed, because that engines are made closely to specific titled games. When you’re making not only engine for engine, but when you’re making game primary and engine secondary, then engine becomes good indeed. Unfortunatly UE4 mostly is engine for engine, ofc i know about UnrealTournament, but thats not enaugh, for example Battlefield is much more complex and scaled than UT, so, Frostbyte is also more complicated and featured. Assasin’s Creed also is more scaled than UT, thus it’s engine is also more featured and probably less bugged, because when you’re releasing own game, you dont want to have much bugs, so you’re making everything to reduce bugs in engine of that game.

The point is, yes, i agree, that Epic should have their own big title, but historically they are moslty positioned as developers of engine for engine. But dont forget, that UE4 is the only free to develop AAA engine with opened source code.

By the way Crytek and their Crysis, is not so big title, like Battlefield or Assasin’s Creed, or GTA. Crysis is also more or less simple 3d Shooter.

Nope, PhysX is not completely free - all stand-alone console versions (X360, XOne, PS4, PS3, Wii, WiiU) + iOS version require paid licensees, and there also an option for paid support (ticket based).

Ok, even better, then PhysX is not so bad.

Unreal Engine 4 is a suite of integrated tools to build games, simulations, and visualizations.


Custom Logo Design India

This is exactly one of the weaknesses of PhysX: the inter-penetration of bodies in PhysX, i.e. how two bodies suddenly overlap because the algorithms loose it. This forbids to use PhysX for anything more than ‘gimmick-physics’. Anything where physics is of more important nature for the game, Havok is used.
Just yesterday I had the situation, where 9 of 10 trials work, and then there is one trials where interpenetration is messed up, two bodies overlap and as a consequence, stuff gets messed up and all rigid bodies explode off in all directions. An unreliable behaviour like this is not good.
Collission robustness like this is nothing that you change withing a day, but it requires serious work. This has to come with the engine - or not.

you hit the nail on the head there.
for a long time i have suspected this to be a major factor in the vehicle bugs, its as if the physics is out of sync with the rest of the engine or something.
i dont know enough about how it works under the hood though.
guess ill have to bite the bullet and download the nvidia branch and start hacking away again, someone has to do something. might as well try to help pinpoint the problem area(s).

even if cryengine would provide free version without any payment, i still would be use UE4 and pay 5% to Epic because of source and this gives feeling that i am not prisoner of company.

If you repeat at many times, it won’t become true) Look what TheJamsh said about how PhysX is used - “all of the collision code for the entire game”.

Havok sim can freak out as well, but it deals with consequences more gently, I’ll give you that.
Havok bugs examples - http://www.youtube.com/watch?v=h4NdPepMemE (Skyrim), http://www.youtube.com/watch?v=IK4jaNwu_4g (WatchDogs), http://www.youtube.com/watch?v=AVJbdL83UmU (Battlefield), etc

Thats more like it)
And don’t forget to share your effort with the community, so with combined effort physics in UE4 can be further improved)

Believe me, you do not just download the PhysX branch and change the collision behaviour, unless you are a really experienced coder with experience in that area.
Implementing collision ‘freak out’ algorithms, i.e. error handling the collision in PhysX is far form trivial. I work in a similar area, and have seen professional people trying. But you can always downlaod and try yourself…

Sure, PhysX handles all collisions, line traces and so on, that is clear.

As with regard to your examples: did you notice that most ‘big’ games use Havok? Guess why! Or guess how the games would behave with PhysX!

of course not but every coder knows how to debug. simply following the code flow and logging certain values will help zone in on the problems. then the people who actually wrote the code can take it further and hopefully fix it. or someone might just get lucky and see exactly whats wrong. monkeys with typewriters and all that…

The misunderstanding here lies in the actually difficulty/cleverness required to create good collision error handling algorithms.
I agree, everyone can track down the variable or whatever that goes crazy in case of a ‘collision freak out’, but then how to handle it? What algorithm to write/apply to not have it freak out? This is where advanced coding/maths kick in.
If this was any easy task that could be done by a single hand, nVidia would have implemented it already. This is the core reason why Havok swims on top. (next to speed, memory and multithreading)

http://www.havok.com/products/physics

Everything written here, especially for collision -> True!

oh if only they had gone with havok but they didnt, and although havoks game engine is ok its kinda old school now so its not that inspiring to use.
if unity had gone with another physics engine i would happily use that and forget about ue4.
at least here we have the ear of the physx developers. even if i do use unity in the end (more than likely tbh) physx needs some serious fixing.

Haha, that is an unbeatable argument to finish a technical discusssion about an engine that has been used in most in the most recent games.

I wish UE4 would include Havok. -> robust collision detection, multi-threading, low memory footprint and fast.
‘How it handles’ becomes just more and more important in games…

havoks engine is ace dont get me wrong. but it feels a bit like going from windows 8 back to using dos lol. just my experience of it.

so in very untechnical terms logic would point to the physics being worked out after the engine has moved an object, rather than before.
ue4 says this object moved this far
physx then says that object is inside another, ahhhhh spak attack

where as it should be doing,
physx says this object moves this far, but there is another object in the way so stop it there and get ready to handle that
ue4 says ok move this object up to the collision point

on the other hand it could just be a wayward variable that needs clamping or something

Havok Physics it’s not free, isn’t an option to integrate with UE4. (But can be added like Speedtree or other solutions)

You have examples of different physics engines in different well know games:

  • Bullet Physics:
    Grand Theft Auto V - IV

  • Havok Physics:
    Orcs Must Die 1 - 2
    Far Cry 3 - 4

  • PhysX
    Borderlands series
    Metro
    The 90% of Unreal Engine based games

And others with custom ones:
BeamNG
Crysis

Each physics engine have different pros & cons.