Last night I read about DRIVE and instantly got the alpha. After playing a little, I think it would be insanely awesome if I could save a crash to either a .obj sequence, MDD or something else that would contain the animation of the crash. The unique here is that the crashes are different every time. You don't know how it's gonna turn out, which makes it a whole lot more realistic. This could save hours of tinkering in any other animation system. Purchasing 3D models or making our own, and then "record" the crash would be a great asset in the VFX toolbox.
.obj isn't exactly perfect for animations. also it's rather unlikely that this gets implemented because it's quite a chunk of data you have to buffer and write to your HDD.
The .obj was just a suggestion for use with any app. Especially for those who use Videocopilot Element 3D. MDD, FBX or anything else could be used as well. Anyone looking to bake motion like this would have a computer and hard drive suited to read/write fast enough. If not, I guess it would be necessary to have a replay mode where one could bake from, thus writing frame by frame at the rate possible by hard drive speed. It's a dream, not a "I need this, or else"..
Instead of baking the entire collision, record the car position and user input. You would have to see the collision in game because it will compute it every time. The user input should be considerably smaller than the many frames of tens of thousands of polygons. Theoretically, if the game mechanics are the same, then the recreated collisions should be the same, or at least very similar. Also, by just dealing with user input and initial car position, I can foresee an editor, in which users can alter some parameters, or even add new objects or change camera positions, etc. But I may be getting ahead of myself a bit ...
I was thinking of bringing the crash mesh out of the game engine, and into a 3D animation and rendering software.
Yeah, there's no easy way around those files getting big. Who knows, as the game progresses, you may not need to export them
Anywhere around 300 to 400 nodes and 1-2k in beams. It really varies on the vehicle and how much detail.
Without knowing gory details, I'd guess tens of kilobytes per car per frame, which is in the order of megabytes per car per second. Sounds doable.
The provblem is you would have to record every nodes position, and every single beams deform, and break properties. It might be do-able, but requires a lot of effort.
We have it in our mind, but most probably it would be a professional product and not meant for end users.
I think if you want an animated car crash with the car mesh itself you would want to export the mesh itself and not the node-beam structure. in the case of a mesh export with about 60fps and e.g a car with about 5000 vertices you would have maybe about 20MB per second to export. That's just one car though and no environement counted in. it's somewhat doable but not really something you really need in a game I think.
You're not getting it... The node beam structure determines damage, mesh is only for appearence. EDIT: Maybe I'm not getting it then. Lol
I think the point is that once the nodes and beams determine the damage in the collision, there is no more need for them from an aesthetics standpoint. OP was talking about taking the mesh of the collision and importing it into another 3D renderer/animator, where appearance is all that matters.
Ace, you're spot on. And even though this might end up as a paid module if needed, I think if many get their eyes opened for this, it would mean a lot for anyone from indie film makers to the high-end VFX artist. As long as it looks good, it's not how or where an effect shot was made that counts. The OBJ sequence question was merely for the majority of 3D apps that can take OBJ sequences, one file = one frame. And especially those indie guys who's using the Videocopilot plugin Element 3D. Anyone working on rich media content, especially video and VFX, know you can't get by with only a 2TB hard drive. That's almost just a cache folder.
