Well. The start of it, at least.
So, now that you’ve seen what I am on about let me delve into the depths of this.
Quick notes on the video:
* Those green lines are the constraints of the cloth. It’s low resolution and doesn’t give a very wide range of motion usually found in cloth, but I’ll deal with that later.
* I think we should, as a people, already be used to a lowered framerate when capturing video- so No, this program doesn’t run just 30 frames per second. (Actually I’m not sure the compression of the video lets you see the FPS to well. It says 30 however.)
What you’re seeing is a simple, procedural animation for this banner, which hangs on a wall.
Why is this anything to get excited over?
Well, there are a ton of things that can be made with cloth animation, if not only enjoying the atmosphere it creates.
I’m planning a pretty extensive implementation of cloth and other soft body physics for my engine, mostly because of all the cool stuff one can make with it.
Right now, though, I’ve got the code for dealing with the banner above, and some pretty unfinished code for dealing with ropes that can be hung around the world.
Both are implemented using a verlet integrator.
I’m eventually hoping to move this code over to use the physics engine, since it will run faster and be more stable.
Verlet integration as it is doesn’t deal tremendously well with framerates that vary wildly.
During the course of session in most games the framerate can be very different from one area to another.
Can we blame the programmer for this framerate inconsistency?
But. Operating systems can sometimes cause framerate in games and movies to be inconsistent too.
Can we blame the OS programmer for this framerate inconsistency?
Well. I supposed you could. But then again, maybe we should just deal with the situation for what it is and stop blaming people left and right.
From my experience so far the worst artifacts happen when framerate drops suddenly, but picks up again which usually makes the cloth object jerk violently.
In my test case and more serious case this isn’t a very big problem. The cloth simulates wind as is and it’s usually not that noticeable when it actually struggles.
I guess I should be thankful for the simplicity of my case.
I’m therefore not sure that the situation warrants any real action right now. But I think I might try to code some kind of damper or threshold for it.
Now that we’re aware of the first problem, here’s another one:
This type of cloth isn’t able to collide with anything (I’ll explain soon that this is not entirely true) because it would mean I’d have to deal with two essentially equivalent collision worlds and that’s just ridiculous. I will never do that.
So what I have in place instead is a simple, optional way to restrict the cloth from penetrating the wall that’s behind it. We can therefore mount these cloth objects on a wall (such as the banner in the video) and not have to worry about it sinking into the wall.
So technically, the cloth object is rather simple, but this variance in behavior is actually enough to make it useful.
For a start, this is more than I could’ve expected and it actually doesn’t suck terribly so I’m good for now. 🙂
Edit: Guess I fudged on the promise from the last post about showing off the AO generator with some cooler models.
Truth be told the AO doesn’t get that exciting on said cooler models. So I, in my mind, voted against making a new post about it. Also I failed my first attempt at implementing a blur algorithm for it so that sucks too. But as soon as I get the blurring working I’ll make a new post with some cool models and AO, and you can see for yourself that it doesn’t make a whole lot of difference.
I have some other pressing matters to attend to, namely animation, so I’ll be working on that right now and not the AO.