CSGO Map Compiling/Beginner Questions

[NihiL]

Thanks for the ideas so far. @3Dnj: Are you saying I should compile my maps FAST VIS? That's the first time I've EVER heard that so allow me to ask for other opinions on this? As for the decals, they are certainly normal decals:

That's an example of a flickering decal. Any further ideas?

@FireWarp: I have, it doesn't make any difference  

@laminutederire: I'm aware of how important optimization is, I was asking my question because I used to get good in-game performance with VIS that took long, as expected, and now for no apparent reason it goes by much quicker during compilation (like 10x faster but not instant like actual FAST VIS) and I get way worse in-game performance (ie. FPS). And that's what puzzles me as I didn't do much except add a couple more func_details.

 

Thanks for the input so far, again. Do let me know if there are more ideas you guys have, I'll also continue to investigate.

Edited June 18, 2015 by NihiL

[laminutederire]

@NihiL

Check those func_detail then  func_detail are very powerful you know, many times have I gained 5 or 10 minutes of compiling just by func_detailling some stairs I forgot about

however, are fps drops only appearing near these particular brushes?

[FireWarp]

@NihiL

Did you change any of your skyboxes? I had the exact same problem but the steps I told you about fixed that for me.

Edited June 18, 2015 by FireWarp

[Michael Greenwood]

When designing the layout for my map, I've been using grids of size 2 or 4. A tutorial I saw recommended using snap on grid with a minimum size of 8 for initial layout. Is there any truth to this?

[Vorontsov]

@Michael Greenwood it doesn't matter because it's all about preference, but 8 is the best for initial layout

[cashed]

I use 16 for my initial layouts, and 8 for typical walls that lie within game space. I actually never get into anything lower unless I'm doing detail.

[Michael Greenwood]

I'm most concerned about textures. I can't find the optimal ratios I should be using to best tile the textures cleanly. Currently I have everything snapped to 4, but you are saying doing it to 16 is better?

[cashed]

I wouldn't worry too much about texture snapping atm. I "zero" mine out all the time which is "0.25" This is standard for hl2. Now since csgo's "HR" for de_train; the default is "0.125"

Use dev textures to get scales correct.

[NihiL]

 @laminutederire I don't think you understood my problem? vis is compiling too fast, not too slow. It's suspiciously fast and ingame it seems like it did 'a bad job'. I didn't change much about the map at all. Don't want to sound too aggressive, it sounds like you misunderstood my issue tho!

@FireWarp I haven't changed my skybox at all unfortunately. I've even gone ahead and changed it now (brought the ceiling down as far as possible) just to see and it doens't change anything.

So right now I optimized my map to have pretty much exactly 3k portals and vis takes a blazing 4 minutes only. Way too fast surely? On full settings with the slowest preset in Expert mode? No errors in the compile log (should I post that, would anybody look at it?) and map is optimized with func_details and nodraw but no hints/skips yet.

If anybody has any additional ideas or anything please let me know. This is kinda ruining my map when it used to be just fine optimization-wise, very frustrating because, again, I didn't really change much except add some func_details.

Edited June 24, 2015 by NihiL

[Michael Greenwood]

Sorry, I dont understand what "zeroing" a texture means. I get that textures at 0.25 make a 512x512 texture apply to a 128x128unit area, but what does that mean for my map making? Areas should be built with 128x128 blocks?

[NihiL]

In general, your walls should be 128 units high but that's a 'baseline' if you will. When actually greyboxing I wouldn't obsess over that kinda stuff too much. Put the brushes down the way they feel right, then adjust later for the texture that you choose. That's the way I do it anyways.

Edited June 24, 2015 by NihiL

[cashed]

Sorry, I dont understand what "zeroing" a texture means. I get that textures at 0.25 make a 512x512 texture apply to a 128x128unit area, but what does that mean for my map making? Areas should be built with 128x128 blocks?

If you type "0" in to the scale it autos to .25. Just quicker than typing it out

[laminutederire]

 @laminutederire I don't think you understood my problem? vis is compiling too fast, not too slow. It's suspiciously fast and ingame it seems like it did 'a bad job'. I didn't change much about the map at all. Don't want to sound too aggressive, it sounds like you misunderstood my issue tho!

I understood, I said that because sometimes a non-optimal optimization make the compiler to be weird and it leads to compiling too fast because it overlooks things, which it thinks they are too complicated, and optimizing can help him figure it out and it can deal with it

Edited June 24, 2015 by laminutederire

[FireWarp]

That's too bad . My only guess would be that hammer is somehow overwriting your custom compilation parameters. To check if that's true, compile vis on fast and compare it with normal settings. What fast compile does is that it actually checks whether or not the visleafs created by vbsp are correct and that's pretty much iit.  Whilst on normal setting vvis performs portal flow correctly, making source cull parts of your map during gameplay. All of this means that fast vvis does pretty much NOTHING. Compiling without vvis shouldn't make any difference

Edited June 24, 2015 by FireWarp

[NihiL]

I understood, I said that because sometimes a non-optimal optimization make the compiler to be weird and it leads to compiling too fast because it overlooks things, which it thinks they are too complicated, and optimizing can help him figure it out and it can deal with it

That's too bad . My only guess would be that hammer is somehow overwriting your custom compilation parameters. To check if that's true, compile vis on fast and compare it with normal settings. What fast compile does is that it actually checks whether or not the visleafs created by vbsp are correct and that's pretty much iit.  Whilst on normal setting vvis performs portal flow correctly, making source cull parts of your map during gameplay. All of this means that fast vvis does pretty much NOTHING. Compiling without vvis shouldn't make any difference

Thanks for the answers! @laminutederire: okay and with optimization you mean hint/skip brushes at this point, right? Because everything else that I'm aware of (nodraw and func_details) I've already done to the map, as I said. @FireWarp: Nah, fast vvis actually is done within less than a second for my map so it's not like Hammer is doing an actual fast vvis when it should do a full vvis. It's somehow not doing the full vvis right apparently...