Few questions/suggestions
by Dean Calver · in Torque Game Engine Advanced · 06/04/2004 (1:15 pm) · 5 replies
Hope you don't mind me asking/suggesting but while browsing through the source, noticed a few things.
Add a
#define GFXCOLORWRITEENABLE_ALL (GFXCOLORWRITEENABLE_RED | GFXCOLORWRITEENABLE_GREEN | GFXCOLORWRITEENABLE_BLUE | GFXCOLORWRITEENABLE_ALPHA)
This was such a stupid oversight in Dx9 that at least one Microsoft Dx9 system added _ALL
Confused why you are using FVF (GFXVertexFlag), they are a distinctly legacy idea seem stranges that that is the route you have decided to go. It will cause problems for more advanced shader (surfaces, geometry compression,etc.).
Odd choices for GFXFormat. Support for P8 even though no card supports it but no DXT, no Float formats etc.
DXT aren't a native type, every card capable of running TSE has DXT. Seems silly to still have to load TGA etc to convert.
Related to float formats, a file loader would be nice. OpenEXR have a nice file-format and loader library.
setActiveRenderSurface only support one render target. MRT is pretty common these days and real easy to support.
Related to setActiveRenderSurface, I'd advise an start/stop API approach.
i.e.
startActiveRenderSurface(surf);
RenderStuff();
endActiveRenderSurface(surf);
Hope this doesn't come across as negative, what you have done is great, just this kind of thing is my day job and hoping your won't mind a few suggestions.
Deano
(who brought torque for my home use, so I only think about rendering stuff at work but can't help myself :-) )
Add a
#define GFXCOLORWRITEENABLE_ALL (GFXCOLORWRITEENABLE_RED | GFXCOLORWRITEENABLE_GREEN | GFXCOLORWRITEENABLE_BLUE | GFXCOLORWRITEENABLE_ALPHA)
This was such a stupid oversight in Dx9 that at least one Microsoft Dx9 system added _ALL
Confused why you are using FVF (GFXVertexFlag), they are a distinctly legacy idea seem stranges that that is the route you have decided to go. It will cause problems for more advanced shader (surfaces, geometry compression,etc.).
Odd choices for GFXFormat. Support for P8 even though no card supports it but no DXT, no Float formats etc.
DXT aren't a native type, every card capable of running TSE has DXT. Seems silly to still have to load TGA etc to convert.
Related to float formats, a file loader would be nice. OpenEXR have a nice file-format and loader library.
setActiveRenderSurface only support one render target. MRT is pretty common these days and real easy to support.
Related to setActiveRenderSurface, I'd advise an start/stop API approach.
i.e.
startActiveRenderSurface(surf);
RenderStuff();
endActiveRenderSurface(surf);
Hope this doesn't come across as negative, what you have done is great, just this kind of thing is my day job and hoping your won't mind a few suggestions.
Deano
(who brought torque for my home use, so I only think about rendering stuff at work but can't help myself :-) )
About the author
Been a games dev for more years than its comfortable to remember. Have shipped a fair few games, most recently have been Lead Programmer on Brink and Heavenly Sword.
#2
We use FVF because it is simpler than the D3D VertexDeclarations. I haven't heard of FVF causing any problems, it shouldn't be an issue unless you want to use complex vertex types.
Float formats are a little beyond where we are at just yet. We should expose them though for you advanced users. I don't think anything in the base engine will use them for a while since so few cards support them in D3D right now. The nVIDIA Geforce 6800 is the first nVIDIA card to support it.
MRT is cool, we should support that, but it's not a priority as it's
my understanding that it's mostly useful for speeding up special case situations. Any suggestions for implementation?
(start/end)ActiveRenderSurface - good call, that makes a little more sense, I'll change it over.
Thanks again Dean, I especially appreciate suggestions on how to make things better - we really want the best support we can provide. If you want to submit patches to get this stuff going before I can get to it, I'll gladly check it in. Email me if you want to coordinate.
06/04/2004 (2:47 pm)
Dean - not at all, I appreciate the suggestions very much. A lot of this stuff we just haven't had the time to get to yet. The GFX layer is the initial implementation and it will change as we add OpenGL support, DXT, etc. We use FVF because it is simpler than the D3D VertexDeclarations. I haven't heard of FVF causing any problems, it shouldn't be an issue unless you want to use complex vertex types.
Float formats are a little beyond where we are at just yet. We should expose them though for you advanced users. I don't think anything in the base engine will use them for a while since so few cards support them in D3D right now. The nVIDIA Geforce 6800 is the first nVIDIA card to support it.
MRT is cool, we should support that, but it's not a priority as it's
my understanding that it's mostly useful for speeding up special case situations. Any suggestions for implementation?
(start/end)ActiveRenderSurface - good call, that makes a little more sense, I'll change it over.
Thanks again Dean, I especially appreciate suggestions on how to make things better - we really want the best support we can provide. If you want to submit patches to get this stuff going before I can get to it, I'll gladly check it in. Email me if you want to coordinate.
#3
I was purely talking about the API rather than things being used by the higher level code. Wouldn't expect the renderer to use lots of these fancy things (for a while anyway :-) ) but would be good if advanced devs can use them.
FVFs : The list you already have is 20-30 long and there are no non-float formats. I (for example) rarely have any floats in my vertex formats(its just a waste of memory/bandwidth in 90% of cases) so I could easily see myself expanding that list 3-4 times. I have some advanced shaders that use some pretty funky vertex formats. A single unsigned int can't express enough options to cover them all.
Is this style interface that bad?
#define DECLARE_VERTEX_FORMAT(type,usage,tuple,fraction)
uint32 VertexFormat[] = {
DECLARE_VERTEX_FORMAT( TYPE_FLOAT, USAGE_POSITION, 3, 0 ),
DECLARE_VERTEX_FORMAT( TYPE_SHORT, USAGE_NORMAL, 3, 1 ),
DECLARE_VERTEX_FORMAT( TYPE_SHORT, USAGE_UV, 2, 1 ),
};
SetVertexFormat( VertexFormat, 3);
Thats pretty much how (at least one) the major vendors hardware actually works. So I can't help thinking thats the right way.
Floats textures, I might see about adding them with an OpenEXR loader in a couple weeks... BTW All NVIDIA GeforceFX will get some support soon. The laptop I'm typing this on supports it (GFFXGo 53x0) under Dx9.0c (I just checked with caps viewer). I'm seeing support for G16R16F and R32F.
MRT, I usually copy the D3D interface and just add a parameter to setRenderTarget. That way its easy to tag on extra render targets for cards the support it etc. We use it as an advanced form of stencil for certain effects (i.e. render some of the scene normally with one target, than attach a second, render some more stuff that outputs into both, detach second render target and then fiddle). You can do some cool halo/glow effects very quickly like this...
I'm busy with ShaderX3 (article deadlines, I'm already late :-) ) for the next couple of weeks. But after that I'd be happy to implement a few things.
BTW Had a look at ShaderGen, like it alot :-)
06/05/2004 (7:31 am)
Brian - I was purely talking about the API rather than things being used by the higher level code. Wouldn't expect the renderer to use lots of these fancy things (for a while anyway :-) ) but would be good if advanced devs can use them.
FVFs : The list you already have is 20-30 long and there are no non-float formats. I (for example) rarely have any floats in my vertex formats(its just a waste of memory/bandwidth in 90% of cases) so I could easily see myself expanding that list 3-4 times. I have some advanced shaders that use some pretty funky vertex formats. A single unsigned int can't express enough options to cover them all.
Is this style interface that bad?
#define DECLARE_VERTEX_FORMAT(type,usage,tuple,fraction)
uint32 VertexFormat[] = {
DECLARE_VERTEX_FORMAT( TYPE_FLOAT, USAGE_POSITION, 3, 0 ),
DECLARE_VERTEX_FORMAT( TYPE_SHORT, USAGE_NORMAL, 3, 1 ),
DECLARE_VERTEX_FORMAT( TYPE_SHORT, USAGE_UV, 2, 1 ),
};
SetVertexFormat( VertexFormat, 3);
Thats pretty much how (at least one) the major vendors hardware actually works. So I can't help thinking thats the right way.
Floats textures, I might see about adding them with an OpenEXR loader in a couple weeks... BTW All NVIDIA GeforceFX will get some support soon. The laptop I'm typing this on supports it (GFFXGo 53x0) under Dx9.0c (I just checked with caps viewer). I'm seeing support for G16R16F and R32F.
MRT, I usually copy the D3D interface and just add a parameter to setRenderTarget. That way its easy to tag on extra render targets for cards the support it etc. We use it as an advanced form of stencil for certain effects (i.e. render some of the scene normally with one target, than attach a second, render some more stuff that outputs into both, detach second render target and then fiddle). You can do some cool halo/glow effects very quickly like this...
I'm busy with ShaderX3 (article deadlines, I'm already late :-) ) for the next couple of weeks. But after that I'd be happy to implement a few things.
BTW Had a look at ShaderGen, like it alot :-)
#4
Keep me updated on the float textures, that's good news dx 9.0c is going to get them going on the FX boards - about freaking time!. I haven't had time to get 9.0c going at all, sound like TSE runs it OK though, that more good news ;)
I haven't had time to play with MRT's either, I'll try to get up to date and open the API to your needs.
Thanks on ShaderGen, my hope is that you can get in there and tweak it to your own procedural needs. The output isn't as optimized as it could be, but it works.
06/05/2004 (10:42 pm)
It's been a *while* since I looked at the vertex declarations, I'll see if I can dig through them again and get you a more powerful interface. I also have to start thinking about API changes with OpenGL, so hopefully I can come up with something that's going to be happy on both.Keep me updated on the float textures, that's good news dx 9.0c is going to get them going on the FX boards - about freaking time!. I haven't had time to get 9.0c going at all, sound like TSE runs it OK though, that more good news ;)
I haven't had time to play with MRT's either, I'll try to get up to date and open the API to your needs.
Thanks on ShaderGen, my hope is that you can get in there and tweak it to your own procedural needs. The output isn't as optimized as it could be, but it works.
#5
startActiveRenderSurface( surf, RTIndex, mip );
endActiveRenderSurface( RTIndex );
If you end on RTIndex 0 (the default), it goes back to rendering to the back buffer.
06/14/2004 (3:34 pm)
OK, MRT support is in. I changed the API to be:startActiveRenderSurface( surf, RTIndex, mip );
endActiveRenderSurface( RTIndex );
If you end on RTIndex 0 (the default), it goes back to rendering to the back buffer.
Associate David Wyand
Gnometech Inc.
I just wanted to second the use of OpenEXR. If you're looking for a floating-point format, I'd recommend that one.
www.openexr.com
- LightWave Dave