Bug 22743

Seems it fails the max_index check in drawrangeelements when rendering player models. 

e.g:

Mesa warning: glDraw[Range]Elements(start 0, end 126, count 240, type 0x1403, indices=(nil))
        index=126 is out of bounds (max=125)  Element Buffer 85 (size 480)

Mesa warning: glDraw[Range]Elements(start 6, end 1495, count 5130, type 0x1403, indices=0xfad0ac4)
        index=1495 is out of bounds (max=1494)  Element Buffer 0 (size 0)

You can try if commenting out the return statement in this check or
inside the game using gldrawelements fixes it (open console shift->ESC type: gl_mesh_drawrangeelements 0).

This is a nexuiz bug and should be fixed there (if it isn't already, I didn't test latest version). Note that nexuiz doesn't actually use that index which is one too large, it's just the end value to the DrawRangeElements call which is wrong.
(Though, I'm not actually really sure it's against the spec to use a end value which is larger than what the bound arrays can provide and larger than the largest index value as it's a mere hint that no larger indices will be used but doesn't indicate that the end index value will be used itself - but anyway the app certainly didn't want to use that value.)

(In reply to comment #2)
> This is a nexuiz bug and should be fixed there (if it isn't already, I didn't
> test latest version). Note that nexuiz doesn't actually use that index which is
> one too large, it's just the end value to the DrawRangeElements call which is
> wrong.

I tried also nexuiz 2.5.1 with current mesa but the bug is still here (my weapons are visible but not enemy models).

> You can try
> inside the game using gldrawelements fixes it (open console shift->ESC type:
> gl_mesh_drawrangeelements 0).

This works indeed!

I've committed an update to the darkplaces svn to use -1 bias on the end vertex, my understanding of the word "end" is that it is one past the "last", so this mix-up was inevitable, I am careful to use the words first and last as parameter names when this is the intended usage.

However it is also interesting that other drivers do render in this case.

P.S. I am the primary author of the engine.

(In reply to comment #5)
> I've committed an update to the darkplaces svn to use -1 bias on the end

I confirm that using the svn version of darkplaces engine this problem is no longer reproducible.

Thanks!

> However it is also interesting that other drivers do render in this case.

There is someone with same problem on Windows:
http://alientrap.org/forum/viewtopic.php?p=62297#62297

Mass version move, cvs -> git

*** Bug 23471 has been marked as a duplicate of this bug. ***

I fixed this by disabling Vertex Buffer Objects in the game video settings.

(In reply to comment #10)
> I fixed this by disabling Vertex Buffer Objects in the game video settings.
> 

It should be fixed in nexuiz 2.5.2, FYI (but I didn't test it).

I'm on latest intel with a X3100 graphics:
OpenGL renderer string: Mesa DRI Intel(R) 965GM GEM 20090712 2009Q2 RC3
OpenGL version string: 2.1 Mesa 7.6

. gl_mesh_drawrangeelements 0 does NOT work for me
. Vertex Buffer Objects : "Disable" or "Vertices" fixes the problem. Default "Vertices some Tris (compatible" does NOT fix the problem.
. present in Nexuiz 2.5.1 and 2.5.2
. Mesa 7.5 fixes the problem as well

Is this a different issue then or the same and has been fixed in latest svn, but didn't make it into 2.5.2?

*** Bug 24471 has been marked as a duplicate of this bug. ***

> Is this a different issue then or the same and has been fixed in latest svn,
> but didn't make it into 2.5.2?

I built an updated nexuiz intel 32 bit binary just after the fix, which you can get here:
http://rapidshare.com/files/269056184/nexuiz.html

It fixed the problem here. Can you try it?

I tried it although on x86_64 platform.

Results are:

. Fabio's built still has artifacts and doesn't render characters, nor weapons. But walls are textured now, whilst 2.5.1/2.5.2 some walls were black, when enabling Vertex Buffer Objects for vertices and triangles.

. Fabio's built CAN'T be fixed by turning off Vertex Buffer Object usage.

If I'm facing a slightly different bug, then I think I can't tell whether it's a Mesa regression (7.5 works) or the game using Mesa in an unsupported way.

If it is a regression it is not necessarily the same one, it could be a shader compile error or other silent problems.

Please provide a log of running the game with these extra commandline options:
-developer -condebug +gl_paranoid 1

This should produce a log named ~/.nexuiz/data/qconsole.log containing many details of how the renderer is operating, and if any GL errors were reported.


Options that may tickle the bug (use in any combination you like and see if they fix it):
-notexturenonpoweroftwo        (disables use of non-power-of-two texture sizes)
-novbo                         (disables use of GL_ARB_vertex_buffer_object)
-nocva                         (disables use of GL_EXT_compiled_vertex_array)
+gl_mesh_testmanualfeeding 1   (causes game to use glVertex and friends instead of glDrawRangeElements, slow)
+gl_mesh_testarrayelement 1    (causes game to use glArrayElement instead of glDrawRangeElements, slow)
+gl_mesh_drawrangeelements 0   (causes game to use glDrawElements instead of glDrawRangeElements)

There are other options that might be involved but those are the likely suspects.

Options that will almost certainly make things appear, but will perform poorly:
-nofragmentshader              (disables use of GLSL shaders)
-safe                          (uses OpenGL 1.1 API only, no extensions)

You may also want to try different Effects presets in the options menu to see if you can tickle the bug and isolate the causal relationships.

Created attachment 30342 [details]
nexuiz 2.5.2 ~/.nexuiz/data/qconsole.log taken after a "rm -rf ~/.nexuiz" with current r300 master driver when run with "-developer -condebug +gl_paranoid 1 -safe"

I would add two things:

* with current r300 driver the original problem is no longer reproducible, even on the old, bugger nexuiz version;

* when running with -safe option, i.e.:
./nexuiz-linux-686-sdl -developer -condebug +gl_paranoid 1 -safe
the problem appears again, tested with both old nexuiz and 2.5.2 binary downloaded from nexuiz web site. I'll attach the qconsole.log, apparently something is wrong since I see many lines like:
R_Mesh_Draw: invalid vertex index 0 (outside range 264 - 504) in element3s array

Created attachment 30375 [details]
X3100 vbo_off

Created attachment 30376 [details]
X3100 vbo_vertices

Created attachment 30377 [details]
X3100 vbo_vertices_some_tris

Here some test results for intel GM965 (GMA X3100).

As previously stated Vertex Buffer Objects : "Disable"|"Vertices" fixes the problem for me. What results in corrupted display (some walls transparent, no enemies, no weapons) is the setting "Vertices some Tris (compatible)".

Using Nexuiz 2.5.2 everything an default and "Vertices some Tris (compatible)" enabled with the various command line options:

No fix:
-------
-notexturenonpoweroftwo
-nocva
+gl_mesh_drawrangeelements 0
-nofragmentshader

transparent walls fixed, but still no weapons, no enemies:
----------------------------------------------------------
-novbo

fixed:
------
-safe but lots of messages:
R_Mesh_Draw: invalid vertex index 0 (outside range 2226 - 2230) in element3s array
+gl_mesh_testmanualfeeding 1

app crash:
----------
+gl_mesh_testarrayelement 1 with message:
nexuiz-linux-x86_64-glx: main/api_arrayelt.c:1316: _ae_invalidate_state: Assertion `!actx->mapped_vbos' failed.

---

I attach the qconsole.logs. They were obtained from:
./nexuiz-linux-glx.sh -nosound -developer -condebug +gl_paranoid 1
with the three vbo settings [off|vertices|vertices+some tris].

There's nothing special in those logs. All contain
^7scripts/common.shader parsing warning: unknown surfaceparm "skip"
^7scripts/common.shader parsing warning: unknown surfaceparm "skip"
which can't be the cause, since it works in vbo setting [off|vertices].

The log from vbo_vertices_some_tris.log, which causes visual bugs, is not different in it's critical parts from the one vbo_verticles, which does NOT.

Thanks to the reports of R_Mesh_Draw warnings I have identified a problem when GL_ARB_vertex_buffer_object is not detected (such as in -safe mode), it was not initializing the ushort triangle data on models, causing them to disappear, which can be avoided with the setting gl_mesh_prefer_short_elements 0.

However this does not explain any bugs when GL_ARB_vertex_buffer_object is supported.

(In reply to comment #21)
> +gl_mesh_testarrayelement 1 with message:
> nexuiz-linux-x86_64-glx: main/api_arrayelt.c:1316: _ae_invalidate_state:
> Assertion `!actx->mapped_vbos' failed.

This is an interesting restriction (although logical) - glArrayElement does not support vertex arrays inside buffer objects?

I may have to force off vertex buffers when the debugging setting gl_mesh_testarrayelement 1 is used, although this is of limited interest to most people.

I should note the ushort triangles bug mentioned in my previous comment was introduced in revision 8252 of DarkPlaces svn on 2008-04-10, quite a sleeper bug.

(In reply to comment #22)
> Thanks to the reports of R_Mesh_Draw warnings I have identified a problem when
> GL_ARB_vertex_buffer_object is not detected (such as in -safe mode), it was not
> initializing the ushort triangle data on models, causing them to disappear,
> which can be avoided with the setting gl_mesh_prefer_short_elements 0.

OK, darkplaces r9337 works fine with my RV530 even with -safe option. Apparently also "+gl_mesh_testarrayelement 1" works fine here. Maybe it's only an intel driver problem.

Please be more specific - what bugs remain with the current darkplaces svn on Intel graphics?

(In reply to comment #25)
> Please be more specific - what bugs remain with the current darkplaces svn on
> Intel graphics?
> 

Ah, OK, I was referring to the "nexuiz-linux-x86_64-glx: main/api_arrayelt.c:1316: _ae_invalidate_state: Assertion `!actx->mapped_vbos' failed." problem, that is indeed fixed.

It wasn't clear to me that it was fixed in darkplaces and I thougth it was only an intel problem. However the "Assertion failed" also appeared with old nexuiz also on my RV530 and I confirm it's fixed with 9337.

> Please be more specific - what bugs remain with the current darkplaces svn on
> Intel graphics?

The nightly builds are no longer available, are they?
http://www.nexuizninjaz.com/forum/Thread-FAQ-Where-can-I-download-nightly-builds-of-Nexuiz.html

If I understand correct there is no issue with missing enemies, walls, weapons on RV530 with current Nexuiz 2.5.2 and setting VBO "Vertices some Tris (compatible)". At least this seems to be an intel-only issue.

I am willing to test a couple of things, but right now I don't want to bisect Mesa 7.5 -> 7.6 regression regarding this issue to find the commit.

> The nightly builds are no longer available, are they?
> http://www.nexuizninjaz.com/forum/Thread-FAQ-Where-can-I-download-nightly-builds-of-Nexuiz.html

This is my 32 bit compile of latest 9337 svn revision:
http://rapidshare.com/files/293285850/nexuiz.binario-svn-9337.html

So you are confirming that all issues related to this are gone with the darkplaces svn?

I think this bug is solved then...  Although I do find it interesting that 7.6 would not be reporting VBO but 7.5 did.

(In reply to comment #23)
> (In reply to comment #21)
> > +gl_mesh_testarrayelement 1 with message:
> > nexuiz-linux-x86_64-glx: main/api_arrayelt.c:1316: _ae_invalidate_state:
> > Assertion `!actx->mapped_vbos' failed.
> 
> This is an interesting restriction (although logical) - glArrayElement does not
> support vertex arrays inside buffer objects?

Could you explain what you mean by this?  Parts of this discussion are difficult to follow.  It should be valid to use glArrayElement to source vertex data from a buffer object.

The following code should work fine.  If not, then there's definitely a bug.

    glBindBuffer(GL_ARRAY_BUFFER);
    glVertexAttribPointer(0, ...);
    glEnableVertexAttribArray(0);

    glBegin(GL_TRIANGLES);
    glArrayElement(0);
    glArrayElement(1);
    glArrayElement(2);
    glEnd();

I will reopen #24471 once it turns out that it's not a duplicate of this (closed) one. That will make this bug report here more readable.

I did download Fabio's svn 9337 build. I fixes my problem. All enemies, weapons, walls are there, but it's ridiculous slow. Like 1 fps.

So I went ahead, grabbed svn 9337 sources, build a x86_64 compile (make nexuiz) and launched it. I was surprised that the display was again corrupted despite the fact that Fabio's 32-Bit version worked.

I tried all the switches again with the following results, which are indeed different to the ones I got from the 2.5.2 build:

No fix:
-------
-notexturenonpoweroftwo
-nocva
+gl_mesh_drawrangeelements 0
-nofragmentshader

fixed:
------
-safe
-novbo
+gl_mesh_testmanualfeeding 1
+gl_mesh_testarrayelement 1

> I did download Fabio's svn 9337 build. I fixes my problem. All enemies,
> weapons, walls are there, but it's ridiculous slow. Like 1 fps.

Are you using latest libdrm? There were some issue with mixed 64-32 bit with old libdrm:
http://cgit.freedesktop.org/mesa/drm/commit/?id=cdd325b59a17a614b90fc2f8b388175e6d79e3cf

9337 works fine here even when using "Vertices some Tris (compatible)", which however is the default, and when using:
-notexturenonpoweroftwo
-nocva
+gl_mesh_drawrangeelements 0
-nofragmentshader

> Are you using latest libdrm?

Yes I am on libdrm 2.4.14, which includes the fix you pointed to. However this fix doesn't apply to me anyway: I'm on intel X3100 graphics and using the intel drm bits not the radeon ones.

> 9337 works fine here even when using "Vertices some Tris (compatible)", which
> however is the default, and when using:

This makes it very clear:
radeon - no issues
intel x3100 - rendering issues

> -notexturenonpoweroftwo
> -nocva
> +gl_mesh_drawrangeelements 0
> -nofragmentshader

Just to be clear: I only used one switch at a time not all together. And my graphics rendering isses are present even without any switches and default Nexuiz settings.

Thanks Fabio, Forest and Ian. I'm about to reopen the bug in mesa i965 component again.

I probably won't bisect at the moment since I assume that's a pain: mesa depends on libdrm and the kernel drm bits. Bisecting back to much older revisions may also mean to downgrade libdrm and the kernel.

Just for reference, we've got a downstream report of this in Fedora bugzilla:

https://bugzilla.redhat.com/show_bug.cgi?id=533759

actually, sorry, that's for the Intel case, which is 24471.