drOpenGL2?
<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the category: Engine.</i>
I was investigating the problem with shiny multitexturing not working on the Mac. The reason was that the OpenGL extension GL_NV_texture_env_combine4, which apparently is the only one that draws the shiny multitextured surfaces correctly, is not supported by the GeForce 6600 drivers. This causes drOpenGL to use the ATI specific extension, GL_ATI_texture_env_combine3, which evidently does not work.
I think it's past time to update the renderer with fragment shaders. Because the rendering architecture is what it is, we can't really make Doomsday itself aware of the shaders, but we can replace the current DGL_MODULATE_TEXTURE modes in drOpenGL with shaders that can be specified in .ded files. This has two huge benefits: 1) compatibility across different graphics cards should be vastly improved, and 2) we can easily use more than 2 texture units.
After this is working, there is only a rather small effort needed for having custom shaders specified in, say, 3D model definitions.
Also, how about some nice looking water...?
I was investigating the problem with shiny multitexturing not working on the Mac. The reason was that the OpenGL extension GL_NV_texture_env_combine4, which apparently is the only one that draws the shiny multitextured surfaces correctly, is not supported by the GeForce 6600 drivers. This causes drOpenGL to use the ATI specific extension, GL_ATI_texture_env_combine3, which evidently does not work.
I think it's past time to update the renderer with fragment shaders. Because the rendering architecture is what it is, we can't really make Doomsday itself aware of the shaders, but we can replace the current DGL_MODULATE_TEXTURE modes in drOpenGL with shaders that can be specified in .ded files. This has two huge benefits: 1) compatibility across different graphics cards should be vastly improved, and 2) we can easily use more than 2 texture units.
After this is working, there is only a rather small effort needed for having custom shaders specified in, say, 3D model definitions.
Also, how about some nice looking water...?
Comments
I thought you said you weren't interested in updating the renderers at this time?
This definetly gets my vote. Having access to all of graphic card's texture units would be a huge boon for Doomsday.
I have had so many ideas for effects to implement in jDRP that shaders would be used for too.
Yes I would love to see the water replaced with a nice fluid-like effect. I came across this article on GameDev.net you might like to read, about simulating water:
http://www.gamedev.net/reference/articles/article2138.asp
What are your feelings on stencils? I think they would be a great help for many tasks. For example, it might be worthwhile to see if there is any speed difference using a stencil buffer for the rendering of the sky.
I would also like to see some more realistic shadows with models, perhaps shadow volumes + stencils?
Have you thought much about using cubemaps for the dynamic lights? I'd really like to have projection lights as well as the current omni lights. Plus once thats working it becomes a lot easier to do other effects.
In practice, we are talking replacing the messy "texture modulation" modes hardcoded into drOpenGL with a clean, shader program solution that can be easily customized and extended. The affect on Doomsday's rendering code is not huge, but it should clarify things a bit. I am thinking that, if at all possible, the rendering plugin should try to allow the engine to draw with a sufficient number of texture units always, so that the engine doesn't need to have huge conditional branches in its rendering code.
Also, retaining support for the old drOpenGL/drD3D does require a bit of planning, but I would rate this as quite a low priority. The world moves on and so should we.
<blockquote> For example, it might be worthwhile to see if there is any speed difference using a stencil buffer for the rendering of the sky.</blockquote> I doubt there would be much speed difference. The sky is practically already stenciled, only its done with the Z-buffer.
<blockquote>I would also like to see some more realistic shadows with models, perhaps shadow volumes + stencils?</blockquote>My feeling on stencil shadowing is that it's much much more important to get the world lit and shadowed right first. Also, sharp stencil shadows are not my favorite. I would like to pursue more of a soft/ambient lighting model. The shadows have to look good on the old 2D sprites, too.
<blockquote>Have you thought much about using cubemaps for the dynamic lights? I'd really like to have projection lights as well as the current omni lights.</blockquote> No, I haven't been thinking about that. Do you have any good ideas regarding that? I don't want to make large revisions of the lighting system at this point. We don't want to keep piling stuff over the existing code.
Post-1.9, I'm thinking there's much to be done with lighting and world geometry. If we consider the big picture, things like the partially freezing rendering lists, more detailed world geometry (surface meshes), and soft/ambient radiosity-like world lighting are very important.
What I used to do with my asm code was to copy the address of the selected function to a varible and instead of making a bunch of if-then-else or select-case constructs was to call [variable]. This avoided causeing unnessicary performance hits from branch mis-prediction and cache flushes. It should be possible to do something similar with C
Yeah, I agree that sharp shadows don't look all too great, even now that modern GPUs can perform AA on stencil buffered geometry (eg Nvidia's UltraShadow).
So I guess that really we should be looking at texture/shader based techniques now that large scale ambient lighting is taken care of.
Incidentaly, I implemented a quick attempt at converting huge dynamic lights to bias sources (in SVN). There are a few problems with it mind but I did it mainly to get something in-place to get us started.
<blockquote>No, I haven't been thinking about that. Do you have any good ideas regarding that? I don't want to make large revisions of the lighting system at this point. We don't want to keep piling stuff over the existing code.</blockquote>
Obviously anything we do won't happen yet a while. At least not untill after 1.9.0
Well, I was looking at the dynlight code and currently it wouldn't be all that easy to switch to a method using cubemaps.
The normal method for directional lights in a non-PPL lighting model is to project a triangle onto a surface to obtain the texture coordinates and apply a 2D texture using an additional pass or using multitexturing. This method is described in the section titled "<strong>16.1.4 Projective Textures</strong>" and "<strong>16.2.2 Spotlight Effects using Projective Textures</strong>"<a href="http://www.cs.sun.ac.za/~lynette/courses/rw778/grafika/OpenGLtuts/Big/graphicsnotes016.html"> HERE</a>
These days what with PPL being all the rage there doesn't seem to be much information available about using cubemaps for dynamic lights the "traditional" way. It would seem to me though that the same basic technique should work except we would be projecting two hemicubes instead.
The reason I'm interested in taking the cubemap approach is because once implemented the same ideas can then be easily extended for other stuff such as decals and stain maps.
However, the "traditional" approach could be adapted to fit into the existing dynamic light code fairly easily but as seperate logic branches.
A sidenote:
Have you considered how planes with different light values to that of the sector they are in (DOOM.exe rendering hacks) are to be handled with respect to the lightgrid?
Speaking of the lightgrid I've fixed up the five sample sector to block kludge I implemented with a proper scalable method. The best way to see what this does is to uncomment the debug code in LG_Evaluate() in <tt>Src/r_lgrid.c</tt> and experiment with the CVAR "rend-bias-grid-multisample" in DOOMII MAP08. Setting that CVAR to zero reverts the lightgrid init to using a single sample point (the center of the grid block) when doing the sector to block sampling in LG_Init().
<blockquote>Post-1.9, I'm thinking there's much to be done with lighting and world geometry. If we consider the big picture, things like the partially freezing rendering lists, more detailed world geometry (surface meshes), and soft/ambient radiosity-like world lighting are very important.</blockquote>
Feel free to bounce ideas off of me. I'm not exactly the fountain of all knowledge on the subject but I am interested in this stuff and I'm trying to learn as much as I can.
It would also help me to know roughly what sort of techniques you have in mind so I don't "waste" time experimenting with things that wouldn't be compatible anyway.
Though once 1.9 is released, I plan to step back from code development somewhat, in order to get the next incarnation of jDRP released.
<blockquote>What I used to do with my asm code was to copy the address of the selected function to a varible and instead of making a bunch of if-then-else or select-case constructs was to call [variable]. This avoided causeing unnessicary performance hits from branch mis-prediction and cache flushes. It should be possible to do something similar with C</blockquote>
Unless I'm mistaken the current renderers DO do this already, though it is mostly unbeknown to the engine.