New members map

[orange]

Hi all

first let me say what a great forum this is, ive been reading for a few months now after finding it by accident while searching for maps for my server, great forum

recently i decided to venture into the world of q2 mapping.
having played with quark for a short while i had a go at my first map, which turned out quite well i think.

but for my second map i got a little too adventurous and it grew and grew.
having spent alot of hours building the d**n thing, ive now come to the point of finishing it, but with a problem i hope someone can help with...

yes, my map lags

the map itself is big, and you can see right across it from certain parts. having done so much work i was hoping someone could help me by giving suggestions in reducing the rspeeds and general lag

i have used the detail flag on almost everything
i have given everything a 1 unit gap so the textures arent broken up in showtris

the rspeeds dropped slightly, but not enough to make it playable online. any help would be great coz i dont wanna waste the work i put into it

heres the link to my map

www.savefile.com/files/7744054

i hope someone can help
and grats again for a great forum


Orange

[Wixen1 [Q2C]]

Hello Orange and welcome to the Café.

Real big but very nice map, i like it
Cool smooth lights, and good for at least 24 players or more..

I see what you meen about the r_speeds and Iam allmost sure that Grieve can help you in this matter.

Wixen1

[grieve[Q2C]]

hi and welcome to the Cafe, orange ( funny nick)

your map is really interesting ..... and BIG !
I think there are some ways to improve performance.

the main problem of the map, despite the excessive polycount, is it's openness.
the engine does not see the same as you, in fact the engine "looks" around the next 2 or 3 corners and renders the scenery there.
in your map it is extreme, because there is no vis-blocking at all. in most places of your map the game engine "sees" the whole map at once.

this shot, showing the r_speeds and gl_showtris, makes it obvious :



btw, the talk is always about "r_speeds", but this term is misleading. it is not really about speeds, it is the reverse factor of the rendering speed: it tells you the number of world polygons the engine has to render.

I will call it furthermore rather polycount than r_speeds.

well, in your map you don't have many details ( polygons) in the perimeter with its small halls and corridors, they are concentrated in the middle section.
unfortunately, because of the lack of any "shield" which blocks the engines view, it "sees" this detail-intensive middle section all the time. the Quake 2 engine is not optimized for a polycount that high and is chocking because of that, causing the miserable performance.
if the view to the cooling tower in the middle would be blocked, you would rather have a polycount (r_speeds) between 150 and 400 in the peripheral halls and corridors, instead between 2000 and 3800 !!

so blocking the view would be the first task to do, before starting to optimize the middle tower section with polygon-reducing tricks.

there are mainly 2 possiblities: donut doorways or doors with func_areaportals in the corridors. I'd say doors will fit better for this type of map.

you may have a look at this RUST tutorial which covers the subject ....

www.gamedesign.net/node/53

[grieve[Q2C]]

hmm, and this is about the func_areaportal entity and how to use it. there are (still) other tutorials on the web. googling might bring up some results.

files.volved.com/qsr/qoole250_cd/rust/tutorials/15/15.html

doom-ed.com/john-carmack/new-culling-mechanism-for-quake-2.html

www.gamedesign.net/node/242


of course there is much more to tell about this, but this is a good place start.

[orange]

hi grieve, thx for the reply

yeah i tried adding a door in each of the 4 coloured corridors, added a square func_door with a square areaportal inside (also tried making it 1 unit bigger), each door had a target of 1 to 4, and each areaportal a targetname to match each door, ie door 1 has an areaportal of targetname 1.
but for some reason the rspeeds only seems to drop by 1

i made a small test map to see if i was doing it right, made a small room with a door right in the centre, filled the far end with small cubes and the rspeeds went from 200 to 10 each time the door closed, when i did the same in on my map, the rspeeds just didnt seem to drop and i couldnt figure out why, so i removed the doors


on a side note, the map is very open because the mod i play is kots2000 which is like an RPG for quake2, in which you can upgrade fly, the map is that size and has that much room so some players can fly about and rail someone in the top of the head lol


Orange

[grieve[Q2C]]

hmmmm, weellll .....

but Orange, you shouldn't be too fast with dumping the idea of areaportals.
I mean, you want to make your map lag free and playable, don't you ?

A Quake 2 map with a polycount around 3000 will be by no means playable lagfree online. The dated netcode can't handle this, regardless how high end the used machines are or the connection.

It IS a rather old game, and if you want to map for it you have to accept it's restrictions.

If the portals didn't work, there must have been some errors in the construction. And there are many possible errors to make.
Why did you let the portal brush only overlay 1 unit ? Just make it as big as possible. But of course you know that no entity may touch the void, or it will be a leak.
And the brush for the area portal must really touch BOTH bordering areas.
My guess is that there were most likely gaps in the surrounding construction of the door and the walls which it was embedded in. The smallest gap, even smaller than 1 unit, will make the engine "look through"

(Microgaps are also a very likely cause of lighting anomalies, btw.)

I would imply that you check the construction of doors with areportals again. This is a basic step to make your map playable. There WAS something wrong, and if you look you will finally find it.

You should also use the gl_showtris command to check your map. It shows you much more than only r_speeds, it shows you exactly WHAT polygons the engine currently renders, and WHERE they are. The map becomes transparent, and you see what the engine "sees"

It works only with OpenGL rendering. If you use the standard ref_gl.dll which belongs to quake2.exe version 3.20, you will have to disable the multitexturing extension before you use it.

that is:

gl_ext_multitexture 0

gl_showtris 1

then you will see the map the same way as in the screenshot I posted above, and you will get much more information out of it.

[Wixen1 [Q2C]]

grieve said:

hmmmm, weellll .....

but Orange, you shouldn't be too fast with dumping the idea of areaportals.
I mean, you want to make your map lag free and playable, don't you ?

A Quake 2 map with a polycount around 3000 will be by no means playable lagfree online. The dated netcode can't handle this, regardless how high end the used machines are or the connection.

It IS a rather old game, and if you want to map for it you have to accept it's restrictions.

If the portals didn't work, there must have been some errors in the construction. And there are many possible errors to make.
Why did you let the portal brush only overlay 1 unit ? Just make it as big as possible. But of course you know that no entity may touch the void, or it will be a leak.
And the brush for the area portal must really touch BOTH bordering areas.
My guess is that there were most likely gaps in the surrounding construction of the door and the walls which it was embedded in. The smallest gap, even smaller than 1 unit, will make the engine "look through"

(Microgaps are also a very likely cause of lighting anomalies, btw.)

I would imply that you check the construction of doors with areportals again. This is a basic step to make your map playable. There WAS something wrong, and if you look you will finally find it.

You should also use the gl_showtris command to check your map. It shows you much more than only r_speeds, it shows you exactly WHAT polygons the engine currently renders, and WHERE they are. The map becomes transparent, and you see what the engine "sees"

It works only with OpenGL rendering. If you use the standard ref_gl.dll which belongs to quake2.exe version 3.20, you will have to disable the multitexturing extension before you use it.

that is:

gl_ext_multitexture 0

gl_showtris 1

then you will see the map the same way as in the screenshot I posted above, and you will get much more information out of it.

THATS IT!!!
I will not ever try to map...thx. Grieve, I now feel as old as Iam....

Wixen1...

Wow..man Iam behind, until my pension, then il return..(Cos tiiime,,, time is on my side... !!)

[grieve[Q2C]]

LOL, Wixen !!

so we have to wait like 20 years for your next map ?
it better be good then, to justify the long wait .....

;D

[orange]

hi again

yeah i know areaportals are a much needed thing, i wasnt dismissing them i just couldnt figure out what i was doing wrong so removed the doors. and the 1 unit bigger thing, in one of the areaportal tutorials they suggest making it 1 unit bigger than the funcdoor to make sure there is no problems, but i might have took that wrong.

but now i think i know where i was going wrong. the area portal was acutally touching the void, i added a square portal to a 6 sided corridor (the coloured ones) and enlarged it so it would cover the whole width, which means all 4 corners of the portal were in the void, why i get chance ill have another try, hopefully that will be one thing solved