i think with my last maps, i tried to keep stuff under 5k. 

Do we really want to push the limits, or keep the old constraints and being stucked into 1996 ??
Come on, it is natural to evolve.. please do the same... doh ! 

What computer and engine did you get low fps in? Maybe some gfx card or engine settings can help you. 

if you still get low fps in Quake these days, even with those r_speeds, you need to upgrade mate! :) 

I never go below 77 fps in quakeworld. I have a p3 500 with geforce4 mx. Sure, I accept some lag in big maps. But it just sucks when it's there for no good reason.

Well, whatever, maybe someone can make you a d3->quake map converter that turns the bumpmaps into bsp details and you can vis it for a year on a beowulf cluster and release to the awe-gaping community. R speeds 100k.

The quake engine was not meant for big detailed areas. The long vis times are one clear indication of that. Another is the gameplay. Q1 doesn't have detail brushes and whatnot. I really shouldn't need to explain this. Doing big detailed areas in quake 1 is like milking a horse. It's not meant to be that way.

There's a balance in going "beyond 1996". Go to 2001 or so in r_speeds. If you want to go further, use other engines and map formats?

Why even vis your maps then JPL, if it takes weeks, if you don't care about performance? Castle of dark ages was unplayable for me, but the spacebase map was good and I liked it.

This is of course all my layman opinion.
Please, think of the computing cycles. 

Why even vis your maps then JPL, if it takes weeks, if you don't care about performance?

Why ? Because it is more than unplayable even with a high performance PC.. Only aguirRe's engine would have been able to play unvised CDA...

Actually, my target was (and is always) FitzQuake: it must support the level without warnings/errors, and it is not a question of PC performance only IMHO...

I doubt many of us are still playing with WinQuake... or even original Quake engine... though...

Anyway, I think "old PC" and "old engine" have to be "archived"... and please let the humanity evolve to higher performance materials.... ;P 

Darkplaces and FTE can load q3 maps which should have less problems with size, and vis really fast afaik. Probably works with better fps too. Although the support is probably buggy as hell, but that will never be remedied if nobody starts using the features.
And some shader things are not there. 

My old PII with crappier specs than that loaded and played CZG97 and Necros' maps without any refresh rate problems.

As for what mappers should be doing that isn't really worth discussing because limitations in size also effect decisions in design, and that is unacceptable.

I'm looking forward to the day when the tools allow us to build big festering Quake cities. 

A future generation will put CZG on ice in a hightech, Illumanati subbasement and force him to produce maps with just his mind. 

If a machine was built to create structures based solely on czg's thought processes, all we'd get would be lots of kittens and giant willies. 

"limitations in size also effect decisions in design, and that is unacceptable."

So design should never be limited by the engine? You're mapping for the wrong game, mate. 

So design should never be limited by the engine?

That is a bit of a dodge on your part because you are advocating limiting map design to the requirements of outdated machinary, not what is possible given engine design and current hardware.

Binary partitions are not an effecient means of rendering terrain scaled areas but if someone wants to build an octree based renderer that processes bsp maps no one is stopping them, and as Carmack has stated the means of rendering is becoming irrelevant as hardware advances are being made.

You're mapping for the wrong game, mate.

I know of noone who shares your opinion of keeping maps and tech at 1997 among fellow Quake fetishist. It is bit of a puzzle to me where your mindset is coming from (years of living under Communism, maybe?). If I became destitute and could not afford to keep up beyond the 2006 mapping scene in the upcoming years, I would not expect mappers and programmers to keep churning out product to please me.

In fact, in 2002, I did not have a system that could play UT 2003, it was a bit of a pisser but that was their decision to develop as they pleased (though I did tell Wolf Marshall the Unreal 2 sucked and he wrote back that Epic did not develop it).

The design of Quake was modular from the beginning, and the code was released by Id to encourage further development as an extension of that modularity, so who is really out of sync here? 

I would not expect mappers and programmers to keep churning out product to please me.

you to read Atlas Shrugged sometime. Noone has to map. 

Well, if quake was some octree based thing that supported big maps in a proper way, it'd be fine, but it's not.

czg07 btw, It's probably done in proper czg style and thus has good fps all along. Terra is a very good example of excellent maps with low system requirements. They don't take years to vis either.

The bsp and vis specs and algorithms haven't really changed since 1997 and you're advocating for using them for 2006 "modern maps"? Well, do port the doom 3 architechture to q1 then. There has to be a limit even for you somewhere?
Modular quake etc... well, if there would be a new renderer and new compile tools, then it'd be fine. There aren't. Except q3 format. Why not map for it?

Living under communism. I chuckle. Probably every other country but USA is deeply communist from someone's point of view. My country is as communist now as it was 20 years ago. It was an ad hominem attack anyway.


The point here is we're actually arguing what is sensible and prudent, approrpriate and moderate. Aristoteles kinda things, it's a hard problem everywhere.
I say r_speeds below 3000, (and often it'd be good if maps stayed below 1000, especially if the rooms are small and undetailed) what's your number?

It's maybe visionary but it's half lazy too to put lots of complex geometry in open areas.

The original inspiration to talking relates to somehow seeing "classic modern maps" reviewed and seeing terra, adamantine cruelty and egypt on the same page and thinking how much easier it was to do egypt than the others since it doesn't care about r_speeds that much, so I thought it must be noted explicitly.

I laud mappers making small r_speeds maps! 

Marcher was cool and it was playable with my system, it somewhat lagged in some places. It was a concept map and the concept really could not have been done in any other way. (It was way faster in fitz than in aguirre btw!)
Headthump, I see that your project from qexpo really pushes some boundaries. I wish it well and hope it vises in finite time. Maybe if it was in some other engine, such problems wouldn't exist.

But it really pains me seeing good-quality maps but nothing huge, and them having huge r speeds mostly because of lack of caring. Maps that needn't necessarily have huge r speeds but they still have. 

that would mean an intention of insult. The circumstances of one's birth and place are purely accidental. I ask because I really would like to know what drives you to make rather authoritarian pronouncements on how other people should create content.

Why would you feel that it is your edict from on high that r_speeds should be in the 3000 range? Because that feels 'right' on your machine? Nomatter if that was the common recommendation in tutorials from 1999 but doesn't even come close to the capacity of the average machine today? There is a presumptiousness here that I am curious to understand. 

it is higher than 3000, but I have only -fast vised it. An earlier version compiled in 8+ hours but the change from that version is substantial. I got the portal number down to around 22,000+ after they were 31,000 plus so the performance should increase on the next build. Though, I have no problems running around in it, I aim to make it somewhat efficient.

I get this message, MAX_MAP_VISIBILATY exceeded when I attempt to compile it in the Quake 3 Arena format, but AquiRe's and Tyrann's tools compile it without any problems. Undoubtedly, it will take some time fully vis when I am ready to do it. 

I do agree somehow with bambuz that maps should be playable in normal Quake option.
I had the abandon pak first released and it played well in normal quake and the maps were not bigger than a floppy.

Then I took as advice to recompile them again with new compilers and updated quark, and I had a lot of work getting them leak free.
Great to see them in Fitzquake, but I wasn't able anymore to play them in normal quake because of the grey fall outs.

I am a pacifist, but I can't see the relation with mapping. I have a P3 1300 logitec-gForce. 

Then I took as advice to recompile them again with new compilers and updated quark, and I had a lot of work getting them leak free.
Great to see them in Fitzquake, but I wasn't able anymore to play them in normal quake because of the grey fall outs.

this paragraph makes no sense to me. surely recompiling maps in order to get rid of leaks (and therefore make it visable) would reduce (if not totally remove) grey flash in winquake? if anything, you should have gotten grey flash in winquake before you recompiled and fixed it.

did i miss something? 

There is a difference between lazy+inefficient mapping (made easier by better computing power), versus purposely designing complex maps made for contemporary computer systems. The computational expense of the former leads maps to get bad reviews and might crash your pc, while the latter helps the game evolve.

Maybe. 

 

Here's to evolution. 

Tyrann updated his site:

Just a quick update. I was going to put up a booth at QExpo, but I just don't have the energy right now. Anyway, just to get this out there, here is version 0.1 of tyr-utils (and source). This packages together my light and vis utils, as well as bspinfo and the beginnings of a bsputil tool. The version of tyrlite included is unchanged from version 0.99b, but the version of vis has a few tricks added to reduce compile times. I'll update the utils page later to reflect this new packaging. Qbsp will be added later, once I get a clean GPL version done (the TreeQBSP source isn't GPL compatible as far as I can tell, and I haven't been able to contact the author to get it changed).
http://disenchant.net/ 

1)Dont touch communism, or I'm calling Vondur!

2) Bamb, spare ~100$ on a new mobo+sempron 3000+ CPU. Its time to upgrade. Aslo q3 maps in DP will prolly run even slower on your outdated sys 

1) HT, did you make the detailed spire tops as entities/models/whattheyare so that they are not included in vis? In quake1 you can't do that, because then they wouldn't be lighted properly. And thus they have to be in the bsp and fuck up the map. Or well, modern computers can handle the map even when it's fucked up, but that's not beautiful imo. But in more modern engines they can be excluded from bsp splits and vis calcs. That's one point I'm trying to make, quake was not designed for that, while many engines are. You have only the func_wall that's not going far enough.

2) Upgrading my pc is pretty low in the priority list. I hope we'll see it someday though. :)

3) r speeds 3500 was high even in 1999. My computer is about 2000-2001 mid-range.

Making "modern" maps for q1 is a bit like putting a jet engine to a bicycle. Yes, well, it can be done, but we already have motorbikes, cars and aeroplanes which do the job better. It's a curiosity allright. But I recognize you digress and we can just say, "ok, we disagree but we can live with that", I'm fine if we stop this particular part of discussion here. The tech part is interesting though.