Problems with cubemaps

Discussion in 'Mapping Questions & Discussion' started by about drew, Sep 19, 2015.

  1. about drew

    about drew L1: Registered

    Messages:
    47
    Positive Ratings:
    6
    A
    Don't judge me, this is my first map. :(

    B
    This is my issue:
    Okay, I attempted to build my cubemaps before the previous Gameday featured my map, and I followed all the instructions in Squit's Thread, but it wouldn't (and still won't) build them for me.

    So I had a little conversation with Mr. worMatty and he suggested that I post my .vmf and .bsp files for the gracious people of TF2Maps.net to have a look-see and help a budding mapist.

    Dropbox Files
    V M F B S P

    C
    I am aware of some issues in the map (listed below). The cubemaps is but one of the rookie mistakes I have made, and it is the one I am currently trying to solve. But I would gladly welcome any and all information on the other issues. I haven't actively searched or attempted to fix them yet, so I could use any info or links if you have time and energy and the grace and the dash, but you'll win yourself a girl if you've only got a mustache.
    NODRAW on Terrain Surface
    Displacement edge problem
    Too many light styles on a face x1000
    Physics [variable] very full
    prop_statics with no collision meshes
     
    Last edited: Sep 19, 2015
  2. iiboharz

    aa iiboharz Meme Queen

    Messages:
    718
    Positive Ratings:
    1,040
    We aren't huge fans of self depreciation around here. No need to be ashamed for being new! But, I've deleted the poll attached to this thread.

    I appreciate you're a new mapper, but putting yourself down like that will do no good. Learn from your mistakes instead of beating yourself up, and I'm sure you'll do just fine here.
     
    • Thanks Thanks x 2
  3. Tumbolisu

    aa Tumbolisu  I ⌄ I 

    Messages:
    949
    Positive Ratings:
    937
    I recommend you to fix the non-cubemap related issues first.
    NODRAW on Terrain Surface
    Displaced faces do not accept the nodraw texture. You have to select these faces and click the "Destroy" button in the displacement tab of the face manipulation window.
    Displacement edge problem
    Not sure what you mean with the displacement edges. If it is what I think, the stuff i just said will fix it as well.
    Too many light styles on a face x1000
    Did you name any light entities?
    Physics [variable] very full
    Don't spam prop_physics I gues.
    prop_statics with no collision meshes
    That's not an issue, it's just some information to make sure you don't oversee it. You can remove the message by selecting the props and changing their solidity to "non-solid" instead of "V-Physics". It is recommended not to use "bounding box".

    Here is a video related to displacements. In fact, it tells you everything about them.
     
    • Thanks Thanks x 1
  4. about drew

    about drew L1: Registered

    Messages:
    47
    Positive Ratings:
    6
    Haha, I saw that edit and I really appreciate that you took the time to make it sound even nicer than it did before.
    I wasn't intending it to be in bad taste, but I suppose I could have just left it out.

    The NODRAW issue: oh! If that's it, then it's probably one of the early displacements I made. I discovered the destroy feature after I made a few displacements, and used it. I guess I just missed one or two.

    The displacement edges are abutted or something. I think they're just intersecting each other, and I need to sew them.

    Yes, I named quite a few of them. Is that bad? Is that all it is?

    I don't even think I've intentionally created any prop_physics entities

    Vphysics: Yepper, I just haven't taken the time to do it today - I just learned of that one this evening.

    Thanks ever so much!
     
  5. Tumbolisu

    aa Tumbolisu  I ⌄ I 

    Messages:
    949
    Positive Ratings:
    937
    I have now taken a look at the map and... dude. Let me tell you something:
    Only name an entitiy if you absolutely have to.
    This has the following reasons:
    1. Saves a bunch of work.
    2. Prevents unintended behavior.
    What is this behavior im talking about? The best example for this are light entities. Naming a light entitiy will instantly make it dynamic. What does that mean? The light from that entitiy will be direct only, meaning it's less realistic. Surfaces hit by one light-name will have their number of lightmaps increased exponentionally. And because of limit reasons, you can only have about 4 different sets of names hit a surface.
    You named every single entitiy in your map, which for the engine means that you are planning on dynamicay disabling these lights, possibly all of them at the same time.
    And now we get to something relating your original problem: Cubemaps.
    When building cubemaps, all dynamic things are hidden. I wouldn't be surprised if the lights get disabled too, which would cause most of your cubemaps to be very very dark.

    Alright, now that this is clear, let's fix some other shit.
    • This: You can't have this prop be a prop_static. The Info tab has only "dynamic" checked, so either use it as a prop_dynamic or not at all. [​IMG]
    • All your func_nobuilds use the clip texture. You are supposed to use the trigger texture however. Also, you don't have to nobuild every ramp. In fact, barely anybody ever does that.
    • Why are your capture area triggers so damn tall? You don't have to be completely inside it to capture, you just need to be touching it.
    • You need to func_detail a lot more. Stairs are a good start, but not enough.
    • Speaking of stairs, I see that they are off-grid. Don't resize a group of brushes. Always make sure it's on grid. The only exception are rotated instances, which won't change anything here.
    • One of your B-sign overlays is Z-fighting, which instantly means that you are using the wrong texture. That texture does not have the tf keyword. Use "signs/sign116b" instead. Same applies to any other flickering overlay.
    • Point A's capture trigger is a 32-sided cylinder. I bet something like 12-sided would have been enough. Don't make things unneccessarily complex.
    • You seem to have done quite a few things on a pretty small grid-size. Is that true? For now the smallest grid size you could possibly need is 8. I personaly like to use 32 anywhere I can.
    • And to finally finish this: You really gotta work on your displacement brushes. The video linked before should help a ton [​IMG]
     
    • Thanks Thanks x 3
    Last edited: Sep 19, 2015
  6. about drew

    about drew L1: Registered

    Messages:
    47
    Positive Ratings:
    6
    Naming objects: I had no idea naming entities behaved like that. Thank you. I never considered looking up a tutorial on naming entities (or if there even is one)

    The barricade: I almost removed it already because I wasn't very attached to it

    func_nobuilds: I actually asked about the ramps before, and didn't feel like I got a clear answer. I also was worried I was creating too much work with it. Thanks for that tip, I will remember that in the future.

    Capture Areas: I don't know why they're so tall, honestly. I didn't think about it that way.
    Point A: I will simplify the shape. That makes so much sense.

    func_detail: I would need to use this on things like my windows and signs and door arches, yes? Just not on the bare bones of the map like walls and floors and ceilings?

    Stairs are off-grid: I am planning on changing the structure of most of the stairs, in fact, so it's good that you said this. I may have just re-done all of them in the wrong way entirely.

    Small grid: I have discovered the hard way that using a small grid is a bad idea. I did a lot of that early on, and I've been trying to line things up to that and it's just been a mess. I figured that's just the way it was (I've seen a lot of people complain about some of Hammer's overall inconvenience).

    Displacements: After watching that video, I can easily name at least 10 places I made some BIG mistakes. (Or maybe just all of the displacements). They're all just overlapping and covering up sad edges. I have my work cut out for me, but I'm actually excited about having something a little cleaner.

    I expect with more knowledge and experience I'll be a bit more efficient about it.
    This one reply has helped me more than I ever hoped. You are a gentleman and a scholar.
    I will be getting to work right away. :D
     
  7. Tumbolisu

    aa Tumbolisu  I ⌄ I 

    Messages:
    949
    Positive Ratings:
    937
    About the func_detail stuff, you would need to read and understand all the stuff on this site to make use of it effectivly: http://www.optimization.interlopers.net/
    But just in case you don't feel like reading this much at once, I'm gonna try to put it in the simpliest and dumbest way I can think off right now:
    If you cant hide an elephant behind it, you should probably func_detail it.
     
    • Thanks Thanks x 2
  8. about drew

    about drew L1: Registered

    Messages:
    47
    Positive Ratings:
    6
    okie dokie! I don't mind reading, I just have trouble concentrating sometimes, so I miss important facts on occasion. Thanks for all your help again. This really has been eye-opening.
     
  9. Pocket

    aa Pocket func_croc

    Messages:
    4,489
    Positive Ratings:
    2,219
    That's a really good way to put it, actually. As a specific example, I like to point out that all three capture point buildings in Gravel Pit are made entirely of func_detail. A because it's full of holes, B because it's full of windows, and C because it's so skinny.
     
    • Thanks Thanks x 2
  10. worMatty

    aa worMatty Repacking Evangelist

    Messages:
    1,072
    Positive Ratings:
    836
    For reference, here are the problems drew listed, but as they appeared in his compile log that he quoted in this thread:
    • NODRAW on terrain surface!
    • Found a displacement edge abutting multiple other edges.
    • Overlay touching too many faces (touching 209, max 64)
      Overlay overlays/patch009 at 922.0 548.0 -280.0
    • WARNING: Too many light styles on a face at (-3484.000000, 2056.000000, 127.000000) [quite a few of these]
    • physics [variable] 4743394/4194304 (113.1%) VERY FULL!
    Hi again, drew.

    Personally, I advise against using func_nobuild to try to shape the way the game is played. It should be used first in places that could be considered exploitative, such as beneath shutter doors, on top of rock models where a spy cannot easily reach them or in a high, unassailable position overlooking a choke. If a sentry position simply proves to be too powerful during the course of testing, then you should look at redesigning the area to balance it out. If an area is routinely accessible by non-jumping classes, then an engineer will expect to be able to build there, especially if it is a good spot for a sentry. More capable and inventive engineers can use sentry jumping to get to high places, and they should be allowed to on occasion, if it doesn't make it extremely difficult for the enemy team to get to the objective.

    Touching on what Tumb said about naming entities: Not only is it more work efficient to leave entities unnamed if they will never be controlled, your entity data lump size will be kept down to reasonable levels. The entity data lump is one of the lumps that makes up a map. Some lumps, and some aspects of a map such as the number of brush faces, have a maximum limit. If you check your compile log, you will see a table telling you how 'full' each lump, or aspect is. That is why we have to be careful when making maps that have a lot of detail and entities, not to exceed the limitations of the game. If you do not need to enable, disable or otherwise manipulate an entity via inputs, then you should leave it unnamed.

    True, your capture trigger brushes don't need to be tall, normally. They aren't 'wrong', though, and I don't think they will affect the gameplay at all. Though it looks possible for someone on B to stand on the sloping roof next to the point room, or on one of the cross beams on its exterior faces, and still capture.

    EDIT: Also I checked your BSP and you do have a cubemap in there. You only have one env_cubemap entity in your map so that's why the cubemap build process is so short. It will take longer if you have more cubemaps. During alpha, one cubemap is great because it keeps things simple and the file size down. So you do not seem to have a problem with cubemaps! :)

    I have played Chateaux before. As Spy would say, "You have done well."
     
    • Thanks Thanks x 2
  11. henke37

    aa henke37

    Messages:
    1,919
    Positive Ratings:
    449
    The entitydata lump is not size restricted, aside from the overal maximum lump size limit. You are not going to hit that one. What the vvis post compile reports is a mere recommendation. I've safely exceeded that recommendation with several hundred percent, but that was a very special case and I can't recommend it, other limits normally occur as an indirect result of all those entities.
     
  12. about drew

    about drew L1: Registered

    Messages:
    47
    Positive Ratings:
    6
    func_nobuild: okie dokie. I wasn't intending to be controlling, just cautious. Now that I think about it, I should have done some more research on Valve maps to see what they do about that.

    cubemap: ironically, this is the least referenced issue in this thread. The whole reason I thought there was an issue was because people during the Gameday mentioned how I had cubemaps but didn't build them. But I had already tried, and it was giving me that weird error afterward. And apparently everything was shiny?

    And it's good to hear that. I don't play Spy as much, so that's very uplifting.