The engine isn't intended as a general purpose Quake engine. It's purpose is to run RMQ content and to act as a sample implementation of engine changes needed for RMQ content. The longer term intention is that the RMQ engine will become obsolete.

With that in mind, issues relating to general purpose usage of the engine (especially with other maps and mods) are quite low priority, and the recommended solution is normally going to be something like "use another engine".

All the same though, I'll check it out and see why it's crashing as it may be relevant for RMQ. 

I just tend to use it to play everything to get the decent FPS.

Fastvis is now good enough - even not vising doesn't take that much of a hit performance wise. 

i struggle to use anything else now. it's essentially quakespasm with coloured dynamic lights, contrast slider, better performance and higher limits. just the contrast alone made it hard switching back to QS for rubicon2 (it was metl's first map that crashed for me)

another map crashed it the other day too, forgot what it was though. 

Something to do with particles, apparently. I'm looking at the diff and I don't understand it, though... 

Careful with this - I know most people these days have multicore cpus and geforce 8 bajillions, but crucially, not everybody does. Quake's beauty is that it still runs well on "that old POS collecting dust in the closet." 

Well the key point here is that high-end hardware is not actually a requirement. The renderer has been completely restructured to allow for more efficient geometry processing (look up GPU batching on Google sometime). In fact in some cases fast vis may even be faster than full vis as the BSP tree can be simpler (traversing it can be a huge CPU bottleneck).

This can be a bit counter-intuitive because you have to throw out everything you know about how the Quake engine works and what it's good or bad at. wpoly counts become more or less irrelevant, wide open and complex scenes are no longer a problem, heavy dynamic lighting comes almost free of charge, and so on. 

I run my maps on a non-gaming laptop that overheats pretty quickly with even fitzquake due to the C/GPU usage.

Most of the original Quake architecture is based on you having a crappy PC, or is just completely outdated in terms of software (as Mh says).

Its why a monster pc that doesn't have any problems with, say, Crysis, has problems with some of the bigger Q1 custom maps even though you're looking at a fraction of the poly counts, texture quantities and texture sizes. 

It doesn't matter if you have a good or bad system to run the engine on - it'll still be incredibly slick. 

Gotta also remember that Quake's original software design was based around a software renderer running on an MS_DOS machine with a p60 and 8 MB of RAM. That was then crudely ported to run on $25,000 OpenGL workstation cards, and then crudely ported again to run on first generation 3DFX cards through a Glide wrapper.

So a lot of the design decisions made back then either don't work well (immediate mode), don't work at all (gl_ztrick) or are just plain dangerous (writing to the front buffer) on more modern GPUs (and by that I mean any consumer-level hardware from about 1999 or so that has a full native OpenGL driver). 

I would argue though that not fullvising a map is very unprofessional. 

 

and watch how many polygons are rendered on a flat surface for no reason at all except that the map compilers were meant for DOSQuake and WinQuake and cut up surfaces into a billion pieces. 

and cut up surfaces into a billion pieces.

i've been wondering if it's possible to make this any better... you spend ages doing your trisouping and then qbsp doesn't seem to actually care and cuts it up worse than if you had just carved everything out of a cube. :( 

That nowadays you should be able to bypass bsp altogether. Put all level geometry into VBOs and render those in one go. Just look at the triangle throughput that modern GFX cards have. It's so high that you can easily just render your entire Quake map and still be fast. And if that doesn't work, you could implement some simple culling, but you wouldn't need a BSP anymore I think. 

You still need the BSP tree for stuff other than rendering. The server uses it for clipping, movement, tracelines, positioning entities in the world, and so on. Really though only nodes and leafs (and clipnodes) are needed for that, and the surfaces can be easily omitted.

I believe that Half Life 2 stores the original map brushes in it's BSP and uses those for rendering, so it can avoid all of the ultra-heavy tesselation that QBSP does. This would be a great feature for any hypothetical extended BSP format. 

Those are areas of the engine that I'm not familiar with, so I was talking only about the renderer. 

being that I'm on a ppc mac laptop with a Radeon 9700m. So I have not personally experienced its dramatic efficiency. However, mh, what you are claiming is most impressive and exciting.

Am I understanding correctly that the rmq renderer is more efficient than vis at culling unseen surfaces?

I looked at that batching stuff and it went a bit over my head. But from a mappers perspective,

wpoly counts become more or less irrelevant, wide open and complex scenes are no longer a problem, heavy dynamic lighting comes almost free of charge, and so on.

Is all I really care about, don't really need to know the nitty-gritty. 

The main obstacle when it comes to Mac RMQ is that none of us has a Mac. I could try installing a virtual OSX machine, if that's even possible, but I'm busy :-P

Mac compiling help would probably be welcome. Just to see what happens. It's hard to fix Mac problems without a Mac though. 

Bloody things are so annoyingly expensive. Easily the most annoying thing about trying to make iphone stuff :p

Well, that and having an iphone too... 

BTW...

wide open and complex scenes are no longer a problem

And with that, terrain generator programs start looking pretty attractive all of a sudden.

If only terrain in Quake was more interesting. I'd love to be able to blend terrain textures for example... or simply import .obj terrain and have that loaded in the engine.

Terragen2Quake.

Only then it would be even less "Quakey". Sounds almost (argh!) modern. 

Would be cool. Re-build engine, monsters and weapon system from scratch with modern engine, AKA that Doom mod from a while back......

Nah - but a terraingen tool would be soo cool and make mapping faster for me :) 

 

The most practical use so far is culling on func_wall, and the removal of the entity flicker bug.

Basically, I'm building box rooms, and then decorating the fuck out of them with a single func_wall each.

In theory I can combine multiple func_walls into one.

A recent compile went from 12 minutes vis to 43 - I realised I'd left a single object collection as brushwork instead of wall. 

Am I understanding correctly that the rmq renderer is more efficient than vis at culling unseen surfaces?

It's actually the case that performance of the renderer is far less impacted on by those extra surfaces. They're still there and they still go through, but they don't slow things down even nearly as much as a more traditional setup. 

Just because you can doesn't mean you should...