The online racing simulator
I wonder how difficult this would be to replicate in LFS
Wow, great animation. But I highly doubt it's realtime.
It'll be a hideously complicated physics system that models the entire structure of the car, calculated frame by frame. It's then played back as an animation. I doubt it's real-time.
Definitely not real time, the mere fact the interesting part is only 150 ns long makes it impossible. But that's some deformation engine they've got, really impressive...
Quote from MadCatX :Definitely not real time, the mere fact the interesting part is only 150 ns long makes it impossible. But that's some deformation engine they've got, really impressive...

I think that is 150ms but the font they use and compression aliasing makes it look like an 'n'

That is one impressive animation, and I would hazard a guess it took days on a render farm to produce. The detail is incredible, despite the poor compression artefacts. I wonder if there is a HD version around?
Watching it on a larger screen makes the letter actually look like M. Anyway it's still 10 times more precise than LFS' current physics engine...
#7 - Mysho
I can imagine how much FPS we would get in T1 of some Fern Bay even if that was realtime.
#8 - Nick7
Quote from MadCatX :Watching it on a larger screen makes the letter actually look like M. Anyway it's still 10 times more precise than LFS' current physics engine...

10 times only?
You cannot compare those 2 things.
LFS is realtime driving/racing simulation.

Comparing it to simulation of physics, as this is.. is simply not possible.
This was calculated/rendered in non-real time due to very complex amount of objects, calculations, etc, etc...
I was referring to the LFS engine that runs at 100 Hz precision (minimal dt is 10 ms) whereas the VW simulation apparently runs at 1000 Hz at least. The fact that the VW sim cannot run in realtime because of it's immense complexity is obvious...
There's a whole bunch of these animations, this one does not seem quite as detailed through it appears to be in real time.

http://www.youtube.com/watch?v ... zfatU&feature=related

Appears to be a physics engine here.

possibly CGI
That tree is one hella tree.

I assume it'll be quite difficult? I mean imagine a T1 crash with a full grid... The stress the CPU would have to take be immense. From my POV, atleast when it comes to LFS, it would take years and years and years.
Quote from FPVaaron :There's a whole bunch of these animations, this one does not seem quite as detailed through it appears to be in real time.

http://www.youtube.com/watch?v ... zfatU&feature=related

Appears to be a physics engine here.

possibly CGI

Quote :To make a crash scene the car was then given an initial speed, and some obstacles were placed in its way. After this to scene was simulated, a process which took about 20sec / frame. This video has a frame rate of 30 frames / sec, so that means a 3-4 second long clip took about 40 minutes to simulate. The simulation is done by the computer and you cant influence it while it's being done.

I think it will be a good few years before we get anything as realistic as this in any game. Would be cool as though, and would make people drive more carefully.
Quote from FPVaaron :There's a whole bunch of these animations, this one does not seem quite as detailed through it appears to be in real time.

http://www.youtube.com/watch?v ... zfatU&feature=related

Appears to be a physics engine here.

possibly CGI

Read uploaders text.
Simulation 20s per frame, 3-4s clip = 40mins
Rendering took much longer, 54000 frames took over 40 days.

The first video is much more complex, and even with high performance machines, must have taken a long time.
You forget about burnout paradise crashes....
Quote from Calyps0 :I think it will be a good few years before we get anything as realistic as this in any game.

Should come eventually though, especially once hardware physics becomes as standard as hardware graphics. It's not that long ago since current games would have taken upwards of 20 seconds a frame to render.
Not only would better crash physics require new coding by Scawen, but probably new car models made by Eric - and we know that's never going to happen.
Quote from Crashgate3 :Should come eventually though, especially once hardware physics becomes as standard as hardware graphics. It's not that long ago since current games would have taken upwards of 20 seconds a frame to render.

Yea it will come eventually, but i don't see it happening within this decade. Maybe thats just my opinion though
My god, poor DB9.
I dont think many people understand the complex coding involved. It (my guess) would take a whole new physics engine basically a who new game....

I like what we have
Can you imagine a lag impact with that? Bump someones car and a lawn 2,500 miles away gets shatters with a rear view mirror, 200,000 miles away the engine would probably land.

I don't really see how it would be hard.. I've seen some physics games that are just meant for physics look pretty cool, Just look at some of the nifty PhysX Stuff, Without any knowledge, I'd say that if you make every car a "Mesh" On a "Model" And make the mesh get horridly deformed, Somewhat like a ragdoll, And make the collision mesh dissapear with how badly the mesh is mangled, Like if the car just had the body thumbtacked to the actual car, I guess that'd be called clipping, Give it some weight and strength.. I think that could be cool.

But, Alas, I have absolutely no clue what it'd really take. Just my personal thought.
Paws kind of touches on an issue with physics like this in a multiplayer game - if a car is to have huge amounts of parts break off, and if these are to affect a following car (popping a tyre from running over debris, damage from hitting a larger peice, etc) you'd need to accurately send the exact position and velocity of every single peice over the network to all connected clients.
Quote from TehPaws3D :... Just look at some of the nifty PhysX Stuff, Without any knowledge, I'd say that if you make every car a "Mesh" On a "Model" And make the mesh get horridly deformed, Somewhat like a ragdoll ...

PhysX looked very promising in its inception. The problem was it required dedicated hardware for the physics rendering. A brilliant idea, but expensive, and caused compatibility problems. The problem became worse after nVidia acquired Ageia and incorporated it into their graphics cards. Because it's proprietary technology, means PhysX will only natively run on nVidia GPU's - there are some modified drivers for ATI, but that opens a whole load more issues - The other problem being that of licensing the SDK for developers. It's expensive, and also means that a whole section of the potential audience will be excluded from these enhancements.

Quote from Crashgate3 :Paws kind of touches on an issue with physics like this in a multiplayer game - if a car is to have huge amounts of parts break off, and if these are to affect a following car (popping a tyre from running over debris, damage from hitting a larger peice, etc) you'd need to accurately send the exact position and velocity of every single peice over the network to all connected clients.

A good point. There are some wonderful "ragdoll" like games out there, but they tend to be single player. The netcode for a multiplayer environment would be horrendous, and while the local particle effects might look good, any network synchronisation issues would make it a nightmare.

There is a related discussion going on over at Will the graphics render engine get updated ?

Intel acquired Project Offset to showcase the Larrabee chipset (multi GPU and physics plus lots more) as a tech demo. The promise was that multiplayer physics would be seamless using this new technology. Again it would mean a developer nailing their colours to a proprietary technology mast, and potentially expensive for end users. The whole project was wrapped up due to legal battles with nVidia, and the performance gains weren't as expected.

The ideas are there, the stand alone implementations are out there. Unfortunately, the technology/processors/networking are not available yet. One day it will happen, but I believe it's some time before we get a homogeneous and open system available to us.
Quote from Squelch :PhysX looked very promising in its inception. The problem was it required dedicated hardware for the physics rendering. A brilliant idea, but expensive, and caused compatibility problems. The problem became worse after nVidia acquired Ageia and incorporated it into their graphics cards. Because it's proprietary technology, means PhysX will only natively run on nVidia GPU's - there are some modified drivers for ATI, but that opens a whole load more issues - The other problem being that of licensing the SDK for developers. It's expensive, and also means that a whole section of the potential audience will be excluded from these enhancements.

The biggest problem about PhysX (apart from being nV stuff only) that doesn't make it really useful for crash engines is it's inflexibility. It doesn't give you an empty playground where you can build whatever you wish, it comes with a bunch of predefined algorithms to simulate smoke, cloth and to some extent deformation - pretty much the eye candy kind of things. Whoever played Mafia II probably knows.
There are much more suitable APIs to create a GPU powered crash physics engines like CUDA, DirectCompute or better yet OpenCL. Writing stuff for a GPU with these APIs is a bit of a nightmare though, 'cause you really have to "think multithreaded" to make any use of the power GPU offers.
Quote from MadCatX :The biggest problem about PhysX (apart from being nV stuff only) that doesn't make it really useful for crash engines is it's inflexibility. It doesn't give you an empty playground where you can build whatever you wish, it comes with a bunch of predefined algorithms to simulate smoke, cloth and to some extent deformation - pretty much the eye candy kind of things. Whoever played Mafia II probably knows.
There are much more suitable APIs to create a GPU powered crash physics engines like CUDA, DirectCompute or better yet OpenCL. Writing stuff for a GPU with these APIs is a bit of a nightmare though, 'cause you really have to "think multithreaded" to make any use of the power GPU offers.

More good points.

I suppose it could be likened to force feedback. There is a library of "canned" effects that are cue'd and played back according to the old MIDI standards from which ffb was born. Immersion cornered the market with their chipset - Saitek and Logitech at least still use these chips - despite systems being able to render force feedback directly nowadays. LFS uses the direct ffb rendering approach afaik.

Until a non proprietary standard is adopted, physics rendering will continue to go through fads, and companies manoeuvring to make their implementation the de facto standard. An organisation along the lines of mpeg is needed to define how we move forward. Projects like Newton and OpenCL are leading the way to a certain extent, but Microsoft DirectX kind of blocks any multi platform standards. The videos featured in this thread just go to show what can be done, but its worth bearing in mind that they are not real time, and took hours/days of computing time to complete. Recent CGI laden Hollywood blockbusters take months/years to produce too.
1

FGED GREDG RDFGDR GSFDG