How to reduce R_speeds in large map Created 17 years ago2007-09-25 09:42:00 UTC by Kill_the_Bug

Hi - working on a large outdoor map and so far I'm getting large and random r_speeds. I'm sratching my head on this one.

Any ideas how I can bring them down? texture is at 2 setting. Can you place skybox texture inside skybox - would this help?

or does this also work - place the item that divides sector A and sector B 1 space above the floor that way it doesn't intersect it reducing them.
Map layout is something like an hour glass. Flows to a choke and opens outagain - really rough pic below - lol.
_____________
| |

/

/

-- --
/
/
| |
____________

Some thing you can do to reduce r_speeds:
? Apply NULL-texture to unseen brush-faces.
? Tie complex geometry like cylinders into func_wall.

If you're a bit more advanced mapper you can also make use of Hint-brushes.

I don't really understand what you said about sky-texture.

I always get high R_Speeds even on small maps, no matter what methods I try.
(and what is the null texture? I've seen it on a lot of forums but I don't understand what it is)

When you apply the NULL texture to a face, the engine will not render that face, and it'll save wpolies. Best applied to faces the player never get to see. To get the NULL texture, download the latest ZHLT (3.4). You'll find a wad file named zhlt.wad, the NULL texture, plus some others like ORIGIN, CLIP, SKIP, AAATRIGGER. Simply load this wad in Hammer and always wadinclude this wad with each map.

I read somewhere in the posts here that if you group items together(if they are already joined somehere) and then compile the parts that are joined get ignored and only the visbilbe faces get rebdered - it this correct? Will it alos cut down on r_speeds?

Sorry buggy for not answering sooner... I tried posting this comment like a week ago, but lost the message and got all PO and didn't write back.

Grouped Items
Yeah... I wrote about that topic, and I'll go into a little more detail about what I mean.
-- If you have a grouped object of world type, the VIS compiler will split it up like any other world type wall / object.
-- If you have a grouped object of entity type, the VIS compiler will NOT split it up, but it will render that object as 1 whole piece. Meaning... If you hare in a large 10-floor stairwell and you're at the very bottom, and you made your rails one solid entity object, you will render the entire rail object whenever it is visible.
If it was a world type, the VIS would hide certain parts you cannot see... but because it's one large entity, you see it all.
... In short... it's easy to move the object as a whole, and since it's an entity you THINK it won't split your map up further because it touches other world objects. This is all true... but you'll see the whole thing.

You CAN make every piece of the railling individual entity objects... but you can only have ~300 individual entity OBJECTS on the map (both grouped / ungrouped).

In this case, it is best to make your rails all world type and lift the base from the ground 1-unit up instead.

As for your map and keeping the W_Poly count low for users and the CHOKE on the server lower... you can do the following:

-- Make cliffs on your map and divide it into larger outside rooms. Use the sky texture to reach from the top sky plane to the top of your cliffs to box it all off. This will reduce unneeded w_poly counts like if you made really high cliffs.

-- Make your outside cliff and ground texture higher size ratio, like 2x or 3x larger than original size. Gives you larger texture blocks to keep w_poly count lower.

-- If you have boxes and stuff, first TRY to lift them off the ground 1-unit and keep them world type. If you must... make the entities, but keep this in mind:
world objects have no "extra" hidden parameters, so they don't send much data over the server.
entity objects have many hidden parameters, and for each individual entity you have... multiply that number by how many parapeter they have AND add your texture count for those faces.
...Yeah... I don't think I need to tell you how large that number can be.
That is why my early noob_32fighter & noob_playground maps have so much CHOKE and lag / crash the server, because most of those objects on the map are entities...

OK cool Noober!

--edit-- (still adding...)

-- Make use of the HINT brush as much as possible. They have to be world type and touch the surfaces you want to split apart. You can FORCE the VIS compiler to split your map up in certain ways to further reduce poly counts in certain areas...
BE CAREFUL, depending on where you are on the map and how the other walls on the map are placed... you could be doing nothing but ADDING more poly count to your map!
It is vital you remember the old poly count / split areas (use gl_wirefram 2 in ONE player mode to see the grid lines) and compare them to the new version.

-- If you have hallways, deep ditches, etc. it is best to HINT those areas. Even if you are outside in a trench maze, it is best to make them individual rooms. This will only work if you are IN the trenches, but it might be worth it.
I've implemented this concept in my new noob_32fither_v2 map. It added like 40-60 new poly count overall when you are above the trench areas or in the tower... but I reduced the visible poly count IN those areas by 3x.
>>> If you do this method... compare and contrast the old and new versions when you do this. Sometimes it's higher performance... sometimes it's worse. This is pure Trial and Error.

Example:
You have a hill with a wall in the middle. Make the area from the wall to the top several HINT zones so that people below the wall cannot see those zones. The HINT brush cannot go higher than the wall's top part, and it must NOT be visible anywhere else for it to work. If you see any part of the HINT brush within a certain range / distance, it will not work.
However... you may be adding more poly count for the TOP people, because they see everything, including the HINT cut zones.

-- Hope all this helps somewhat Buggy.
-- If you have further questions or need diagrams / pictures, I'll be happy to post them when I get back home.

I feel like i'm playing The Legend of Zelda when I read you're posts.

ROFL, are you talking about my posts Rimrook?
And why does it feel like you're playing LoZ when you read them?

Oh yeah, buggy... about the NULL textures.

It's actually good practice to make ALL of your objects starting out with the NULL texture, then apply the specific sides with the necessary textures. This not only keeps you from going back and checking every single side, but in the event you make them ENTITY, all sides will be rendered if it's not a NULL side.

Little more about VIS and texture splitting...

Lets say you place a solid world box in the middle of a 1-texture floor.
I think you already know the final result will give you 4-8 texture blocks on your floor (not including 5 texture faces from box).

This is the same for GROUPED Entity type objects.
A good example is an elevator with buttons and lights. Because it's one solid func_train entity, wherever you place the button/light on the wall, it will split your elevator walls at those points.
In short... entities as ONE solid group will behave the same as solid world objects... to some extent.
(good idea to keep this in mind)

rimrook said:I feel like i'm playing The Legend of Zelda when I read you're posts.

:S

Don't you get it :S Zelda often highlighted words of importance in red with a slight boldness.

Hey! Listen!

lol really? I don't remember that.

ROFL, now that you mention it, I do remember the stuff being bold and italic. It's been ages since I played that game, so I didn't notice it that quickly.

Hey! Listen!

AHHHH! It's in my head!

Bonus points to World Crafter for working in a Zelda reference.

i hated that fairy

You're a fairy. And I hate you.

A good way to cut r_speeds is to do a full vis compile with a low max node size. If you use a Batch Compiler, these options are easy to turn on and off. (The one I use is Nem's Batch Compiler)

Node sizes are nodes for vis that help load and unload sections of your map. The more nodes the more detailed vis data. Don't be fooled that it will slow down you're map's performance by having more nodes. The more detail, the more of only what you see will be loaded, otherwise in the past, maps loaded in larger sections, resulting in more r_speeds being drawn.

Why does it always come down to people hating fairies - no wonder your fairy godmother never grants your wishes!

Thanks for the Node thing - have no clue what you're talking about but it sounded good.

If I put my map into the problem maps folder - how's the best way for me to do it?

Should I just make the entire thing 1 texture and let you guys add in your own? What format you want .map or .rmf?