torque renderer
by Dan Martin · in Torque Game Engine · 10/25/2002 (4:48 pm) · 14 replies
Does it bother anyone else that there's no explicit renderer in the torque code base?
OpenGL calls sprinkled all over the code base seems to me like it could get ugly, especially if we wanted to make changes to the way everything is rendered.
Also, is it just me or are there a lot of unecessary state changes going on when a scene is rendered? Perhaps instead of changing render state inside the renderObject method there should be a dglSetRenderState function and a RenderState structure or something along those lines.
There's also the problem of vertex array storage, I believe the best that torque does is CVAs. Utilizing the NV_var extension, or the ATI_vao extension would probably lead to better geometry throughput.
I would also like to see some sort of a shader system put into place, even something like quake 3 shaders would be beneficial IMHO.
I hope no one takes this the wrong way, I'm not trying to trash the TGE, I love it. These are just some minor changes to the rendering pipeline, however they would take some major work due to the structure of the code...
I think the TGE is great for what it is, obviously it was designed during a transition period where hardware was growing in capability very quickly. It's tough to expect an engine to use the new hardware features when even OpenGL hasn't really caught up yet. I do feel that the rendering code in torque needs some reworking in order to be competitive with other game engines.
I for one am more than willing to work on this part, and plan on doing some of this work regardless of the feedback I receive here. That said I would like to start a discussion.
I would like to start a technical discussion on what we can do to improve the rendering quality of the torque game engine. When I say technical discussion I mean that comments like "The images it displays are already pretty good, shut up!" and so on will not be appreciated.
Some of the key targets I have in mind are:
- Increasing triangle throughput
- A shader based rendering pipeline
- Overall better support for modern GPUs
One of my first goals is to implement a terrain LOD algorithm which is more friendly to graphics hardware that has tranformation and lighting support.
Tell me what you would like to see...
Thanks.
OpenGL calls sprinkled all over the code base seems to me like it could get ugly, especially if we wanted to make changes to the way everything is rendered.
Also, is it just me or are there a lot of unecessary state changes going on when a scene is rendered? Perhaps instead of changing render state inside the renderObject method there should be a dglSetRenderState function and a RenderState structure or something along those lines.
There's also the problem of vertex array storage, I believe the best that torque does is CVAs. Utilizing the NV_var extension, or the ATI_vao extension would probably lead to better geometry throughput.
I would also like to see some sort of a shader system put into place, even something like quake 3 shaders would be beneficial IMHO.
I hope no one takes this the wrong way, I'm not trying to trash the TGE, I love it. These are just some minor changes to the rendering pipeline, however they would take some major work due to the structure of the code...
I think the TGE is great for what it is, obviously it was designed during a transition period where hardware was growing in capability very quickly. It's tough to expect an engine to use the new hardware features when even OpenGL hasn't really caught up yet. I do feel that the rendering code in torque needs some reworking in order to be competitive with other game engines.
I for one am more than willing to work on this part, and plan on doing some of this work regardless of the feedback I receive here. That said I would like to start a discussion.
I would like to start a technical discussion on what we can do to improve the rendering quality of the torque game engine. When I say technical discussion I mean that comments like "The images it displays are already pretty good, shut up!" and so on will not be appreciated.
Some of the key targets I have in mind are:
- Increasing triangle throughput
- A shader based rendering pipeline
- Overall better support for modern GPUs
One of my first goals is to implement a terrain LOD algorithm which is more friendly to graphics hardware that has tranformation and lighting support.
Tell me what you would like to see...
Thanks.
#2
Dan, you're right on with what I've been looking into doing for a while now. I've actually got some stuff done already, but it's really early stage stuff, and I haven't done testing outside of my little sandbox. I've got a .plan update coming up soon, keep an eye out.
10/25/2002 (6:54 pm)
Actually, scene graph-based engines can provide state-based sorting throughout the whole scene instead of just on a resource level.Dan, you're right on with what I've been looking into doing for a while now. I've actually got some stuff done already, but it's really early stage stuff, and I haven't done testing outside of my little sandbox. I've got a .plan update coming up soon, keep an eye out.
#3
10/25/2002 (7:47 pm)
I think you are very right Dan. On the top of my list for stuff that I would like to see added to the renderer is PPL and shader support. Would be REALLY happy to see this stuff get in there, would help Torque graphically a lot.
#4
In a way, a proper scene graph can more easily avoid this unecessary state switching by accumulating render state from other nodes, sorting based on this render state, and finally only changing the necessary state at each node.
James: I'm quite interested in what you have done, care to elaborate? Do you think it would be a good idea to create a renderer interface, and make the scene objects render using that, rather than directly interfacing with OpenGL?
Ben: Certainly would. Making it easier to create new effects is a side effect of the restructuring I'm talking about.
GG people, notably Tim: I have some idea of how much work this would be, but can you tell me if I'm in for a nightmare, or if refactoring the rendering code can be done fairly independantly of the rest of the system?
10/26/2002 (3:02 pm)
Robert: If you're asserting that scene-graph based rendering engines are prone to this sort of render state abuse, I have to disagree.In a way, a proper scene graph can more easily avoid this unecessary state switching by accumulating render state from other nodes, sorting based on this render state, and finally only changing the necessary state at each node.
James: I'm quite interested in what you have done, care to elaborate? Do you think it would be a good idea to create a renderer interface, and make the scene objects render using that, rather than directly interfacing with OpenGL?
Ben: Certainly would. Making it easier to create new effects is a side effect of the restructuring I'm talking about.
GG people, notably Tim: I have some idea of how much work this would be, but can you tell me if I'm in for a nightmare, or if refactoring the rendering code can be done fairly independantly of the rest of the system?
#5
It's hard to say what the best way to go about it would be. I think the flexibility afforded to each object is one of torque's better qualities. What I'd like to work towards is as you said--some degree of centralization with the renderer. To maintain the individuality of the objects, I think they should push their geometry (etc.) to a central rendering manager which, following scene graph culling, would chunk together objects with same or similar material/state and render them in order.
As I understand it, that's mainly the more modern approach, and it should at least reduce the bottleneck that's been seen with objects replicated many times over.
10/26/2002 (6:04 pm)
I just put up a .plan update, so look there for an idea of what I'm working on.It's hard to say what the best way to go about it would be. I think the flexibility afforded to each object is one of torque's better qualities. What I'd like to work towards is as you said--some degree of centralization with the renderer. To maintain the individuality of the objects, I think they should push their geometry (etc.) to a central rendering manager which, following scene graph culling, would chunk together objects with same or similar material/state and render them in order.
As I understand it, that's mainly the more modern approach, and it should at least reduce the bottleneck that's been seen with objects replicated many times over.
#6
Might it be possible to optimize certain advanced graphics capabilities by saying something like:
? I guess it would depend how far you abstracted from the GL state machine. Personally, I think it'd be nice to roughly map all the GL calls onto the abstract renderer, then let the renderer figure optimizations out in some efficient way from there.
10/26/2002 (11:32 pm)
Having an abstract centralized renderer and such would in addition to making state optimizations possible also allow us to finally be free of the silly opengl->d3d hack they use... Not a big thing, but wouldn't hurt, and when the hypersuperduper four dimensional SDK comes out, it'll be a bit easier to port stuff for that, too.Might it be possible to optimize certain advanced graphics capabilities by saying something like:
if(renderer->supports(RENDERER_8TEXUNITS))
.... big complicated render code ....
else
if(renderer->supports(RENDERER_4TEXUNITS))
.... notsobig code ....
else
.... nasty old code ....? I guess it would depend how far you abstracted from the GL state machine. Personally, I think it'd be nice to roughly map all the GL calls onto the abstract renderer, then let the renderer figure optimizations out in some efficient way from there.
#7
I'll have to try and find a link to the layout. Damn!
State management is a big issue. I agree that flexibility should be kept, but you dont want to be at the point where when you write a new object class you have to write its render functions as well.
Phil.
10/27/2002 (1:15 am)
I think it'd be useful to try and follow John Ratcliffe's class structure for rendererers if we're going to do that, it seems pretty well organised for shaders and fast rendering.I'll have to try and find a link to the layout. Damn!
State management is a big issue. I agree that flexibility should be kept, but you dont want to be at the point where when you write a new object class you have to write its render functions as well.
Phil.
#8
10/27/2002 (2:02 am)
@Phil: any link or ressources about John Ratcliffe's stuff ? I do not know what it is :)
#9
I would definitely like to toss around some ideas about what we should have in our abstract renderer API. For instance, should scene objects know how to draw themselves using our abstract renderer, or should the renderer know how to draw every scene object? There are certain advantages with each approach, IMO.
Ben: Yes, the direct3d stuff in torque is terrible. This would be a way out :) As for the pseudo-code, hopefully each renderer backend would be able to optimize the render calls itself..
Frank: Checkout jratcliff.flipcode.com
Who wants to talk about renderer architecture?
10/27/2002 (5:10 pm)
Phil: I assume you're talking about his CGDC talk? I thought he had some pretty good ideas for sure.. His vertex caching stuff was interesting, although I suppose the managed pool in direct3d makes it unecessary. I do like the way he detaches the description of the scene from the data... good stuff.I would definitely like to toss around some ideas about what we should have in our abstract renderer API. For instance, should scene objects know how to draw themselves using our abstract renderer, or should the renderer know how to draw every scene object? There are certain advantages with each approach, IMO.
Ben: Yes, the direct3d stuff in torque is terrible. This would be a way out :) As for the pseudo-code, hopefully each renderer backend would be able to optimize the render calls itself..
Frank: Checkout jratcliff.flipcode.com
Who wants to talk about renderer architecture?
#10
My current plan of attack has been adding support for a shading language into the existing rendering engine. It seems to me that once a good shading description is in place, minimizing state change becomes a simple matter of sorting by shader.
Similarly, implementing some 'shader requires' and 'fallback' keywords easily buys support for all kinds of advanced hardware without necessarily leaving our lower-end users in the cold.
Maybe when OpenGL 2.0 goes out it would be a time saver to have an abstracted renderer, but I'd just as soon re-write the rendering with the new API in mind if/when such a radical event occurs.
10/28/2002 (6:25 am)
Hmm. I'm not so sure that Torque really needs an abstracted renderer. OpenGL is already a cross-platform API, after all, and the fixed function pipeline is dying anyways. My current plan of attack has been adding support for a shading language into the existing rendering engine. It seems to me that once a good shading description is in place, minimizing state change becomes a simple matter of sorting by shader.
Similarly, implementing some 'shader requires' and 'fallback' keywords easily buys support for all kinds of advanced hardware without necessarily leaving our lower-end users in the cold.
Maybe when OpenGL 2.0 goes out it would be a time saver to have an abstracted renderer, but I'd just as soon re-write the rendering with the new API in mind if/when such a radical event occurs.
#11
The flexibility in torque right now is great, that's a strong point. However, it seems to lead to degraded performance. Storing vertices in driver managed memory, rather than system memory is important for good performance now, if we had a centralized renderer, we could control the interface the objects have with the rendering hardware and "force" proper usage of vertex buffers for example.
Another member mentioned the current D3D hack, it'd be nice to fix that "the right way". A shader system would definitely be easier with a centralized renderer, because we can have different backends (or implementations if you prefer) for the renderer that optimize the shader in different ways.
The fixed function pipeline isn't so much gone as becoming more flexible. There's just a couple of programmable stages being added.
Also, there's no indication that the opaque vertex/indedx buffer model for graphics hardware is going to last forever. What if Hughes Hoppe's work on geometry images, and his suggested architecture for graphics hardware makes it into mainstream usage? A central renderer would make the transition much easier.
If people really aren't interested in a centralized renderer for torque, I can just make a branch in my own cvs tree I suppose, but I think it's definitely worthwhile.
10/28/2002 (8:23 am)
Mark: Sure, torque doesn't *need* an abstracted renderer. It doesn't need shaders either. The point is that centralizing this stuff will make it easier for torque to grow with hardware and APIs. Also, it allows us to have some control over the way objects are rendered.The flexibility in torque right now is great, that's a strong point. However, it seems to lead to degraded performance. Storing vertices in driver managed memory, rather than system memory is important for good performance now, if we had a centralized renderer, we could control the interface the objects have with the rendering hardware and "force" proper usage of vertex buffers for example.
Another member mentioned the current D3D hack, it'd be nice to fix that "the right way". A shader system would definitely be easier with a centralized renderer, because we can have different backends (or implementations if you prefer) for the renderer that optimize the shader in different ways.
The fixed function pipeline isn't so much gone as becoming more flexible. There's just a couple of programmable stages being added.
Also, there's no indication that the opaque vertex/indedx buffer model for graphics hardware is going to last forever. What if Hughes Hoppe's work on geometry images, and his suggested architecture for graphics hardware makes it into mainstream usage? A central renderer would make the transition much easier.
If people really aren't interested in a centralized renderer for torque, I can just make a branch in my own cvs tree I suppose, but I think it's definitely worthwhile.
#12
Why should we force anyone to use vertex buffers 'properly'? Maybe someone really does have a good reason for rendering his new object in immediate mode. We don't know that. :)
I think we all agree that the D3D is very hackish, but I'd favor dropping it altogether as opposed to fixing it. A typical indie developer has limited tech support resources, and it's just plain silly to support and maintain two equivalent backends when Quake 3/Doom 3 have proven that you really only need to support one.
If hardware manufacturers decide geometry images, or NURBS surfaces, or voxels, or are the way to go... Don't you think we'll have to re-write the collision engine as well? By then, there will probably be major advances in network architechure too. Sounds like we'd save time by just writing a whole new engine!
I suppose I'm just trying to say that refactoring code for reuseability isn't always a win. Remember, code isn't reusable until it's been re-used.
Anyhoo, if you want it, do it. But I don't think that kind of change belongs on the torque mainline, and I'd strongly urge GG not to commit any such engine patch to the CVS.
10/28/2002 (9:19 am)
I'm just not convinced that abstracting the renderer will result in less net work overall, is all. Plus, unless people are actually interested in writing additional backends, it's just so much extra overhead.Why should we force anyone to use vertex buffers 'properly'? Maybe someone really does have a good reason for rendering his new object in immediate mode. We don't know that. :)
I think we all agree that the D3D is very hackish, but I'd favor dropping it altogether as opposed to fixing it. A typical indie developer has limited tech support resources, and it's just plain silly to support and maintain two equivalent backends when Quake 3/Doom 3 have proven that you really only need to support one.
If hardware manufacturers decide geometry images, or NURBS surfaces, or voxels, or
I suppose I'm just trying to say that refactoring code for reuseability isn't always a win. Remember, code isn't reusable until it's been re-used.
Anyhoo, if you want it, do it. But I don't think that kind of change belongs on the torque mainline, and I'd strongly urge GG not to commit any such engine patch to the CVS.
#14
You've misunderstood what I meant by backend. It is well known that Doom III has different OpenGL backends for different classes of hardware. I don't care if we support only one API, I'm just saying that it'll be easier for scene objects if we can encapsulate this sort of thing.
This isn't just about reusability... that was just one of the benefits.
10/28/2002 (4:30 pm)
"I think we all agree that the D3D is very hackish, but I'd favor dropping it altogether as opposed to fixing it. A typical indie developer has limited tech support resources, and it's just plain silly to support and maintain two equivalent backends when Quake 3/Doom 3 have proven that you really only need to support one. "You've misunderstood what I meant by backend. It is well known that Doom III has different OpenGL backends for different classes of hardware. I don't care if we support only one API, I'm just saying that it'll be easier for scene objects if we can encapsulate this sort of thing.
This isn't just about reusability... that was just one of the benefits.
Torque 3D Owner Robert Blanchet Jr.