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. 

A terrain generator simply allows us to build large outdoor areas in a more intuitive and user friendly way than "create 5000 triangles; then start using vertex manipulation..."

Even thinking of that makes me sick. Something like this looks like a really good idea at this point:

http://www.youtube.com/watch?v=FckhbVHqeoA 

It exists. Rather old mac-only commandline tool. http://quake.chaoticbox.com/

I'd offer my tech support for Mac RMQ but I know zero about coding and compiling. 

Whilst working on my own maps scale rather than detail has become the main thing that I enjoy, which is a shame because of how poor the engine is for it. I really like the feeling of the world you're in being huge, and that the part you are exploring is only a piece of a giant world (even if you never *actually* get to it), a feeling that I got from Necro's latest map and that fantastic mountain range.

So I was wondering who else would think that a great edition to a new Quake map format (or whatever is involved to make it work) would be 3D sky boxes. Preferably something like Half-Life 2's where the skybox is scaled up to allow a smaller area to appear massive. 

 

try putting Q3A maps in dpmod, and run them in dpmod using darkplaces and "deathmatch 7". You sort of get a dmsp experience with this setting, but playing in all those gorgeous Q3A maps. 

 

Engine developments aside, I've taken on board some of the discussion over my past few func visits and yeah, the immersion is better when you're a speck in a large world, making your way through one part.

It can lose the focus a bit though, for Quake. 

http://spawnhost.wordpress.com/2011/08/03/rmq-episode-1-status-review/ 

You seriously calling a map Necrophilia? :p