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... 

 

i did that exact thing in that blue coloured ruins map i posted shots of. i had detail brushes that were interchangeable so i'd just put in the appropriate ones and leave them all seperate.

i ran out of vertices doing this and i had to go back and combine all func_walls in one room together so the compiler could start to cut out vertices and such.

you can be sloppy and leave your func_walls seperate in a small map, but once you get to a certain size, you'll need to go around optimizing again. :(

that said, i'm not sure i'd be entirely against making some kind of new bsp format which allows a much larger amount of vertices, clipnodes and such. i know that the new limit imposed by metl's original fitzquake of 65536 vertices cannot be broken without changing the map format. 

There are plenty of reasons in a traditional Quake engine to not do this, including the fact that traditional Quake engines will choke on rendering so many brush models. The RMQ engine does not choke on brush models. Like I said - throw out your current understanding of what the renderer is good or bad at, because it's no longer valid.

Reasons that remain include having them count against MAX_MODELS, having them count against MAX_EDICTS, and having to have physics run on them on the server.

Reasons in favour include accelerating visibility calculations and producing a much simpler BSP tree (which gives perf gains elsewhere too).

Look on this as an intermediate step. The longer term plan to take those func_wall entities, merge them back into the world, convert them to detail brushes and produce a BSP that draws them as part of the worldmodel. The func_wall'ing of entities is just step one along the way to that, and has the bonus that it will still work even if the longer term plan doesn't work out so good. 

The 65536 vertex limit is one that's already been hit in an RMQ map - even without any func_wall'ing.

The most obvious solution is to take the standard BSP 29 spec, convert some of the data from unsigned short to unsigned int, and produce a new BSP format that doesn't have those limits. It would have the bonus of keeping the map format identical to before, but would require tools work as well as engine work to support it, and would obviously need buy-in from outside of the RMQ team. 

It's definitely intended that innovations made during the creation of Remake Quake should benefit everybody.

It makes sense to look at what other people need or want. Because we got quite a bit of dev power in one spot here, and there is a bit of networking going on as well. That gives us a bit of leverage to do "uncommon things".

I guess if an extended BSP format (ie limits removed, "detail brushes") would be used outside of RMQ, that'd be all the better. Then we might as well do it right (TM).

Terrain generator not Quake: I dunno, I think it remains to be seen. :-E 

Ultimately all that a terrain generator would do is build standard brushes to put into the same standard .map file to be processed by QBSP/etc in the standard way; no different from any map editor in other words.

One must always remember that unless explicitly stated, any talk of new stuff should always be read as if "...and it will work just the same way with standard tools" was appended to the end.