Jump to content

MoonDog

Members
  • Posts

    568
  • Joined

  • Last visited

Posts posted by MoonDog

  1. Non-biased point of view. 4 works really well for it's cool colors. It's easy on the eyes for extended viewing, and the angle that it was taken allows the geometry in the level to compliment the layout of the top of the site without distracting from it.

     

    It clashes a little bit with the logo however.

     

     

    7 fits the bill of nondescript far better than the other two however. The orange and brown tones are pretty easy on the eye, but it's rather unremarkable other than that with the layout of the webpage. It also does not blend with the logo well.

     

     

    10 is certainly a pretty image, but the vibrant background and busy skyline is distracting and can become some what of an eyesore after extended viewing. Blends with the logo a bit better, but with the JKHUB Bar, Navigation bar, content bar and line of trees, there is just way too much going on.

    Boothand likes this
  2. So, increasing block size is the answer to my question. Therefore vis is still being drawn etc.  So you are still using areaportals in addition to drawing vis, increasing block size.  What are block sizes normally used in maps you guys have been involved with?

     

    I had previously used area portals when I need to split (sort of) two areas from each other to increase performance while a barrier is thrown.

     

    Increasing the _blocksize in the world spawn is something I have used on large open maps, large terrain maps, etc... Blocksize is automatically 512. Meaning that every X unit, q3map2 will automatically create portal splits on X Y Z. This is why large open maps benefit from a larger blocksize. If you have 512 blocks split on a huge map, vis data can pile up pretty quickly.

     

    I'm not sure how other modders use blocksize, but when I was doing JKO/JKA stuff I usually set blocksize to 0 and did my own portal optimization with hint brushes. I don't like how blocksize throws splits, and I don't like having to design around 512 blocks to accommodate this behavior. Usually, I'd end up with awkward splits where I didn't want them, or splits across cells that did nothing to optimize vis. I suppose if you don't want to do much hint optimization, you can rely a bit on blocksize to automatically create some portals. It's not intuitive at all though, as previously stated.

  3.  Vis should always be priority one over everything else in making a map. I didn't always create maps this way but as I have learned vis is the 1st factor to consider when making one.

     

    That shouldn't be your first consideration. The only problem with designing completely around the idea of having the perfectly vis optimized map, is that you will have to make concessions that could compromise the fun of the gameplay in your level. I'd say you should be very aware of your budgets while blocking out the level, and focus on designing something fun that meets your goals. It's best just to be constantly aware of your budgets while designing playspace. You'll know the purpose of each area, and thus will be able to estimate how it will be dressed artistically later on after play testing and iteration.

     

    I've played old Q3 maps designed entirely for vis. They tend to have hallway cancer. Thus, are not fun.

    .

  4. ---I moved this question from introductions.---

     

    I do have one question about somethign I came across recently.

     

    My question is about areaportal usage.  I see people putting them in doors and elevators and saying it's essential for map making etc.  (I think one of the video tutorials suggests areportal usage whenever possible.)(I watched them yesterday)   I am no stranger to using area portals,  I used to use them a lot.  I was wondering, if the maps being made are so big it exceeds max visibility and won't compile vis and areaportal usage is the only way to separate vis with connected areas of a map or are they being used in addition with the vis compile not exceeding max visibility?

     

    A lot of times when I help people with vis, they do have a ton of vis data. Area portals are not going to fix that. Usually because the levels in question are very large. This I almost always fix by increasing the block size, or making the block size 0 so less arbitrary portals are being created by these automated split blocks conjoining with structural brushes.

     

    If you are splitting areas with regular vis design and hint brush usage, that is great. I agree that you design with the intent of using area portals as lightly as possible for an MP map.

     

    What usually happens is that people run out of options because of their initial design. There isn't a realistic way to split the vis to reduce the render between two cells, and they have obscene geometry, entities and so forth on both sides of a threshold. Therefor, an area portal helps on performance in those cases. That isn't always a bad thing. Cookie cutter designed levels are not very fun.

×
×
  • Create New...