AverageFreak's mapping questions thread
Hey guys, ive got a newbie problem ive been trying to figure out for a while now. The solution might be really stupid and easy, but i cant see it atm..
when i place a light_env entity in a map, i set the pitch/yaw/roll to, for example 100,100,100. Then i save and leave hammer, and when im back, yaw is still 100, but pitch and roll have resetted.
(Ive noticed the "Pitch and roll do not work yet." sentence in Properties, but it doesnt ever seem to change, and it has an arrow pointing at roll, which doesnt help me much)
Also, when i compile, even if i use completely different numbers for the pitch/yaw/roll, the light ingame is the same - has the same color as indicated in hammer, but no source and it seems as if the entire map is in a shadow.
It's because roll doesn't work and therefore will be reseted.
You can set yaw in "Pitch Yaw Roll" property and pitch in "Pitch" property (use pitch yaw roll property only for setting yaw).
problem fixed, it seems it had something to do with the fgd, anyway remake your tips did help me :> thx
Ehm, i dont wanna start a new thread over these questions, so ill ask them here:
1. For example, I create a sky. 6 solids, 36 faces (lol skybox). Will it matter if i nulled 30 of those 36 faces, and left only those visible 6? will it decrease fps/r speeds?
2. Will it matter if the sky texture was scaled to 15x15 instead of the default 1x1, and the null texture for that matter? It theoretically removes a lot of patches. I suppose not, but im asking anyway :D
3. Does skyboxing affect r_speeds and fps in a VERY negative way? I'd say yes, but again, asking anyway. Could the difference be +-1000 wpoly? The reason behind this particular question is, that i want to add a certain depth to the map im making - i need unreachable through normal means objects (for example a solid city skyline far outside of the map, and for that, i will need a skybox). The same map, during the last check, had peaks of !2700! wpoly and ~1500 epoly.
4. Does func_walling improve the performance of the map (lower r_speeds)?
5. If i replaced all light point entities with texture lighting, will it help reduce them speeds?
More questions might arise xD
13/02/2010 12:571. I don't think that the SKY texture will increase the r_speeds - it doesn't create texture patches like normal textures does. Therefore it shouldn't matter if you null it or not.
2. Again, it doesn't create texture patches like normal textures, so this doesn't matter.
3. I'm not sure what you mean here, but skyboxes really puts VIS on a test, it has to render pretty much everything when you make a big box around the map, so don't use it unless it's necessary somehow. You need to elaborate this question, 'cause I didn't really get it. :P
4. Yes, it does, as func_wall's (or just any entity) doesn't "split" the ground's faces like world brushes does. Lets say you have a crate standing on a floor. If it's a world brush, it will cut the floor into several texture patches, creating higher r_speeds. If it's a func_wall, the floor will not get any additional texture patches.
5. From ZHLT: Texture light faces are chopped with a different granularity than the normal faces, primarily so that the lighting looks good. - The quality of the textures is increased when you use texture lights. I don't know if it will decrease the r_speeds, but it probably won't make the map run better when you use texlights.
Also:
Adding -extra to HLRAD will automatically divide the chop value by 2 at runtime.
-chop #
Set radiosity patch size for normal textures.
Each face in the world has a grid projected onto it, and chopped up into a rather coarse set of sample points. These points are patches, and are what HLRAD uses to do the bounced lighting calculations. A higher chop sacrifices quality for both speed and memory consumption of HLRAD. A lower chop increases the quality at the expense of speed and memory usage.
zhlt.info is really useful for these kind of questions, be sure to check it out.
Thanks for the answers. About 3: what i wanted to ask was whether i would get much higher wpoly values when i used skybox (like in space maps). I'll try and make it more clear later if needed, gtg outside now :D
/edit thread renamed, so i can re-use in the future :D
Well, my map came up with another problem for me to ask... it seems visblocking just doesn't work, or r_speeds are completely bugged. in a completely enclosed hallway with a maximum of 30-40 possible wpolys, about 1800 are rendered. No walls/floors/anything that makes up the outside of the hallway are func_wall or any other entity. Even if i stand in the lowest possible place in the map and look straight down, no less than 1500 wpolys are rendered (this works on statueofliberty, where i got a count of 2 wpoly while standing on the edge of the map and looking horizontally into the sky). I have long since removed the skybox too. If anyone has any idea how to fix this problem, you are very welcome to tell me D:
/EEEDIT i think i figured it out... i had a single func_wall entity with ~800 objects in it, it seems whenever i saw even the smallest bit from an object in this entity, all the objects are rendered, sending r_speeds to insane levels : x ... however this is just a theory, compiling now in order to test that out..
16/02/2010 15:37800 objects? Oh my god :O
Dude, I would highly recommend that you split that into like 80 func_walls. I think your theory about this is right.
Also, if you get these VIS problems, try and compile with -full - you might get some doubtful results with -fast or just normal sometimes.
16/02/2010 16:16I suggest splitting them where needed. Look for objects that are close to each other.
Theory correct :D divided it into about 80-100 new FWs, wpoly goes over 1000 only in the outdoor area :>
Another reason for the people who do not single func_wall huge amounts of stuff to avoid doing so. :D i just got convinced too xD
About -full - im compiling with it by default. Thanks a lot for the help people :)
16/02/2010 22:48(edited 16/02/2010 22:51)I prefer not to group brushes into one func_wall if their size (width/height) goes over 200-300 units (in gruop), because otherwise it often causes its polygons "drawing" pretty far away in unwanted places (trough sky or walls).
but there is no strict rules or conditions for this, so the best would be map testing with gl_wireframe 2 to check if some unwanted polygons are seen somewhere or divided in a bad way. this option is good for finding weak places for further optimization.
16/02/2010 23:09But remember that gl_wireframe 2 works only in single player, a.k.a. deathmatch 0.
I found more crap to ask about xD
Supposingly i want to add a model to the map. entity cycler, i select my model, compiling... and when i run the map, cs always crashes and says "model not found in cstrike/models/whateverfolder (whether i added another one), even though it is in the exact same place as stated in the error (triplechecked!). Same thing with sprites.
23/02/2010 12:28Originally posted by AverageFreakI found more crap to ask about xD
Supposingly i want to add a model to the map. entity cycler, i select my model, compiling... and when i run the map, cs always crashes and says "model not found in cstrike/models/whateverfolder (whether i added another one), even though it is in the exact same place as stated in the error (triplechecked!). Same thing with sprites.
It says that because you dont have model in right place
1) Make sure you're using cycler_sprite and not cycler.
2) Make sure that the path to model is models/folder/model.mdl and not cstrike/models/folder/model.mdl.
3) Make sure that the mod directory (Settings - Game Configurations) is set to cstrike folder.
Please log in to post replies.