stock maps issue involving bad material rendering

[holland01]

A lot of the models and faces being rendered are completely black. This seems to be most likely due to some improper material handling, which I suspect might be due to too much memory being allocated on the GPU.

Currently testing on q3tourney2, but this is also reproducable in q3dm15.

For q3tourney2, attempting to create a program for every shader stage has actually caused more models to render their materials improperly, and the default map pass uses little vertexes for an individual drawSurface either way.

It could be that a lot of these models don't have lightmaps, and as a result choosing to fetch the lightmap in the sampler for the main shader is causing issues.

(Note: the above turned out to be true, however it would be worth making sure that these maps are supposed to have only lightmaps in these areas...)

(Note 2: yes, q3tourney2 does have textures that it should be loading. Since generating each glsl possible glsl shader from the effect shader directory causes a lot of models to render with a black material, it really does seem like this is a memory related issue.)

Another potential cause could involve the texture atlas: q3tourney2 has a max texture width of 256 and a max texture height of 512. If the atlas generation isn't equipped to handle that appropriately, then this is likely the root cause.

If the problem is memory related, replace the program reference in the stage with a handle that points to some underlying storage mechanism, similar to the atlas implementation. This way, programs which have the exact same source generation (or attrib / uniform key and location combos) can be considered duplicates, deleted, and their original handle can be returned without issue.

[holland01]

\ New Major Problem**

Testing the Railgun_Arena on an intel i7 windows 10 produces some really fucked up results. The issue involves different portions of various objects disappearing and reappearing on each camera orientation, in strange places where they shouldn't be doing this.

What's been tried so far:

• disabling face culling
• rendering faces only
• removing effect shader draw routines
• switching to 2.0 legacy profile
• using GL_GEQUAL as a depth test function, with a depth clear value of 0
• (using GL_LEQUAL) changing the depth range to the following parameters: [0.5, 1.0]; [0.0, 0.5] and testing these.
• Seeing if setting the perspective projection matrix has caused any issues
• removing the rendering of transparent faces
• removing ALL shaders except Railgun_Arena from the scripts folder
• disabling patch rendering
• Testing both x86 and x86_64 builds (the x86 build hasn't been completely tested yet, due to a different issue).

Things to try:

• Get the x86 build up and running.

Incidentally, for the first issue that was posted, it seems like the problem with q3tourney2's textures isn't quite due to too much GPU memory being allocated. There is of course nothing certain, however.

[holland01]

The intel driver issue is probably due to the fact that too much GPU memory is being used; there's over 200K indices being allocated in Railgun_Arena, for example. Streaming index data to the GPU as necessary, using glMapBuffer or glBufferSubData, rather than allocating it all at once, is probably the best solution.

(use glMapBuffer if it's available, otherwise fall back to glBufferSubData).

Also try looking for the face (patch, polygon, billboard, whatever) which has the most indices, and attempt to allocate that amount for the element array buffer; this way, we won't have to reallocate anything.

Also be sure to memset the element array buffer to 0 after a draw call, unless it affects performance negatively.

[holland01]

Wound up rewriting some of the draw code code to stream index values if desired, and sure enough what we have is some significant visual improvement. It's still not quite there, however.

Some things to keep in mind:

• if possible, it might be more efficient to still use a bound index buffer which is designed to hold indices for groups of faces. If this could be widdled down to a single draw call (with the appropriate offsets into the buffer recorded/specified), there may be some good magic there.
• the mapPatch_t Generate function allocates a large buffer of triangle count values for N total rows in the patch itself. The problem is that this large buffer consists entirely of values which are all the same. So, we have 2N * sizeof(N[0]) bytes when we should really have (N + 1) * sizeof(N[0]) bytes. Think of a way to make this work both in terms of the nvidia GPU and the intel GPU.
• While the WebGL tests appear to work fine with an index buffer containing more than 200K indices, it could be more memory efficient for the GPU to use a conservatively allocated buffer a well, similar to what is stated in the first item of this list.
• If storing the indices client side, one way to really save on GPU memory is to represent the index buffer as an array of uint8_t. Find the maximum index value, and choose the type of index size that corresponds to it. For example, if the maximum index value is less than 256, we can just pass GL_UNSIGNED_BYTE to glDrawElements, and consider our stride to be 1. If the maximum index value is greater, we simply choose the most appropriate range for the list of indices and pass the appropriate enum to glDrawArrays. It goes without saying that each value in the buffer must have the same stride. Packing and pucking the bytes may or may not be beneficial as well. (In progress)
• Look into image compression formats with OpenGL; it's possible that this could be helpful too.

[holland01]

Update

Driver issue definitely isn't memory related; streaming index data through the GPU has confirmed this. The issue is definitely due to something else, however what that something else is remains uncertain. It would be a good idea to try "random" things like activating the compatibility profile when using GL 3.3, in addition to testing the driver through some other programs.

[holland01]

Intel issue is fixed; the driver for some reason chooses to use a 16-bit depth buffer by default.

[holland01]

Closing. Ideally, it would probably be better to avoid relying on an explicit 24-bit depth buffer allocation on initialization, but that will have to wait for another time...