Drawing brush models with the world

[Baker]

In Engine X, I have the option r_brushmodels_with_world and it will render .... (speeds up things maybe 1%, not significant).

1) World submodels (lifts, platforms) but not health boxes.
2) With origin x, y, z = 0
3) With angles x, y, z = 0
4) Provided it doesn't have alpha (solid surface)

What is a good plan to draw the world submodels where the angles and origin are modified?

This being OpenGL 1.2 +/- so fixed pipeline of course.

Am I better off using glRotatef and glTranslatef during the drawing of texture chains and then restoring the modelview matrix back when it runs into surfaces belonging to a world submodel? (This should get complex. I don't know if anyone ever instances world submodels or if that is even possible --- I bet the lighting would potentially look stupid. But really a surface doesn't have a way to know which entity it represents.) Maybe throw the alpha surfaces into the liquids texture chain.

But really, I'm thinking I shouldn't do this at all. Why draw the world submodels in the same function as the world unless it is easy? There is no specific benefit.

Part 2: I think I've heard of MH say he once threw the unchanging static part of the whole map into a vertex array. How does that work with a ton oi potential textures? I'm no master of vertex arrays, but I thought those got paired up with arrays of texture coordinates (not multiple textures). The lightmaps can change, but I guess that is really is a texture update.

Why the hell am I asking this? RMQ engine does this and it uses ancient OpenGL with a ton of extensions.

I could scrap this post, but maybe somehow someone might somehow benefit from reading it.

-----------------

I might add that the RMQ Engine occasionally stalls for a second every once in a great while for me on 2 different laptops (Windows 7 one, a Mac one). Maybe when a lot of dynamic lighting changes happen ??? <---- those question marks mean I do NOT really know why. Both are ATI.

I guess I think the rendering code really could be a lot simpler. And I'm thinking supporting non-multitexture in a desktop engine (or a mobile one --- even OpenGL ES 1.x is required to have multitexture) is something I'm not doing any more (why waste that time for computers that literally don't even exist. That one Steam hardware survey said 2 TMU is 100%)

Not a very coherent or well themed post. Drifting around a bit. I know. I'm thinking of what I hate about the rendering code and why it stands between me and what I am trying to get done.

[taniwha]

[Spike]

glLoadMatrix should be faster than glPopMatrix. not by much though.
glLoadMatrix should be faster than glMultMatrix. much of that is because you can cache the modelview matrix with glLoadMatrix.

changing uniforms will hurt about as much as a texture change (actually less if you're running out of graphics ram... which you won't be).
so changing your matricies mid-batch will give no improvement, so make sure you're not randomly hopping between 500 different ents drawing only one surface at a time.

personally I hate the idea that a surface might be drawn differently purely because its a submodel.
polygonoffset is annoying, and fte's defaults indeed bugged out on at least one android device...
special cases like disabling culling or whatever is just ugly. I want a world entity with alpha 0.5!
Realistically though, you can skip a load of bells and whistles if you do special-case it, but if you're using multitexture in one place, you should have it in the other two. it can make maintainence annoying, which is the real issue. take caustics for instance. love them or hate them, if they don't affect bsp models but do affect world then you have some real weirdness going on.
the real kicker is that this applies to entities too.

older hardware supports only one tmu, but such hardware has eg limited blending modes and do not fully support opengl anyway. which makes then misbehave in everything recent, even if they have the number crunching power for an enjoyable game. really the only reason I would personally care is because a) limitations make things more fun. b) leileilol loves running stuff at low framerates and with dodgy blend modes.

[mh]

I gave up on single TMU cards a long long time ago - the limitations were just too much. Yeah it's sometimes fun to come up with creative solutions, but most of the time I found myself fighting against them and writing multiple versions of code that did the same thing. I'd much rather be productive.

For brush model entities I merge them into the world texture chains in the following conditions:
- Origin is 0|0|0.
- Angles is 0|0|0.
- The model is only being used by a single entity.
- The model name begins with '*'.
- The entity has no alpha.
- ent->frame is 0 (important otherwise you won't get alternate anims!!!).

In theory Quake allows '*' models to share surfaces with the world, and more than one entity to share the same '*' model - there's nothing in GLQuake to prevent it (don't know about software). In practice I don't think I've ever seen it happen, but that's not to say that there isn't a version of QBSP out there doing it.

The merge is just a standard surf->texturechain = surf->texinfo->texture->texturechain thing for each surf that will be drawn in the entity, and is run after R_RecursiveWorldNode but before the world and other brush model entities are drawn - if an entity was merged then it doesn't get drawn in the regular pass. In terms of performance it gives no measurable difference whatsoever in standard id1 maps (fluctuating conditions on your PC will have bigger impact) but may help with maps that use a lot of e.g. func_wall entities.

Beware that standard texture chaining (like the example I gave above) will give you back-to-front ordering, which is going to result in high overdraw. You need to either reverse the chain before drawing, or add new surfaces to the end of the chain instead of the front of it during building.

For standard brush model entities (that don't meet the above conditions) things are a bit more familiar. Load a matrix, loop through the surfaces, add them to texture chains (again based on ent->model), draw chains, clear chains when done, repeat for the next entity. If matrix loading is a bottleneck then you're doing something wrong...

There's potential value to be had in drawing brush models before the world rather than after it, as brush models are more likely to occlude world geometry than be occluded by it, and that will get you early-Z optimizations on most gfx cards (I got good results in the same manner by drawing the view model as the first item in the frame).

Any complexity in the RMQ engine is on account of it's FitzQuake heritage and it's reliance on ancient OpenGL. In the FitzQuake case the original code for handling brush models was (IMO and to be brutally honest) a quite horrendous mess - a correct horrendous mess perhaps, but a horrendous mess all the same. In the case of ancient OpenGL it imposes restrictions that mean you need to go through a coupla extra levels of sorting and other nastiness in order to get things batching up well. Overall there's an extremely high level of frustration involved in it. Code derived directly from GLQuake that does this, and that isn't afraid to jump the hardware requirements a little bit forward, can be a LOT simpler. DirectQ pushes all surfs through the same texture chain setup and drawing routines, bases texture chains on ent->model rather than cl.worldmodel (and takes ent as a param to it's drawing functions) so there's a high level of consistency between all surface types. It's main surface drawing function is 24 lines long, including braces, comments and whitespace.

Ideally you'd just put all brush model surfaces into a single big static VBO, build indexes dynamically for the surfaces you're actually going to draw, use a single glDrawElements (or equivalent) to draw each texture chain, and use shaders for animating water and sky. This also needs texture arrays to avoid texture changes (and consequent batch breaking) for lightmaps, glMapBufferRange to get decent dynamic VBO performance (for indexes), 32-bit indexes in hardware for large maps, and at least 3 TMUs for single-pass diffuse/lightmap/fullbright (in practice if you have the other requirements you won't have less than 8). That's the current fastest path on any reasonably civilized hardware and is also much much cleaner and simpler in terms of code than any other approach.

[Spike]

mh, I find it funny that you advocate using texture arrays for lightmaps, but not world surfaces.
using it for textures *and* lightmaps would mean that you can fully depth sort in advance. and bsps give nice depth sorting. yes, you'll still have issues if you somehow (bsp2?) have a map with >65k verts, but hey...

glMapBufferRange is a problematic one. mapping a buffer is quite a slow operation, with all sorts of system calls and syncronisation issues. index buffers are often software-based. If you're going to use it, you want to map a buffer for *all* batches rather than just one, to avoid making lots and lots of map/unmap calls.
For D3D, FTE maps buffers on a per-batch basis. DO NOT DO THIS, it really kills the D3D renderer's performance, and should have a similar result with gl (at least d3d has a proper 'I'm not gonna break anything' flag, paired with a 'I'm gonna break everything' flag for easy reuse, but even with those it still plummets). With gl, I generally get away with just calling glDrawRangeElements lots in a loop. I'm probably ought to try and investigate glMultiDrawElements, but from what I've seen its only the function call overhead that's saved, and that's just userland overhead (unlike with d3d where it would be syscall overhead).

Even if you do have over 65k verts, you can still use a single vbo. Just use different vbo offsets.
Some of the rmq maps exceed 65k verts with a single texture.

Regarding gles - you'll spend more time rewriting the input code to get the thing usable than you'll spend tweeking the renderer to be gles compatible. I wouldn't really worry about gles1. gles2 is more worthy of concern

[Baker]

[mh]

[taniwha]

Uh, I thought brush models don't support frames.

[mh]

[mh]

[Baker]

[taniwha]

[taniwha]