Tuesday, March 31, 2009
at
12:18 PM
|
6
comments - [Click to post comment]
Posted by
Prometheus
|
|
|
||||
|
Monday, March 30, 2009
at
2:24 AM
|
6
comments - [Click to post comment]
Ahh... I finally got it quite right. Few days back I was trying to tackle frame rate independent physics. Sad to say, bullet physics as nice as it was, was horrible at interpolation. This is due to it doing extrapolation instead of interpolation which didn't work very well with force intensive physics (Having multiple forces applied to an object at each simulation step). The reason for interpolation/extrapolation of physics is so that physics can be simulated at a fixed time step to maintain stability and determinism. This means that given an exact state of an initial physics world, the simulation will always end the same way with the given fixed input in any number of tries. However, as frame rate is not in fixed time step and can fluctuate depending on cpu/gpu performance, interpolation/extrapolation was introduced to provide "smooth" graphical display. The sad part about bullet though was that it's doing extrapolation. In layman term, this means predicting into the future. In some sense it's correct if you think about each simulation is a few millisecond behind the current rendering frame. But it causes horrible jerks due to the prediction. Hence I went and dig through bullet's source and modified it to do backward interpolation or I should say "true" interpolation as described here: http://gafferongames.com/game-physics/fix-your-timestep After this, I managed to get good frame rate independent simulation which helped a lot on my machine where fps fluctuated around 30 to 60. All was nice and dandy until we tried it on the faster 8800GTS and 9800GT cards. It was giving horrible jerky motion due to fluctuating fps of 58 to 60. Thanks to Ogre for providing the frame smoothing feature. After turning it on and tweaking to a good enough value (0.05 - meaning average 3 frames at most), we got pretty darn smooth simulation. :) But there were still some vital pops and jerks once in a while due to paging geometry. In the end, I had to crack my head and totally put all processing of paging geometry stuffs into the background thread. That solved almost all jerks and pops. :) I think I'm happy with what I've achieved thus far. Now I can focus on network and scripts. FINALLY! P.S. I'll be posting up a patch to bullet for that interpolation feature once I get enough time. I didn't remove the extrapolation technique. Just #defined them so users can switch between them when compiling. I think they should really embrace this method as the default though. It works a lot better for visual side of things even though it means visual is slower by 1 frame.
Posted by
Lf3T-Hn4D
Wednesday, March 25, 2009
at
7:06 AM
|
5
comments - [Click to post comment]
L3ft_H4nd finally got the blog comments working ! after many complaints bout the broken post comment link.
Posted by
Prometheus
Wednesday, March 18, 2009
at
2:49 PM
|
2
comments - [Click to post comment]
Tada! I know, I know.. Not the best shot to be proud of. But its the best shot at showcasing every single graphical feature we have in our game right now; HDR, Refraction, Shadow, Paging Geom, Baked AO (somewhat like light map but independent of light source), fuzzy holo and lens flare. Yes, this post is more about the refraction than anything else. Getting refraction up was a real pain. Took me a few days of frustrations and hitting Ogre bug(s) before I got it working more or less. The FPS isn't too happy on my machine though. 8600GTS just doesn't cut it for such fillrate intensive feature. I'm getting about 40-50fps when every feature is turned on (shadow at lowest setting). I've yet to test it on the more powerful 9800GT, but I bet it'll be blazing fast. :) The trick behind refraction is that it's a postprocessing feature. Thanks to Ogre's nifty compositor system, It allowed me to build this pretty much from a simple compositor script and a handful of materials and shader files. What I did was basically tell compositor to render the scene in what I call the refraction pass. What happens here is that instead of rendering the scene with the basic materials, we render them with special refraction materials which sets the refraction and depth info into a temporary render texture. This is done by ordering the compositor pass to use a custom material scheme. After this is done, the render texture is then used to distort the real scene texture base on the offset and depth info. Not too complicated. :) However this technique has it's quirks and problems. Attempt at using it for effects like stained glass results in ugly distortion of the tinting. Stacking them up over one another will most definitely turn it into a muddle of crappy distorted glasses. Still, this effect has it's use in many other cases. For one, we intend to use it for simple water based effect like the shot above. Uh.. yeah, it's not going to look like that, I'll be changing it to the proper shader later. :P The second effect, which we will be using a lot, is heat haze and shield distortion. This will definitely spice up things. Hehe :D Aside from this, there's still more to deal with. To get this working I had to work around a problem with the PCZSM(portal scene manager) that I was using. It was a bug that causes compositor to not function properly. I've yet to figure out how to solve that. Hopefully I can solve that soon and move on. There's already tons of things in my todo list and it's piling up! :( That's it. I'm done. Shader programming should be a full time job. Sheesh. P.S. I know I didn't really properly explain the whole process of the refraction shader. But I'll leave that to the imagination of any reader who intends to add refraction into their system. :) It's not that hard to figure it out.
Posted by
Lf3T-Hn4D
|
Liquid Rock Games and Project Aftershock. All Rights Reserved.
|
||||