Renderer improvements

[OrbWeaver]

Ok, fixed three occurrences of OUTSIDE, where PARTIAL should have been. The render speed is down at 30 msec again.

 

Oops, that's what happens when I get too aggressive with search-and-replace (using ack instead of grep, and Vim macros this is actually very efficient, but you can make mistakes clearly).

 

I'll take this as an eye opener what an effective culling algorithm can achieve (and I'm sure there are more effective ways to do that).

 

Yes, I was just thinking that in fact. I do wonder whether many of the so-called "optimisations" in the GtkRadiant codebase actually do more harm than good, but clearly this one is very effective and necessary.

[OrbWeaver]

Just a quick question about the static sky render. Will there be an option to enable/disable this quickly without having to go into preferences? I'm thinking for finding leaks it may be hard using the rendered skybox views.

 

The skybox is only rendered in the lighting mode, in the regular preview mode you will just see the sky editorimage as you do with the current release. This follows the objective that the lighting mode should be as accurate as possible, whereas the regular mode is what you would normally use for building brushes, finding leaks etc.

[OrbWeaver]

GLSL shaders

 

I have resurrected the GLSL lighting shaders, and these are now used by default on the Linux builds. GLSL is the OpenGL Shading Language, which is a C-like shading language that is compiled and linked directly by the OpenGL libraries, in contrast to NVIDIA's Cg which must be compiled into the ARB assembler format using proprietary tools. Although the ARB assembly program method is not actually deprecated yet, the use of GLSL is what is recommended for modern shader applications, and is more convenient since it is used directly and does not require NVIDIA's Cg compiler to be invoked first.

 

Although GLSL should enjoy mature support from any modern graphics driver, this should of course be tested. @Greebo -- will you have any time to do some testing on the Windows environment? It will be necessary to define the RADIANT_USE_GLSL macro at compile-time in order to use the GLSL shaders, and if all goes well the result should look pretty much identical to the old ARB shaders. If there are no problems, we can switch over to GLSL as default on all platforms, keeping the old shaders only as a fallback.

[greebo]

Ok, I'll try to do some tests in the coming week. Good work anyways.

[greebo]

I just compiled a Win32 build on my work machine with RADIANT_USE_GLSL defined, and everything worked so far (incl. lighting mode).

 

This machine is a quite new Dell with an NVIDIA Quadro NVS 160M, so I think it's more on the modern side as far as the OpenGL support is concerned.

[OrbWeaver]

That's good so far, I have an ATI 4850 on Linux so between us we have tested both platforms and both major GPU vendors. Also, the ATI Linux driver is well-known to be shit, so if anything has dodgy GLSL support I would expect it to be on my setup.

 

I've realised that the GLSL shader doesn't add the vertex colour, but this will be a trivial 1-line fix, I just need to test it.

[AluminumHaste]

Just compiling the latest source with the GLSL enabled on Win32 and noticed this in the output window:

 

42>..\..\radiant\render\OpenGLRenderSystem.cpp(243) : warning C4800: 'const GLboolean' : forcing value to bool 'true' or 'false' (performance warning)

 

And that's about the only warning that I found.

[OrbWeaver]

Problems with the GLSL shaders are unlikely to appear during compilation, it is during application startup (when the GLSL code is actually compiled by the graphics driver) and of course the rendering itself that would be affected.

[greebo]

That's just a VC++ warning about GBOOLEAN used as bool value. The GBOOLEAN is a typedef'd int, that's why VC++ is complaining, I think. (I just hate those stupid typedefs for trivial built-in language types.)

[OrbWeaver]

(I just hate those stupid typedefs for trivial built-in language types.)

 

To be fair, GL is a C API and C does not have a bool type (probably later version do, e.g. C99, but not the version GL was standardised against). I will fix this warning in any case, since the type conversion might not be portable.

[greebo]

Wait, C had no bools? Didn't know that, must have slipped by me - that somehow makes more sense then, but I still don't like it. We should've used gtkmm from the start, but it's probably too late now.

[OrbWeaver]

We should've used gtkmm from the start, but it's probably too late now.

 

Note that this is an OpenGL/GLEW function, not GTK or GLib (although with so many G's it's easy to get confused).

 

You're correct though, GTKmm would be a much better choice than our home-grown wrappers, but converting the application would obviously be a mammoth task.

[greebo]

On a topic-related note: how's your status regarding the renderer? Are you through with the first phase or are you still in the middle of it? I'm asking because it might be time for another release in the near future.

 

(Also, I've been noticing that many models (e.g. the zombie) have a "shader not found" in DR, which were working fine before, but I didn't want to point this out unless you're done with your changes.)

[OrbWeaver]

On a topic-related note: how's your status regarding the renderer? Are you through with the first phase or are you still in the middle of it? I'm asking because it might be time for another release in the near future.

 

I'm not in the middle of any changes at the moment, the next task is to refactor the renderer to group by light, so that fog, blend and ambient light shaders can be implemented, but I haven't started on this so it would be a good point for a release.

 

(Also, I've been noticing that many models (e.g. the zombie) have a "shader not found" in DR, which were working fine before, but I didn't want to point this out unless you're done with your changes.)

 

That sounds like a bug, which I will have to investigate. This should probably be fixed before release.

[AluminumHaste]

(Also, I've been noticing that many models (e.g. the zombie) have a "shader not found" in DR, which were working fine before, but I didn't want to point this out unless you're done with your changes.)

 

I'm having that issue also, but pretty much every model is showing up with Shader Not Found.

[OrbWeaver]

Confirmed, there is a bug whereby the diffusemap is not used for an editor image if there is no qer_editorimage line. I've fixed this for simple diffusemap lines (it was just a typo), but I have to add extra code in case the diffusemap is inside a proper material stage with { }.

 

EDIT: Fixed for the entire stage as well.

[AluminumHaste]

Awesome thanks . I will download the source and recompile tonight when I get to work. I love working on the weekends, it's so dead.

 

Also I noticed that some models are completely broken. For example the bathtub in waterworks, it's materials refer to marble_white_shiney, but the path doesn't exist. It looks like someone re-organized the textures for the mod.