Tuesday, June 22, 2010 at 2:09 PM |  
Small real time outdoor test scene to test paging geometry as well as our new water shader materials. Several future wish list improvements include more material blending for terrain surfaces. Further stress tests and optimizations for dense foliage systems needed.

Posted by Prometheus


LogicalError said...

Looks really amazing! Good work!

Just some positive criticism;
The lighting looks a bit flat in this scene, it could use some improvement.
There's a repeating texture at the side of the road.
Mountains and vegetation could use some more variation in color, a subtle variation in hue should probably be enough.
The stream should move in a direction, perhaps you could some splash particles around the boulders in the water..

June 24, 2010 at 12:32 AM  
Lf3T-Hn4D said...

Thanks for the positive and constructive criticisms and comments :-)

Do keep in mind that this is a test work that we tried to achieve in only 3 days time. So it's not what we would called perfect. Also our FX system is not ready yet. Thus no water splashes and the likes. We are well aware of what we can improve on. However this is just a stress test on what we can achieve with our current engine in a short period of time. ;-)

June 24, 2010 at 1:53 AM  
btolputt said...

Out of curiosity, how does your system fare when moving through the scene at "high velocity"?

A static or even slow moving scene with paged geometry is alot different to one that needs to be moving at high speed during a racing game.

June 28, 2010 at 6:43 PM  
Lf3T-Hn4D said...

Hi, We actually abstracted the paged geometry system to batch in a separate thread. This way, you get to move about while the geometry is being batched which help cut down the jittering and jerks.

It works extremely well as we tested with our first level. However, in a level full of grass, bushes and trees, we have no idea if it will show bad popping glitches or not. But so far with our test cases, it's doing pretty well. ;-)

Personally, I'm more worried about the static scene batching. Right now we page it in/out of GPU ram to avoid GPU ram trashing(dx9 sucks with this, somehow OpenGL handles this better). However, it's causing noticeable jerks when running on a fast machine with fps above the range of 50. We probably should just force it to be 30fps all the way.

June 29, 2010 at 8:15 AM  
btolputt said...

> dx9 sucks with this, somehow OpenGL handles this better
I'd be interested to know the hardware / drivers for this. I'm an OpenGL fan myself, but have tended to find the DX9 drivers better in nearly all cases (the wonders of a Microsoft-driven world).

> We probably should just force it to be 30fps all the way.
I tend to find a capped frame-rate helps when needing to swap geometry in & out of the GPU memory, so I believe this will definitely help you as well.

And, depending on the level of physics interaction in your game, being able to tie the frame-rate down usually allows for a little more leeway in solving collisions & such. A little motion-blur on the vehicles and I doubt anyone but the most fastidious of gamers will care about the framerate not reaching lofty 120fps heights :)

June 29, 2010 at 5:16 PM  
Lf3T-Hn4D said...

DX9 works better in nearly all cases. Drivers tend to be faster and more efficient with DX9 compared to OpenGL in windows. Probably due to their optimal memory management, they perform worst when it comes to memory swapping. I had this behavior on all nvidia cards I tried with. Not sure about ATI since my primary test machine is nvidia. So any issues, I fix them before trying it out on the ATI box.

I suppose most game out there uses the capped frame-rate to hide geometry swapping jerks. That plus motion blur should play well together. But until I test it out, I'm pretty much in the dark here.

Btw, are you familiar with physics simulation? What are the typical time step interval you use for physics simulation? I'm fixing mine at 60fps at the moment. I'm wondering if it's a little bit too high though.

June 29, 2010 at 8:43 PM  
btolputt said...

I'm not an expert by any means, but in the physics simulations I've run (and according to the advice I have been given) 60 fps is pretty standard.

It does depend on how much interactivity between objects you have, how fast things are moving, and whether or not you are using CCD for fast moving objects though. I've seen simulations setup that run decently at 40fps involving only a few dynamic objects ever interacting exactly (a racing game might fit into this).

I assume you are using Bullet for this project? If so, there is also the number of iterations used to solve constraints which you can adjust depending on the issues.

June 30, 2010 at 6:06 PM  
Lf3T-Hn4D said...

Thanks. That's good to know. Yes, I'm using bullet for this project. I'll probably look into trying out at 40fps. However since our crafts are moving at pretty high speed (3x of normal racing games), I suspect it'll be too low without CCD.

July 1, 2010 at 3:57 AM  
deksuteru said...

Absolutely stunning. I have zero knowledge in the technicalities, but I would love to see this scene in some racing action...SOON!

July 2, 2010 at 4:27 AM  

Post a Comment

Liquid Rock Games and Project Aftershock. All Rights Reserved.