The difference is Dean is talking about real-time cloth animation. Maybe it is not clear from his article. The Maya stuff looks great but certainly not useful for a game.
Maya Cloth is based on the Baraff/Witkin solver which Dean talks about in his article. However, the Maya system is made to be flexible and accurate, not fast. It may not work correctly in certain situations (ie: explode) or may take hours to render particularly if their are a lot of collision objects.
Both of these things are fine in an animation, either restart it or just wait. Neither is acceptable for a game. You need to be fast and robust.
As one of those people you mentioned, let me tell you it is hard. The numbers just kill you. Self intersection is very difficult with any decent size patch. Keeping the cloth stiff is another problem. Even my production cloth looks more stretchy then real cloth. The very best system I have seen is Baraff's stuff in Maya but it is not particularly fast or really easy to work with. Most systems are prone to blow up which is fine for an anim (check out the Geri's Game outtakes if you get a chance) but not good for a game. Imagine a game with all the curtains flapping about and moving wildly if not crashing the game.
Making a stretchy mass-spring model is pretty easy but making it look and behave like real cloth is a huge problem.
-Jeff
Unfortunately, ClothReyes and the rendering type plugins are not real-time solutions. That is what Dean at Intel was discussing. It may not have been clear from the topic.
While realistic cloth is currently used mostly as a secondary realism effect, there are interesting game-play opportunities once these type of dynamic elements can be simulated in a game. Realistic rope, nets, sailing or pirate sims where the cloth dynamics matter (not to mention you can rip them in battle like a real pirate).
This really is a hard problem and there are lots of ways to approach it. I explored some of them in an article in Game Developer a year or so ago.
Free source code and the article at www.darwin3d.com/gamedev.htm
Plug-city...
Along with Chris Hecker, I have been working on a very high end technical conference for game developers. Last year our topic for physics was rigid body contact issues. This year we are tackling continuum dynamics. This includes fluid, cloth, and other soft body simulation. We have brought together the very best developers and researchers on the topics, David Baraff and Tony DeRose from Pixar, Jos Stam from Alias, Nick Foster from PDI and many others.
This conference is very small (we sold out last year at less the 60) and not terribly cheap. It is meant for only the very high end developers. This is way beyond Siggraph or the GDC. We do not expect it to be for everyone but if you are looking to explore some of the most difficult problems in 3D simulation...
www.techsem.com
-Jeff
As a game developer and someone who has written extensively in Game Developer magazine on openGL issues, I think my credentials on GL support cannot be questioned. However, let me explain why OpenGL is having problems and why more and more companies will be shifting to DX.
The facts are that there is no one really to evangelize GL. Someone needs to lead graphics development. Someone needs a vision and a roadmap for where hardware should be going and how developers should be using it. In the old days, the defense industry and SGI served that role to some extent but cannot anymore. Microsoft has stepped up and like or not are the only ones able to do this now.
Microsoft goes out to the developers and asks them what they want to see (you may not believe this but it is true that this happens). They then talk to the hardware manufacturers and ask them what they think is possible in various timeframes. They then establish a roadmap for features and lay that out for both developers and IHVs. Hardware vendors decide what to tackle for their cards and developers decide what to use. Sometimes it works well and sometimes it doesn't.
For example, DX7 had matrix blending but it was limited. It was all the IHVs would agree to but it wasn't really good enough for any developers to actually use. So it was not widely adopted. Everyone acknowledged this and the next gen it will improve.
Now the problem. OpenGL has no one able or willing to serve this role. It is a tough one. Someone who can work with developers and IHVs, keep trade secrets, and make people listen. So OpenGL is the orphan stepchild. Ends up with proprietary extensions that follow DX and wait around for the ARB to decide what to do. Look how long it took the ARB to decide on multi-texture.
You do get people like Carmack who via a plan file (as well as discussions with hardware vendors) lets out his vision. There are others as well. But face it, DX is more agile. It can adapt to ideas quickly and has a roadmap for a yearly update.
As far as the API. Most developers don't really care. They want access to hardware functions and a method for making things work on a variety of cards. I use GL because I like it and am used to it but if a client wants D3D, I have a wrapper that takes about an hour to hook up. Unfortunately, if GL doesn't get its act together, I will be forced to prototype in DX. I am looking for solutions but this is the reality and it is looking tough for GL.
The DX8 vertex shaders use the flexible vertex format. Which is actually better then the OpenGL method of doing things. Extending the vertex structure to handle new features is a big deal in GL. In order to do things like multi-texture it requires multiple uv coordinate lists. The DX8 method is equal to the interleaved vertex format in GL but it is much more flexible. You can put any combination of the data you need in a single vertex entry. True DX copied the idea of interleaved vertex format but they have vastly improved it over the current GL method. -Jeff
Slashdot Mirror
The difference is Dean is talking about real-time cloth animation. Maybe it is not clear from his article. The Maya stuff looks great but certainly not useful for a game.
Maya Cloth is based on the Baraff/Witkin solver which Dean talks about in his article. However, the Maya system is made to be flexible and accurate, not fast. It may not work correctly in certain situations (ie: explode) or may take hours to render particularly if their are a lot of collision objects.
Both of these things are fine in an animation, either restart it or just wait. Neither is acceptable for a game. You need to be fast and robust.
That is where it gets really hard.
-Jeff
As one of those people you mentioned, let me tell you it is hard. The numbers just kill you. Self intersection is very difficult with any decent size patch. Keeping the cloth stiff is another problem. Even my production cloth looks more stretchy then real cloth. The very best system I have seen is Baraff's stuff in Maya but it is not particularly fast or really easy to work with. Most systems are prone to blow up which is fine for an anim (check out the Geri's Game outtakes if you get a chance) but not good for a game. Imagine a game with all the curtains flapping about and moving wildly if not crashing the game. Making a stretchy mass-spring model is pretty easy but making it look and behave like real cloth is a huge problem. -Jeff
Unfortunately, ClothReyes and the rendering type plugins are not real-time solutions. That is what Dean at Intel was discussing. It may not have been clear from the topic.
-Jeff
While realistic cloth is currently used mostly as a secondary realism effect, there are interesting game-play opportunities once these type of dynamic elements can be simulated in a game. Realistic rope, nets, sailing or pirate sims where the cloth dynamics matter (not to mention you can rip them in battle like a real pirate). This really is a hard problem and there are lots of ways to approach it. I explored some of them in an article in Game Developer a year or so ago. Free source code and the article at www.darwin3d.com/gamedev.htm Plug-city... Along with Chris Hecker, I have been working on a very high end technical conference for game developers. Last year our topic for physics was rigid body contact issues. This year we are tackling continuum dynamics. This includes fluid, cloth, and other soft body simulation. We have brought together the very best developers and researchers on the topics, David Baraff and Tony DeRose from Pixar, Jos Stam from Alias, Nick Foster from PDI and many others. This conference is very small (we sold out last year at less the 60) and not terribly cheap. It is meant for only the very high end developers. This is way beyond Siggraph or the GDC. We do not expect it to be for everyone but if you are looking to explore some of the most difficult problems in 3D simulation... www.techsem.com -Jeff
As a game developer and someone who has written extensively in Game Developer magazine on openGL issues, I think my credentials on GL support cannot be questioned. However, let me explain why OpenGL is having problems and why more and more companies will be shifting to DX.
The facts are that there is no one really to evangelize GL. Someone needs to lead graphics development. Someone needs a vision and a roadmap for where hardware should be going and how developers should be using it. In the old days, the defense industry and SGI served that role to some extent but cannot anymore. Microsoft has stepped up and like or not are the only ones able to do this now.
Microsoft goes out to the developers and asks them what they want to see (you may not believe this but it is true that this happens). They then talk to the hardware manufacturers and ask them what they think is possible in various timeframes. They then establish a roadmap for features and lay that out for both developers and IHVs. Hardware vendors decide what to tackle for their cards and developers decide what to use. Sometimes it works well and sometimes it doesn't.
For example, DX7 had matrix blending but it was limited. It was all the IHVs would agree to but it wasn't really good enough for any developers to actually use. So it was not widely adopted. Everyone acknowledged this and the next gen it will improve.
Now the problem. OpenGL has no one able or willing to serve this role. It is a tough one. Someone who can work with developers and IHVs, keep trade secrets, and make people listen. So OpenGL is the orphan stepchild. Ends up with proprietary extensions that follow DX and wait around for the ARB to decide what to do. Look how long it took the ARB to decide on multi-texture.
You do get people like Carmack who via a plan file (as well as discussions with hardware vendors) lets out his vision. There are others as well. But face it, DX is more agile. It can adapt to ideas quickly and has a roadmap for a yearly update.
As far as the API. Most developers don't really care. They want access to hardware functions and a method for making things work on a variety of cards. I use GL because I like it and am used to it but if a client wants D3D, I have a wrapper that takes about an hour to hook up. Unfortunately, if GL doesn't get its act together, I will be forced to prototype in DX. I am looking for solutions but this is the reality and it is looking tough for GL.
-Jeff
The DX8 vertex shaders use the flexible vertex format. Which is actually better then the OpenGL method of doing things. Extending the vertex structure to handle new features is a big deal in GL. In order to do things like multi-texture it requires multiple uv coordinate lists. The DX8 method is equal to the interleaved vertex format in GL but it is much more flexible. You can put any combination of the data you need in a single vertex entry. True DX copied the idea of interleaved vertex format but they have vastly improved it over the current GL method. -Jeff