Render Mode Is Broken [open]

[OrbWeaver]

Lighting render mode does not work, a black screen is displayed. Both Windows and Linux. Possible problem with the normal map handling code (addnormals etc.).

[OrbWeaver]

Progress update: Preliminary investigation showed that the GLProgram pointer was NULL in Renderables_Flush(), so that the shaders were not even being used. I am currently in the middle of refactoring some of the renderstate code, so that this problem can be more easily examined -- which is unfortunately a rather difficult task as this render code is some of the worst I have ever seen by way of interdependency and entanglement (class methods which call C functions which set global static variables which are used by other class methods on a different class...).

[sparhawk]

Sounds like fun. I was once working on a project which was equally strange. The C code dynamically created (even nested) DOS batchfiles, which in turn was calling the application again with different parameters in order to trigger some function. And all written in a very "creative" way. It was a nightmare to debug.

[greebo]

Interesting... why would this pointer be NULL now when it wasn't before?

 

However, looks like there aren't a lot of areas left that we haven't touched by now .

[OrbWeaver]

I have a feeling the GLProgram is set from the material, so if the material parsing is broken it might not select a correct program.

 

Next up: move the GLPrograms into a factory class rather than having stupid static globals for each one.

 

Incidentally, I am doing all of this in a separate branch, meaning that I can commit intermediate changes that won't build or work, without breaking the main tree. This is very useful for large or experimental sets of changes, such as refactoring.

[OrbWeaver]

The renderstate refactor is now merged into trunk. The rendering bug is still not fixed, but at least the code is slightly more understandable now that it has been partially separated into classes.

[OrbWeaver]

It seems I was wrong - it is not the GLProgram which is set incorrectly, it is the RendererLight. WHen the OpenGLStateBucket is populated with transformed renderables, it seems that the m_light pointer is always 0, leading to a black render.

 

I need to investigate how these lights are populated.

[OrbWeaver]

Further investigation shows that the light is not always NULL, just a lot of the time (which may be correct). After adding an operator<< for RendererLight, I can see that the correct light is being passed through with the correct dimensions and colour.

[OrbWeaver]

Finally, some progress. Observations:

 

1. The attenuation_z parameter should be bound to a texture -- if the light shader does not specify a texture this is looked up from the default lightshader. This is in fact always bound to 0, which may be what is causing the black display.

2. There are TWO defaultlight shaders in the Light Inspector - lights/defaultpointlight and lights/defaultPointLight. The lowercase version comes from the .game file via ShaderCache_Construct() in renderstate.cpp, while the mixed case version seems to be hardcoded in Light_Construct() in the entity plugin. Only the lowercase version shows correctly in the light inspector, which suggests that the existence of the mixed case version (with its blank falloff images) is causing the problem.

3. Changing the name of the mixed-case version in light.cpp shows that this is the one being used, NOT the one populated from the .game file.

[OrbWeaver]

This is now fixed at last. The problem was in the shaders::MapExpression class I added during the (partial) shader plugin refactor, which was failing to process "makeintensity" which is used in a lot of light shaders for the Z falloff image. I have added in a console error that is emitted if a light shader defines an invalid Z falloff, which should pick up this kind of issue in future.

 

Unfortunately however, I think we are going to need to look at the renderer performance sooner than planned -- trying to view mansion_alpha in lighting mode uses up all my memory, takes about 30 seconds to display and then runs at about 1 fps. I will raise a defect for this.

[greebo]

Congrats! This was kind of tough or at least tiresome I guess.

 

Are there any other issues left that have to be resolved before 0.8.0?

[OrbWeaver]

Congrats! This was kind of tough or at least tiresome I guess.

 

Yes, it is difficult to debug render problems because all you have is a black screen, a very large number of possible causes (missing geometry, missing lighting, incorrect culling, bad shaders, bad GL calls, bad textures etc), and no easy way of debugging the process other than adding loads of print statements.

 

Are there any other issues left that have to be resolved before 0.8.0?

 

No, I think this is all we need for 0.8.0, touch wood.

[greebo]

Namespace is planning to upgrade the renderer, isn't he? I know that the new render system won't be finished tomorrow, but wouldn't it be redundant to look into this if the render is to be reorganised anyway?

[OrbWeaver]

Namespace is planning to upgrade the renderer, isn't he? I know that the new render system won't be finished tomorrow, but wouldn't it be redundant to look into this if the render is to be reorganised anyway?

 

Not necessarily. It might be possible to implement some of his ideas and produce an immediate gain, even before the whole redesign is complete. It would certainly be worth doing some basic profiling to see where the main problems were occuring, for example it could be that the scene graph or culling code is implemented very inefficiently, or certain operations are performed more frequently than necessary. Just getting rid of the 30 second delay when render mode is first activated would be a good step forwards.