The differences are pretty big, but the simplest way to illustrate is to try to use gazebo, isaac...etc, and then try to build a whole physically interactive kitchen.
First off, it's gonna take you 3 months to author that thing, if you don't ragequit along the way.
Then, when you go to run, your "50 million steps per second" sim becomes 500 steps per second.
The reason we have robots doing backflips and acrobatics instead of actually useful stuff like picking up your house is making the scenes and getting the data is tough. It requires sensors like cameras and rendering, vs purely proprioceptive-only envs with a flat ground plane and no other physics interactions.
Right now, the industry is doing manual teleop to collect data because it's straight up easier than trying to build these sorts of things in simulators.
This is why we're building Lucky.
I guess the better question is how much does photo-realism quality matter for this kind of sim2real work? A lot I would wager.
I guess Isaac Sim is king?
UE is definitely used to obtain simulation data in other domains (this is coming from first hand experience in big tech), but usually through scripting UE handmade levels in python which also needed convoluted server systems at the time (hopefully this has gotten better now).
Hasn’t the Bullet physics engine been used for robotics for over a decade?
I don’t understand this “first game engine for robotics” messaging.
As an aside, this website crashes for me on safari on iOS.
Idk if that's true or not, but it does exclude all the engines you mentioned.
I’m going to try it to see if I can make my Go-1 edu do some work around the house finally