Full Version: rendering by Ogre
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5
Hi, I've ported VDrift code to render using OGRE
I know this engine for some time and thought it would be the best one here.
Although much is done now, few things are still missing and few don't work so well.
Check my screenshots at:

I'm somewhat disappointed in the performance. What seems to be the problem is big count of drawn batches. On Hungaroring06 there is a place where 6217 batches are drawn resulting 18 fps, VDrift has here 58 fps. But there are tracks that render just fine, every one having below 1000 batches would render at 60 fps. (more statistics can be seen on those sceens, left upper corner shows fps, triangle count and batches count).

What was easy to implement are tire smoke particles and tire trails. Trails aren't how they should be, they're billboard aligned to screen, but those where already in Ogre and don't look that bad from distance.

I still don't have GUI. I've got MyGUI running ( but probably all actions and rendering settings need to be rewritten. But since there's no Gui now, the game just starts from saved settings on one track with one car.

I had also a lot of trouble in getting car x,y,z axises put the way they really are, and I still have some offset in half of the cars. The driver also isn't in right place.

I used my own camera implemented some time ago, it can be moved with mouse during play, has 4 view modes, and all is saved in xml file.
I've done the meters (velocity and rpm) here and also in original VDrift's code if you're interested (just couldn't drive without them Big Grin ).

Anyway, tell me what you think about this, is it worth the way to complete or would it be better to leave rendering how it is.

My first intentions were to use the (getting better) Ogre's editor (, write a plugin for it to render and edit roads and then drive on them, also having a terrain from heightmap. Roads would have to be merged to fit with terrain, this could require some time to implement.

Also many features speak for using a higher level engine for rendering, lot of stuff is already done (like post-processing effects,etc.) and rendering is independent from rendering system (DirectX 9,10, OpenGL..)

The source files didn't get very messed up, I added few of my own for Ogre, which use the GAME class to get all needed stuff. Tell me where to put it if you want to look at it. I'm working on Windows XP, and don't have other systems where I could check the game.
Quote:What seems to be the problem is big count of drawn batches.
Yeah, VDrift is draw call bound especially on modern GPUs.

Does Ogre support state sorting, geometry batching? You have to reduce the number of batches. Ogre wiki says: "Generic SceneManager hierarchically culls by bounding volumes". I wonder how it compares to VDrifts implementation.

On Windows you might use MinGW/gprof or MSVC/CodeAnalyst for CPU profiling and GPUPerfStudio or NVPerfHUD for GPU profiling.

Edit: You could try to use PCZ SceneManager antiportals to reduce batch count(not sure if they have an automatic antiportal generator though).
Frustum clipping works, when I set the clipping (view) distance very low at 200, I see there 500 batches and Fps is about 150 (at this place on screen in Hungaroring06).
Right now im trying to use StaticGeometry from Ogre properly. I've attached the plugin OctreeSceneManager but I didn't notice any big difference.
Are you using the OpenGL renderer? I think there should be a noticeable speed difference as draw calls are more expensive under DirectX.

You could cull objects based on their size and distance. Does Ogre have object fade out functionality?

PS: Are you abusing ribbon trails for skid marks? :lol:
Well I think view distance is good enough to do clipping, it can be adjusted so every track would render well. Ogre has support for LOD,paging and instancing geometry though.
The thing that's better is that VDrift's direct rendering implementation in OpenGL is fast. Seems like Ogre is slow compared to it.
I've checked VDrift on Hungaroring06 and in this place it drew 3455 of 5166 no2d_noblend objects and 1073 of 1074 no2d_blend, so 4528 of 6240 track objects and it had 56.5 fps there, so it manages big batches pretty good.
Another strange thing is that I'm using DirectX9 renderer in Ogre (I have WindowsXP) and as I checked the OpenGL renderer it gives half of the framerate. Don't know, maybe it is written somehow slower ?
As I tested with no particles, trails and nothing from track rendered (only car and hud) DX gives 1050 fps, GL only 600 fps.
Yeah, ribbons aren't for tire trails, but better those than none I think, and using them was easy.
Quote:OpenGL renderer it gives half of the framerate
This usually means that the OpenGL drivers on Windows suck big time, so I am even more impressed by VDrifts current scenegraph implementation.

I am curious how the OpenGL call trace looks like. Do you mind to upload the executable?
I have put a working binary (I hope so) with data and source code at:
It includes all data with one car, but no tracks. So it should run after copying a track into vdrift_ogre/data/tracks and choosing it in vdrift_ogre/game.cfg, by: track = the_track_name.
I've messed up pathmanager so it reads all cfg's form where the executable is and also puts output there.
At begin you shoud see the Ogre's dialog to select render system and its settings like resolution, etc.
In case of problems you can see how log files look when the game has started without errors from the included ones. I'm compiling in VS2008 using stlport.
Many tracks are modeled with a lot of very small objects that can probably be combined for better performance in situations where the draw calls are expensive. On my test machines it was actually cheaper to not do much combining and take the cull advantage (especially with newer ATI drivers), but there's object combining code in VDrift, it's just disabled. If you look in GAME::LoadTrack, the third to last argument to DeferredLoad is false, you can change that to true to do more object combining:

track.DeferredLoad(pathmanager.GetTrackPath()+"/"+trackname, pathmanager.GetEffectsTexturePath(), *tracknode, settings.GetTrackReverse(), settings.GetAnisotropy(), settings.GetTextureSize(), graphics.GetShadows(), false, info_output, error_output)

EDIT: this is wrong. I forgot that this doesn't actually combine meshes, it just combines scenegraph elements.

Using a texture atlas you could combine even more objects.

I dislike the Ogre architecture, and enjoy writing rendering systems myself anyway, so I'm going to continue to develop VDrift's rendering system... but perhaps there is room for two rendering systems?
Quote: but perhaps there is room for two rendering systems?
Yeah, if CrystalH agrees to maintain the ogre code path.

I've got gui driven profilers here. Is there a way to force ogre not to grab the mouse?
Just to aswer previous post, I have no idea how to get rid of the mouse.
And, I think there is no need to redo VDrift in OGRE and keep it, especially when the current rendering in VDrift is well optimized and OGRE is just one layer of software upon rendering. I just did it as a start to get known with code.

I'm creating a somewhat different game, namely Stunt Rally - so rally style not racing, and with stunts like loops, jumps, uneven terrain and such (Generally is close, also old game Stunts from 1990) but with great simulation from VDrift.

I've created another playable release with terrain, trees and grass.
Screenshots can be seen at:
and it can be downloaded from:

I think this is where OGRE is best at, with its terrain and plugin PagedGeometry with pre-rendered billboards for distant trees, waving grass and so. Performance here is quite all right.

I hope I'm not disturbing by posting this here. But since its in the topic and its still VDrift I guess here's the place.
Of course, post comments on it, what do you think about it.
Really nice project, keep it up!
Driving through the jungle! Looks fun. :-)
I've combined a new quite playable relase version 3.
As before, it can be downloaded from
and screenshots are at

I'm assigning surfaces for wheels based on the blend maps from terrain and from the image of road (not using beziers still), so it uses surfaces.txt.

The road is a spline (Catmull-Rom) and has LOD's so that better quality segments are near the car. This way road can be easy edited and could form loops and such when not sticked to groud (this is my plan for future).

Anyway I'm still at the version of VDrift from may I guess (lot has changed and would require some time to adapt).

Also added reflections, so the car looks better, but since it's a cube map the default settins are to render one face every 500 frames and all faces at start.
Very impressive. The ingame menu is cool. Keep up the good work!
This is really cool.

You've already created an off-road game from VDrift. That itself is an achievement and would generate more interest than you realise.
Pages: 1 2 3 4 5