Tracking Issue: Runtime Performance

[cwfitzgerald]

This issue is addressing runtime performance and the ways that we can improve it.

• Batched renderer where multiple faces will be rendered at one time.
• Vertex transformations run on GPU via per-object matrix transformations.
• Parallel.For for temporary gains?

Work to be Done:

• Rewrite renderer to get off the fixed-function pipeline and using glDrawElements
• Add shader compiler
• Add Parallel.For

Current progress can be tracked on https://github.com/Sirflankalot/OpenBVE/tree/new_renderer.

[cwfitzgerald]

I thought I would give an update on the status of the new renderer and its effect on runtime performance, as well as list TODOs regarding future plans. Comments and questions are encouraged.

The API is being planned out so that it it is as type-safe as possible so that improper use can be detected by the compiler, not at runtime. The API is designed using a model where the client code (the code using the renderer API) goes returned a very lightweight identifier that can be used to modify object properties. The current API calls these Handles. The rationale behind this is that these Handles should be very easy to pass around to where they're needed, with the actual heavy weight data being stored within the renderer. Because I can't explain things very well, here is an example of API use:

var mesh = renderer.AddMesh(raw_mesh, indices);
var tex = renderer.AddTexture(pixels, 4, 4);
var object = renderer.AddObject(mesh, tex);
renderer.SetLocation(object, new Vector3(0, 0, 5));
renderer.SetRotation(object, new Vector3(0, 2, 0));

Currently the following things are implemented within the API:

• Meshes (A container for a single object)
• Textures (A container for a single texture)
• Object (Represents an ingame object with a single mesh and a single texture)
• Camera (A container telling the renderer where to render from)
• Cone Light (A spotlight such as a train headlamp)
• Point Light (A floodlight like you would find on a platform)
• Render Control (Tells the renderer when it should actually do the rendering)

Future plans for the API are as follows:

• Sunlight control
• Instance Objects (A large amount of objects with the same texture and mesh)
• Polygon Objects (2D polygons for menus)
• Font Objects (A container representing a certain font and size)
• Text Objects (Efficiently rendered text)

As for the actual renderer internals, I am working on getting everything implimented. Rendering does actually work with meshes and textures (see here for rendering a square that moves). There are some compatibility issues between different graphics card drivers but that is being worked out and mostly just effects development on intel machines, release mode works just fine. While currently it is a purely forward renderer, there are plans to make it a combination deferred and forward renderer. All objects are drawn using deferred mode, acting like all transparency is absolute (i.e. windows won't be rendered in this pass). Then a forward renderer will come through and render all transparent parts. While this is not a perfect system, for all major use cases, this solves the transparency problem quite nicely.

The implementation is designed in such that work (such as updating matrices) only has to be done whenever an object moves. This reduces the amount of work the CPU has to do quite dramatically.

The source of the new renderer can be followed here with the two major API files being ObjectAPI.cs and RenderAPI.cs. There will be full XML documentation for the library by the time it's ready for release.

If there any questions or if I failed to explain something well, let me know and I'll help the best I can.

Edit: Added menu information to todo list.

[cwfitzgerald]

I have been busy at College so I haven't gotten much of a chance to work on the renderer, but I have gotten back in to the swing of things, and I thought I would post an update on porting the ObjectViewer over to use LibRender.

Pre LibRender:

With LibRender:

Huge progress has been made and I'm getting closer and closer to finishing up the ObjectViewer. They do look slightly different, but the bottom is fully physically correct,

I'm still working on squashing bugs all over the place, but it's getting there.

As part of the revamp, I have fixed the controls within ObjectViewer to be more sane. As opposed to moving the camera around and rotating the camera, the new ObjectViewer has a focus point that you can move around and the camera rotates around that focus point.

Edit: Branch with OV can be found here

[leezer3]

No trouble :)

I've been mostly digging around compatibility in the parsers recently, which has the very helpful sideline of digging up the most obscure bugs with older content.

My other side project is a parser for the BVE5 formats, which also has the sideline effect of doing most of the extension work required for replacing train.dat etc, and is much easier than trying to write this sort of code from scratch, as it gives me a set of known observable behaviours to work with. and in turn figure out what's an engine bug and what's simply crappy code :p