Zhlt 3.0 Beta

124678

Comments

  • OlmyOlmy Join Date: 2003-05-08 Member: 16142Posts: 1,442 Fully active user
    You really should write a more concise detailed changelog for all the betas. I have no idea what 'added ajimbo's csg code' means for me... how does it change CSG... If you were to explain how you've modified the p15 tools code over the course of the betas people might be more likely to start using the tools (when rad works).
  • TequilaTequila Join Date: 2003-08-13 Member: 19660Posts: 3,022
    QUOTE (Olmy @ Oct 20 2004, 12:28 PM)
    Yeah why null faces that will be cut out by bsp anyway?

    Efficiency, my dear. It's too easy to create everything with null and then add proper textures after. That way, everything that can be nulled, is.
  • amckernamckern Join Date: 2003-03-03 Member: 14249Posts: 970 Fully active user
    bad news for some

    I have been neglecting the code for the past week, due to all these asignments i have been given, how ever i hope to have a working build of ZHLT 3.0 out before hl2, so thats about 2 1/2 weeks

    No Frils!
  • BulletHeadBulletHead Join Date: 2004-07-22 Member: 30049Posts: 2,530
    ah, I was about to ask when the non-beta version will be out... but now I see


    Please hurry... my compile on my map atm is over an hour long at the MINIMUM settings (fast vis, no opaque, no bounce, ect) and that is a pain in the rear to work with when testing random shaz to see what it looks like in game (aka, lighting effects)


    But you guys are truckin along! Good luck!
    QUOTE (DragonMech @ Jul 9 2005, 09:19 PM)
    QUOTE (Sonic @ Jul 9 2005, 06:49 PM)
    I wish my butcheeks could propel me up flights of stairs are terrifying speeds.

    I sense a custom title right there... :D
  • FragBait0FragBait0 Join Date: 2003-12-16 Member: 24431Posts: 58
    1. Why is your map taking that long to compile anyway?

    2. Why do you expect ZHLT 3 to fix it?
  • MendaspMendasp I touch maps in inappropriate places Valencia, Spain Join Date: 2002-07-05 Member: 884Posts: 4,175 Fully active user
    QUOTE (FragBait0 @ Oct 22 2004, 01:52 PM)
    2. Why do you expect ZHLT 3 to fix it?

    Read any of his posts, it explains a lot.
  • ReveReve Join Date: 2003-09-23 Member: 21142Posts: 64
    FragBait0: RAD after p13 is horrendously slow.

    amckern: Have a reply from XP-Cagey, see here.

    Reve
  • ReveReve Join Date: 2003-09-23 Member: 21142Posts: 64
    Anyone with some free time care to try to introduce the changes in that file in the thread linked to in the previous post one at a time to see what causes the problems? Post any results here or email to amckern.
  • AJenboAJenbo Join Date: 2004-06-14 Member: 29298Posts: 30
    edited October 2004
    lol my name i definatly not ajimbo it Anders Jenbo or short AJenbo

    any way, adding bevel instead would aktualy make sence as the colisions isn't striped and that way you would be able to get corect colision with out sticky eges, so use bevel instead of null to optimise you maps.

    the thing that i changed for bsp is that it devides fited and non fited textures by the same value (240 by default)
  • amckernamckern Join Date: 2003-03-03 Member: 14249Posts: 970 Fully active user
    thanks

    If your going to send me anything please put zhlt in the subject, or message, as my filters catch that an put it in my zhlt folder, if you dont, it will most liley get removed

    I personaly will take a look at the code, and see what has changed

    amckern

    No Frils!
  • BulletHeadBulletHead Join Date: 2004-07-22 Member: 30049Posts: 2,530
    edited October 2004
    QUOTE (Reve @ Oct 22 2004, 09:04 AM)
    FragBait0: RAD after p13 is horrendously slow.

    amckern: Have a reply from XP-Cagey, see here.

    Reve

    that answers your question when I looked at the compile logs...

    it was indeed the RAD... meh, takes fo-eva!


    btw- any progress updates us non-coders can understand ? tounge.gif
    QUOTE (DragonMech @ Jul 9 2005, 09:19 PM)
    QUOTE (Sonic @ Jul 9 2005, 06:49 PM)
    I wish my butcheeks could propel me up flights of stairs are terrifying speeds.

    I sense a custom title right there... :D
  • GiGaBiTeGiGaBiTe Join Date: 2003-10-07 Member: 21489Posts: 1,110 Advanced user
    whats with rad taking forever to compile huge maps? i can do rad on my

    athlon 2400
    512 meg ram

    in like 15 minutes on complex maps that take up 70% of the grid in hammer.

    i use ZHLT 2.5.3 Custom Build 1.7, xp-cageys dont work right, when i compile a map, rad gives an error "no light entities found in the map, you dont want to run around in pitch dark do you?"

    lol kills maps that have almost all texlights.
    QUOTE (unknown)
    Admiral, why dont we just breach the hull after overriding the automatic hatchlocks closing procedure?

    Last time we did this an onos just put its fat **** inside the hole and lerks just farted a new athmosphere.
    It looked so gross that we decided to never ever do this again.


    My Website
    NS Map Archive
  • amckernamckern Join Date: 2003-03-03 Member: 14249Posts: 970 Fully active user
    yeah http://www.zhlt.tk for those of you that make typos trying to put all those acro's into a url, such as AMMAHLS - "Amckerns Maps Mods And Half Life Stuff"

    please pimp zhlt.tk as it needs at least 25 hits a month for it to stay active, and the .tk will move with the download, so no need to post a new url when the file is updated
    No Frils!
  • The_Real_NemThe_Real_Nem Join Date: 2002-12-16 Member: 10900Posts: 53
    edited October 2004
    I put the beta HLRAD through a profiler and I've attached the results (zipped .rtf file).

    The profile was done on a simple map (a little smaller then your average co map) using no HLRAD switches and a debug .exe. I had to use a simple map because the more complex ones took for god damn ever (it takes about 60 times longer for the map to compile with the profiler).

    The results don't show any glaring "optimize me here" results, but there are some general optimizations that the tools could probably benefit from (standard stuff). I admit I haven't had a chance to study the results yet, but it might be interesting to put the p13 source through the profiler (if the code still exists) to see if there are any glaring differences.

    Edit:
    I should point out that about 92% of the "% in Method" was spent on WaitForSingleObject() (which makes sense if you think about it). This is important because when you are looking at the below chart (a subset of the attached file), 2.5% is a huge chunk of the 8% not attributed to WaitForSingleObject().

    CODE
    Method Name     % in Method     % with Children         Called          Average


    TestLine_r      2.5             2.5                     687,143,438     0.3
    PointInLeaf     2.4             2.4                     112,108,803     1.8
    HuntForWorld    0.4             3.3                     561,871 64.7    0.5


    Nem
  • The_Real_NemThe_Real_Nem Join Date: 2002-12-16 Member: 10900Posts: 53
    edited October 2004
    Based on the results of the profiler I've optimized some HLRAD functions (most of them were already quite optimized but I did my best):

    TestLine_r(): trace.cpp
    CODE

    int             TestLine_r(int node, const vec3_t start_c, const vec3_t stop)
    {
    vec3_t start;
    VectorCopy(start_c, start);

    while (1)
    {
     tnode_t*        tnode;
     float           front, back;

     if (   node == CONTENTS_SOLID
      || node == CONTENTS_SKY
     //  || node == CONTENTS_NULL
     )
      return node;

     if (node < 0)
      return CONTENTS_EMPTY;

     tnode = &tnodes[node];
     switch (tnode->type)
     {
     case plane_x:
      front = start[0] - tnode->dist;
      back = stop[0] - tnode->dist;
      break;
     case plane_y:
      front = start[1] - tnode->dist;
      back = stop[1] - tnode->dist;
      break;
     case plane_z:
      front = start[2] - tnode->dist;
      back = stop[2] - tnode->dist;
      break;
     default:
      front = DotProduct(start, tnode->normal) - tnode->dist;
      back = DotProduct(stop, tnode->normal) - tnode->dist;
      break;
     }

     if (front >= -ON_EPSILON && back >= -ON_EPSILON)
     {
      node = tnode->children[0]; // Non-recurse recurse with tnode->children[0].;)
     }
     else if (front < ON_EPSILON && back < ON_EPSILON)
     {
      node = tnode->children[1]; // Non-recurse recurse with tnode->children[1].
     }
     else
     {
      vec3_t          mid;
      float           frac;
      int             side;
      int             r;

      side = front < 0;

      frac = front / (front - back);

      mid[0] = start[0] + (stop[0] - start[0]) * frac;
      mid[1] = start[1] + (stop[1] - start[1]) * frac;
      mid[2] = start[2] + (stop[2] - start[2]) * frac;

      r = TestLine_r(tnode->children[side], start, mid);  // We are forced to really recurse.

      if (r != CONTENTS_EMPTY)
       return r;

      node = tnode->children[!side];  // Non-recurse recurse with tnode->children[!side].
      VectorCopy(mid, start);   // start changed so we need to "pass" it.
     }
    }
    }

    Before TestLine_r() was purely recursive, now it is an iterative/recursive hybrid and it pays off in performance. This effects BuildFacelights().

    PointInLeaf(): qradutil.cpp
    CODE

    dleaf_t*        PointInLeaf(const vec3_t point)
    {
       int             nodenum;
       vec_t           dist;
       dnode_t*        node;
       dplane_t*       plane;

       nodenum = 0;

       do
       {
           node = &g_dnodes[nodenum];
           plane = &g_dplanes[node->planenum];

           dist = DotProduct(point, plane->normal);

           if (dist >= plane->dist)
           {
               nodenum = node->children[0];
           }
           else
           {
               nodenum = node->children[1];
           }
       }
    while (nodenum >= 0);

       return &g_dleafs[-nodenum - 1];
    }

    Before PointInLeaf() was doing an unnecessary comparison and floating point subtraction. This usually wouldn't make too much difference except this function gets called a couple hundred million times and this is something the compiler will not optimize.

    getPlaneFromFace(): qradutil.cpp
    CODE

    const dplane_t* getPlaneFromFace(const dface_t* const face)
    {
       if (!face)
       {
           Error("getPlaneFromFace() face was NULL\n");
       }

       if (!face->side)
       {
     return &g_dplanes[face->planenum];
       }
       else
       {
           return &backplanes[face->planenum];
       }
    }

    The profiler revealed that !face->side is far more common then face->side so I swapped the two (simple optimization rule: the most probable branch should come first). The compiler can handle the ! and again, this is only significant because of the number of times the function is called. (And even then it isn't that significant.)

    getPlaneFromFaceNumber(): qradutil.cpp
    CODE

    const dplane_t* getPlaneFromFaceNumber(const unsigned int faceNumber)
    {
       dface_t*        face = &g_dfaces[faceNumber];

       if (!face->side)
       {
     return &g_dplanes[face->planenum];
       }
       else
       {
     return &backplanes[face->planenum];
       }
    }

    Same deal as above.

    Results:

    Small Test Map
    Before: 65.11 s
    After: 60.89 s

    Medium Test Map
    Before: 188.64 s
    After: 178.22 s

    Notes:
    I used MD5 checksums to insure that the code changes did not effect the HLRAD output. These changes yielded about a 5% speed increase on my test maps, this isn't too significant but not bad for an hours work. The above times are accurate to within a second.

    That's all, maybe I'll look at some more complicated functions tomorrow,
    Nem
  • amckernamckern Join Date: 2003-03-03 Member: 14249Posts: 970 Fully active user
    OMG!

    I'll check though that

    Good work Nem
    No Frils!
  • ReveReve Join Date: 2003-09-23 Member: 21142Posts: 64
    /me echoes amckern wow.gif

    Nem you're a star! smile-fix.gif
  • ReveReve Join Date: 2003-09-23 Member: 21142Posts: 64
    Um, removing this floating point subtraction doesn't affect hlrad building maps made in QuArK, which uses floating points, does it? confused-fix.gif
  • FragBait0FragBait0 Join Date: 2003-12-16 Member: 24431Posts: 58
    QUOTE
    unnecessary comparison and floating point subtraction

    That kinda makes me think that there just was no point to that piece of code.
    Maybe not though.

    Anyways some speed ups in RAD are always a good thing so w00t for Nem.
    It's also got me tinkering with a profiler on opt_entdata...whoa its awesome stuff...

    It's both a good and a bad thing that RAD is optimized quite a bit already - bad because i can't look forward to it getting a huge amount faster but good because it hasn't been even slower for all eternity.

    Do a lot of BEVELed surfaces together end up using less clipnodes?
  • ReveReve Join Date: 2003-09-23 Member: 21142Posts: 64
    edited October 2004
    amckern, looking at your changelog for zhlt it says that "Inverse shadows, when using entity light flags" is fixed. Does that mean that the only major issue on my list of problems with p15.5 that still needs fixing is the speed of RAD?

    I think it would be nice to release a beta 4 with all the safe stuff in it, like this entity lighting fix, and perhaps the faster entity shadow code from hullu and this new stuff from nem. Then concentrate on the last fixes before 3.0 final (which we ought to work out a release plan for - i.e. lots of mention on different gaming/mapping websites).

    Nem, had a chance to play with the p10 mathutil code from XP-Cagey (see links above) and see what's causing the really major speed issue in p14? If we get this fixed, we're almost set for release smile-fix.gif
  • The_Real_NemThe_Real_Nem Join Date: 2002-12-16 Member: 10900Posts: 53
    QUOTE
    That kinda makes me think that there just was no point to that piece of code.
    Maybe not though.


    The changes don't change the outcome; they change how you get to the outcome. It's like simplifying a math equation, same result, fewer operations.

    QUOTE
    Nem, had a chance to play with the p10 mathutil code from XP-Cagey (see links above) and see what's causing the really major speed issue in p14? If we get this fixed, we're almost set for release.


    That's one thing I'd love to put the profiler through, it should make the problem obvious. I'll see if I can spot anything though.

    Nem
  • The_Real_NemThe_Real_Nem Join Date: 2002-12-16 Member: 10900Posts: 53
    Ok, I'm a little confused here. I downloaded the p10 mathutil.cpp and it is way different then the mathutil.cpp included in the beta's source. In fact, the mathutil.cpp included in the beta's source seems to be from MHLT 1.7. Am I missing the p15 mathutil.cpp?

    BTW the HLRAD_FASTMATH shaved another 3 seconds of the compile time for my small test map. I didn't notice a visual change but my MD5 test shows something is different. Then again it could just be my hacking to get HLRAD_FASTMATH to compile (am I looking at entirely old code here?)

    Nem
  • BulletHeadBulletHead Join Date: 2004-07-22 Member: 30049Posts: 2,530
    I'm prolly gonna get run outa my skin for asking...

    but is their a release date set? I'd LOVE to not have to compile overnight (my maps starting to get big.. and opaque entities take a LOT of time)
    QUOTE (DragonMech @ Jul 9 2005, 09:19 PM)
    QUOTE (Sonic @ Jul 9 2005, 06:49 PM)
    I wish my butcheeks could propel me up flights of stairs are terrifying speeds.

    I sense a custom title right there... :D
  • AJenboAJenbo Join Date: 2004-06-14 Member: 29298Posts: 30
    Thers no release date thow we are working on a plan schedual. we want this thing sone just as mutch as you do smile-fix.gif
  • amckernamckern Join Date: 2003-03-03 Member: 14249Posts: 970 Fully active user
    oh oo

    Sorry about that, i was trying to see the difrence betwen the files, and did a test build of the beta 4, with the 1.7 file

    i'll fix it up tonight when i get home SORRY, and thanks for picking it up mate

    Relase date i hope will be some time before hl2, so that gives us just over 19 days, even though alot of people will be still working on there hl1 mod maps, untill they get converted to hl2 mods




    AJ, can you please send me the unbuged beta 2005 files?

    I have been trying to convert the sln's to 2005, but am having issues with defunct files in platform sdk xp sp2 (or what platform sdk are you useing with beta 2005)

    amckern@yahoo.com

    Adam

    No Frils!
  • BulletHeadBulletHead Join Date: 2004-07-22 Member: 30049Posts: 2,530
    Yeah, can you guys release the parts that are determined as bug free?
    QUOTE (DragonMech @ Jul 9 2005, 09:19 PM)
    QUOTE (Sonic @ Jul 9 2005, 06:49 PM)
    I wish my butcheeks could propel me up flights of stairs are terrifying speeds.

    I sense a custom title right there... :D
  • GhozerGhozer Join Date: 2003-05-22 Member: 16617Posts: 313 Fully active user
    Using these tools to compile my map, i get a...

    QUOTE
    for Face 3723 (texture rClfBox2) at
    (-1323.973 -220.147 -1042.000) (-1277.798 -161.046 -1042.000) (-1274.000 -164.000 -1042.000) (-1276.954 -167.798 -1042.000) (-1320.046 -223.202 -1042.000)
    Error: Bad surface extents (2 x 17)


    When using Zoners Tools (1.7p13) i dont get this error...

    i checked the brush at the location and there was actually no problems with it, i sat there for almost an hour re-makign the brush and re-trying to compile till i finally tried the old tools... any tracking/work you want me to do? - any more info you need?
    Clan scF / Founder
  • amckernamckern Join Date: 2003-03-03 Member: 14249Posts: 970 Fully active user
    this is a known bug with csg, and as a result, its advised that people use p13 untill we can iron out all the bugs

    the only stable items at this time are bsp, and vis, and its advisable to upgrade both, if not both, then at least use the vis

    No Frils!
  • ReveReve Join Date: 2003-09-23 Member: 21142Posts: 64
    edited October 2004
    On which version was CSG broken?

    *edit* Should I add this to my list of things seriously broken with the p15.5 source code that we're planning to fix for the 3.0 release that's on the front page of zhlt.info? (along with slow rad, messed up shadows, and overbright light_environment). Is there anything else I could add?
    Post edited by Unknown User on
  • AnpheusAnpheus Join Date: 2004-09-30 Member: 32013Posts: 63
    edited October 2004
    I think I've got a map that compiles into an infinite loop.

    Who here needs it? I will send on an individual basis. The last edit that made it 'uncompileable' was the placement of the fourth and uppermost layer.


    Edit: evidence that it got stuck into an infinite loop? It sucked up memory for about an hour which amounted to 1.3GB, and then on the second attempt it got stuck at 1.6GB. Once it achieved these huge numbers the memory usage ceased increasing and the cpu usage of HLRAD decreased.


    I think the tools are entirely p13
Sign In or Register to comment.