Thread: [ARCHIVE] Custom ZHLT by vluzacn

Page 33 of 33 FirstFirst ... 232930313233
Results 801 to 825 of 825
  1. #801
    Registered User vluzacn's Avatar
    Join Date
    May 2010
    Location
    China
    Posts
    274

    Re: custom version of ZHLT by vluzacn

    Quote Originally Posted by Green Astronauts View Post
    My map is colossal, about as big as they get. It's a series of floating snowy islands, in seven separate areas. In Hammer the current WIP version looks like this. Almost all floating islands are func_detail, by the way, just to clarify the large amount of pink in that screenshot
    I'm using vluzacn's ±16384 unit gridhack so it may seem that the map could be bigger, but everything I built thusfar is very, very close to the ±4096 unit boundaries.
    I've done some optimization with CLIP brushes, as you can see in that pic. I have yet to optimize more, though.

    Basically the most detailed part of the map (which is, fortunately, already finished and therefore won't be eating more clipnodes) is a massive tower (click) on one of the floating islands.

    For the rest, the map mostly looks like this and this.

    This map is actually an updated version of an older map I made. Most of what I have yet to do is entity work, but in terms of clipnode-eating additions I still have ahead of me:
    • A large bridge on three floating islands (pic of old version here, without floating islands)
    • Some ruins here and there to spice things up (pic of old version here, pre-really-snowy version)
    • Monsterclips in a lot of locations to prevent monsters from falling off the islands


    The bridge will eat up lots of clipnodes. I'm not really concerned about the monsterclips and the ruins (and foliage) here and there. Still though, it's a pretty ambitious project and I'll probably be pushing against the clipnode limit once I'm done.

    Edit: I just compiled the bridge section (only) of the old version of this map, and it only eats up 2154 clipnodes ('simple' cliptype + clipnode economy mode), or 6.6% of the limit. I'm actually optimistic now!
    Cover the unreachable bottom part of the island with CLIP should help.
    Click image for larger version. 

Name:	clip.jpg 
Views:	56 
Size:	42.7 KB 
ID:	15261

  2. #802
    snarks snarks snarks snarks snarks snarks snarks snarks Green Astronauts's Avatar
    Join Date
    Mar 2013
    Location
    Nijmegen, the Netherlands
    Posts
    196

    Re: custom version of ZHLT by vluzacn

    Thanks a ton for your swift reply! Everything is clear now.

    I've already been using CLIP for the undersides of floating islands where applicable (click) and the map is coming along nicely (click). Still though, thanks for the advice :)

  3. #803
    Registered User
    Join Date
    Jan 2011
    Posts
    32

    Re: custom version of ZHLT by vluzacn

    Hello

    I was wondering for a while how well would these compilers perform on x64, so I made the conversion to see how well it would run.

    The compiled maps seem to be working fine, although there seems to be lighting errors (picture attached), I haven't tested in other maps but this is the only visible lighting bug I have encountered in this one.

    Using x86 lighting is flawless, but there is a very noticeable compile time decrease by using x64.

    I was wondering, has anyone else tested this out?, Any ideas what might be causing this issue?

    There were some x64 compiling warnings related to a potential data loss on conversions from size_t to int or long and vice versa, I fixed this by casting the variables to either size_t or __int64, but it didn't fix the problem so this is likely unrelated or unimportant at all since the compilers use the 64 bit equivalents of the data types during compile.

    I is also worth mentioning that I tested the same spot with the original zhlt3.4 x64 and got the same result, so the original developer didn't do any extra modifications for the x64 build.

    EDIT: I forgot to mention, I am using vl23, the last stable version with Trinity.

    Any ideas?
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	hlep2_aft030000.png 
Views:	78 
Size:	152.6 KB 
ID:	15267  
    Last edited by Hunk Guerrius; 10-04-2013 at 11:14 AM. Reason: plawmz

  4. #804
    Ultimate Monster Mapper amckern's Avatar  
    Programmer
    Join Date
    Feb 2002
    Location
    Sydney, Australia
    Posts
    1,268

    Re: Custom ZHLT by vluzacn

    Dont cast, this will cause holes in the hull, and also result in the issue your experiencing with lighting, just pargram the error code, and you should be fine (or ignore it)

    Compile this in release mode, and see if you get the same errors:
    http://downloads.ammahls.com/zhlt/Ol...f(SSE)-src.zip
    SC Kicks ass!

    My Maps - SC_28, SC_AVP, SC_AVP10, SC_Duno, SC_Max, Opposing Forts, SC_Massive, SC_Oni
    My Web Sites - AMMAHLS

  5. #805
    snarks snarks snarks snarks snarks snarks snarks snarks Green Astronauts's Avatar
    Join Date
    Mar 2013
    Location
    Nijmegen, the Netherlands
    Posts
    196

    Re: Custom ZHLT by vluzacn

    Small request for future VHLT versions, specifically for ripent: Can you have it display the total amount of entities? count_ents says "Counted n entities." at the end and your modified version of ripent, while a lot more useful, doesn't.

  6. #806
    Registered User vluzacn's Avatar
    Join Date
    May 2010
    Location
    China
    Posts
    274

    Re: Custom ZHLT by vluzacn

    Quote Originally Posted by Green Astronauts View Post
    Small request for future VHLT versions, specifically for ripent: Can you have it display the total amount of entities? count_ents says "Counted n entities." at the end and your modified version of ripent, while a lot more useful, doesn't.
    There already is such feature. Run ripent with -export -parse .

  7. #807
    snarks snarks snarks snarks snarks snarks snarks snarks Green Astronauts's Avatar
    Join Date
    Mar 2013
    Location
    Nijmegen, the Netherlands
    Posts
    196

    Re: Custom ZHLT by vluzacn

    I feel so dumb now :x

  8. #808
    Registered User vluzacn's Avatar
    Join Date
    May 2010
    Location
    China
    Posts
    274

    Re: custom version of ZHLT by vluzacn

    Quote Originally Posted by Hunk Guerrius View Post
    EDIT: I forgot to mention, I am using vl23, the last stable version with Trinity.

    Any ideas?
    A lot has changed since v23. Why not try v30 compiled with x64.

    Edit: the attachment has been removed, because the code that causes the error has been located.
    Last edited by vluzacn; 15-04-2013 at 11:44 AM.

  9. #809
    Registered User
    Join Date
    Jan 2011
    Posts
    32

    Re: Custom ZHLT by vluzacn

    Quote Originally Posted by amckern
    Dont cast, this will cause holes in the hull, and also result in the issue your experiencing with lighting, just pargram the error code, and you should be fine (or ignore it)

    Compile this in release mode, and see if you get the same errors:
    http://downloads.ammahls.com/zhlt/Ol...f(SSE)-src.zip
    Compiling that project in x86 works, but just like regular zhlt, x64 does not.

    I did try ignoring the warnings but the result was the same, what I'm actually wondering is if the issue is compiler related (the IDE x64 compiler), since the x64 version is different, it could have turned out less confectioned when generating code. I'm saying this because it is not the first time I run into problems compiling projects in x64.

    Quote Originally Posted by vluzacn
    A lot has changed since v23. Why not try v30 compiled with x64.
    I wish I could use the latest build but there are major lighting errors in maps running with trinity and vhlt starting from 2.5, and the appearance of the lighting error changes with each compile, I think this is related to the fix you have done to the lighting styles on the same face.

    I did try running the map with the file you attached however and not only do I get the lighting error I am talking about, I also get the x64 related lighting bug I attached in my first post.
    Last edited by Hunk Guerrius; 11-04-2013 at 12:43 PM. Reason: moar plawmz

  10. #810
    Donated 15NS$ for Sven's Holiday at the Bahamas Puchi's Avatar  
    Artist
    Join Date
    Nov 2002
    Location
    Akihabara, Bochum or Sailune
    Posts
    5,592

    Re: Custom ZHLT by vluzacn

    Quote Originally Posted by Hunk Guerrius View Post
    and the appearance of the lighting error changes with each compile, I think this is related to the fix you have done to the lighting styles on the same face.
    To get the best result for testing for errors and mistakes, i found it best to use only one core during compile. parameter -threads 1, for all tools.
    takes longer, but definitly better.
    Do it with passion, or not at all.
    Do not say everything you know. Know everything you say.
    [ MarySP ][ nacl-h2o ][ The next SC Version ♥♥♥♥ing pwns! ][Puchis Maps ]

  11. #811
    Registered User
    Join Date
    Jan 2011
    Posts
    32

    Re: Custom ZHLT by vluzacn

    Thanks for the info, that gave me an idea and I went trying to compile the x64 build with only one core, didn't work.

  12. #812
    Administrator AdamR's Avatar  
    Manager
    Join Date
    Mar 2004
    Location
    Cardiff, South Wales [uk]
    Posts
    8,404

    Re: Custom ZHLT by vluzacn

    I'd avoid using 64-bit versions of ZHLT. There are some serious data handling issues, which result in pretty glitchy light patches often spotted as random dark gradients for no reason outdoors (some more noticeable than others). Quite a lot of work needs to be done to make ZHLT work well as a native 64-bit application.
    Adam "Adambean" Reece
    Sven Co-op team

    Also on: Steam | Facebook | Twitter | YouTube | Twitch
    Released AMXX plug-ins: Bind number slots | NextMap with Sven Co-op fix | Sven Co-op administrator icons

  13. #813
    Registered User vluzacn's Avatar
    Join Date
    May 2010
    Location
    China
    Posts
    274

    Re: Custom ZHLT by vluzacn

    Quote Originally Posted by Hunk Guerrius View Post
    I wish I could use the latest build but there are major lighting errors in maps running with trinity and vhlt starting from 2.5, and the appearance of the lighting error changes with each compile, I think this is related to the fix you have done to the lighting styles on the same face.
    Yes. Someone has told me about this lighting styles error before. I believe the compiler comforms strictly to the bsp format and trinity made some unreasonable assumption in it.

    Using parameter '-minlight 1' in hlrad can stop this error.

  14. #814
    Registered User vluzacn's Avatar
    Join Date
    May 2010
    Location
    China
    Posts
    274

    Re: Custom ZHLT by vluzacn

    For anyone who is interested, here is the code that has caused the bug in x64 hlrad :
    Code:
    static void     CalcFaceExtents(lightinfo_t* l)
    {
        const int       facenum = l->surfnum;
        dface_t*        s;
        float           mins[2], maxs[2], val; //vec_t           mins[2], maxs[2], val; //vluzacn
        int             i, j, e;
        dvertex_t*      v;
        texinfo_t*      tex;
    
        s = l->face;
    
        mins[0] = mins[1] = 999999;
        maxs[0] = maxs[1] = -99999; // a little small, but same with Goldsrc. --vluzacn
    
        tex = &g_texinfo[s->texinfo];
    
        for (i = 0; i < s->numedges; i++)
        {
            e = g_dsurfedges[s->firstedge + i];
            if (e >= 0)
            {
                v = g_dvertexes + g_dedges[e].v[0];
            }
            else
            {
                v = g_dvertexes + g_dedges[-e].v[1];
            }
    
            for (j = 0; j < 2; j++)
            {
                val = v->point[0] * tex->vecs[j][0] +
                    v->point[1] * tex->vecs[j][1] + v->point[2] * tex->vecs[j][2] + tex->vecs[j][3];
                if (val < mins[j])
                {
                    mins[j] = val;
                }
                if (val > maxs[j])
                {
                    maxs[j] = val;
                }
            }
        }
    
        for (i = 0; i < 2; i++)
        {
            l->exactmins[i] = mins[i];
            l->exactmaxs[i] = maxs[i];
    
            mins[i] = floor(mins[i] / 16.0);
            maxs[i] = ceil(maxs[i] / 16.0);
    
    		l->texmins[i] = mins[i];
            l->texsize[i] = maxs[i] - mins[i];
    	}

    With the same v->point and tex->vecs as input (both of them in float type), x86 and x64 version gives different l->texsize.

    The reason is that this part of code is not stable against rounding errors in floating point calculation.

    Does anyone know how to modify this so x64 will give the identical result of x86?

  15. #815
    Registered User
    Join Date
    Jan 2011
    Posts
    32

    Re: Custom ZHLT by vluzacn

    "-minlight 1"? Won't that light the map with a minimum lighting value so it doesn't come out picth black?

    Anyway, I can't see the answer for that, quite honestly the x64 compilers are supposed to behave exactly the like the x86 version.

    What I'm going to try for the fun of it, is to try it with Intel's C compilers.

  16. #816
    Registered User
    Join Date
    Jan 2011
    Posts
    32

    Re: Custom ZHLT by vluzacn

    Tried it out, same result.

    Also what the heck:

    Code:
    3>.\mathutil.cpp(223): warning #175: subscript out of range
    3>  		CrossProduct (inedgedir[2], ray, tmp2);
    Code:
    		CrossProduct (inedgedir[1], ray, tmp1);
    		CrossProduct (inedgedir[2], ray, tmp2);
    And this:

    Code:
    4>.\qcsg.cpp(1890): warning #175: subscript out of range
    4>                      wadconfigname[MAX_WAD_CFG_NAME] = 0;
    Code:
    wadconfigname[MAX_WAD_CFG_NAME] = 0;

    These array references are obviously wrong, inedgedir[] is being referenced with position [2] and it clearly only takes 0 and 1 as positions!

    Same for wadconfigname[], it should be [MAX_WAD_CFG_NAME-1], since arrays are defined with total amount of positions starting from 1, but references start from 0.

    Why doesn't visual studio warns about this?

  17. #817
    Registered User vluzacn's Avatar
    Join Date
    May 2010
    Location
    China
    Posts
    274

    Re: Custom ZHLT by vluzacn

    Quote Originally Posted by Hunk Guerrius View Post
    "-minlight 1"? Won't that light the map with a minimum lighting value so it doesn't come out picth black?
    Yes. It gives the lighting style of static lights a non-zero brightness so it won't be optimized.


    Quote Originally Posted by Hunk Guerrius View Post
    Tried it out, same result.

    Also what the heck:

    And this:

    These array references are obviously wrong, inedgedir[] is being referenced with position [2] and it clearly only takes 0 and 1 as positions!

    Same for wadconfigname[], it should be [MAX_WAD_CFG_NAME-1], since arrays are defined with total amount of positions starting from 1, but references start from 0.

    Why doesn't visual studio warns about this?
    The first one is contained in a function which has been abandoned for a long time.
    The second one has been corrected since VHLT v24.
    Apart from these bugs which can be detected by C++ compiler, much more bugs can not. The most recent bug I found was a long-standing one in function DecompressVis, where the array size was calculated from a wrong number and cause overflow. This bug was discovered because I noticed the abnormally long time spent by some faces during hlrad.

  18. #818
    Registered User
    Join Date
    Jan 2011
    Posts
    32

    Re: Custom ZHLT by vluzacn

    Optimized?

    I do want some areas of my maps to come out pitch dark, but -minlight with a value of 1 shouldn't really be noticeable would it?

    Talking about static lighting, it reminds me, there is something about switchable light entities that bothers me ever since the original qtools. They always tend to look a lot worse than unnamed lights, even though ever since zhlt bouncing was introduced for those , the lighting attenuation is still a lot harsher so lights have a much more noticeable spherical look, and in vhlt I can still notice it, isn't it possible to make switchable lights look exactly the same as static lights?
    Last edited by Hunk Guerrius; 15-04-2013 at 10:35 AM.

  19. #819
    Registered User vluzacn's Avatar
    Join Date
    May 2010
    Location
    China
    Posts
    274

    Re: Custom ZHLT by vluzacn

    Quote Originally Posted by Hunk Guerrius View Post
    Optimized?

    I do want some areas of my maps to come out pitch dark, but -minlight with a value of 1 shouldn't really be noticeable would it?
    The code that optimize the lightmap will remove any pitch dark style. "-minlight 1" will give the darkest brightness, so I guess it's not noticeable.


    Quote Originally Posted by Hunk Guerrius View Post
    Talking about static lighting, it reminds me, there is something about switchable light entities that bothers me ever since the original qtools. They always tend to look a lot worse than unnamed lights, even though ever since zhlt bouncing was introduced for those , the lighting attenuation is still a lot harsher so lights have a much more noticeable spherical look, and in vhlt I can still notice it, isn't it possible to make switchable lights look exactly the same as static lights?
    Yes. Just update your compiler. VHLT works perfectly when there are the static light style and at most 1 switchable light style.
    If 2 or more switchable light styles overlap on one face, then when both light styles are turned on, the brightness can be 0%~100% higher than normal brightness because of some gamma problem.
    If 4 or more switchable light styles overlap, then some of the light styles will become pitch dark, and there can be noticeable seams between faces (one side of the seam is brighter than the other side).
    Last edited by vluzacn; 15-04-2013 at 11:42 AM.

  20. #820
    Registered User
    Join Date
    Jan 2011
    Posts
    32

    Re: Custom ZHLT by vluzacn

    I am now using vl3, using -minlight 1 doesn't seem to make dark areas even a little bit brighter so yeah its okay, I see toggleable lights don't have the visible radial nature anymore!, or at least not as much.

    So yeah thanks for the support everyone.

  21. #821
    Registered User vluzacn's Avatar
    Join Date
    May 2010
    Location
    China
    Posts
    274

    Re: Custom ZHLT by vluzacn

    Quote Originally Posted by Hunk Guerrius View Post
    I am now using vl3, using -minlight 1 doesn't seem to make dark areas even a little bit brighter so yeah its okay, I see toggleable lights don't have the visible radial nature anymore!, or at least not as much.

    So yeah thanks for the support everyone.
    Nice. Congratulations.

  22. #822
    Fagnus the Gay Pink Dragon DoomMusic's Avatar
    Join Date
    May 2013
    Posts
    26

    Re: Custom ZHLT by vluzacn

    Hey vluzacn. I just want to say, I love your compilers so far, great work.

    I'm working with a mod, and we use a custom renderer(Trinity) because we need to load in lightmaps from an external file, for nighttime stages, so we don't double the map count in places, and we have more control over things without losing lighting quality.
    We do this by first compiling our map with a "night stage" version of your compilers that ignores the light env, and recognises certain types of lights that the normal one does not. We load this into the game, and have it export the lightmap data to an external file. Then we compile the map normally, and when a certain global is set, we load the external file in as the primary lightmap.

    This has worked just fine with Zoner's last HL tool version, however with your compilers, it seems that the output by the two compiles doesn't match, as far as the geometry is concerned it seems, which is the only time we ever have problems with this feature of ours.

    I'd like to ask, is there something in the compiler code that could throw the results off between compiles, even if otherwise the code is exactly the same, as well as the .map files? I just switched over from a singlecore computer to a 6-core, so maybe I thought, multithreading could cause the issue? I'm not very experienced with multithreaded processing, so I figured I'd ask.

    Thanks.

    EDIT:
    Okay, the issue was caused by multithreading on hlcsg and hlbsp. I've disabled those and now this all works just fine, I was just convinced I did nightstage compiles on my new rig too. You can disregard this.
    Last edited by DoomMusic; 12-05-2013 at 09:08 AM.

  23. #823
    Registered User vluzacn's Avatar
    Join Date
    May 2010
    Location
    China
    Posts
    274

    Re: Custom ZHLT by vluzacn

    Quote Originally Posted by DoomMusic View Post
    Hey vluzacn. I just want to say, I love your compilers so far, great work.

    I'm working with a mod, and we use a custom renderer(Trinity) because we need to load in lightmaps from an external file, for nighttime stages, so we don't double the map count in places, and we have more control over things without losing lighting quality.
    We do this by first compiling our map with a "night stage" version of your compilers that ignores the light env, and recognises certain types of lights that the normal one does not. We load this into the game, and have it export the lightmap data to an external file. Then we compile the map normally, and when a certain global is set, we load the external file in as the primary lightmap.

    This has worked just fine with Zoner's last HL tool version, however with your compilers, it seems that the output by the two compiles doesn't match, as far as the geometry is concerned it seems, which is the only time we ever have problems with this feature of ours.

    I'd like to ask, is there something in the compiler code that could throw the results off between compiles, even if otherwise the code is exactly the same, as well as the .map files? I just switched over from a singlecore computer to a 6-core, so maybe I thought, multithreading could cause the issue? I'm not very experienced with multithreaded processing, so I figured I'd ask.

    Thanks.

    EDIT:
    Okay, the issue was caused by multithreading on hlcsg and hlbsp. I've disabled those and now this all works just fine, I was just convinced I did nightstage compiles on my new rig too. You can disregard this.
    Yes, it was multithreading. But there are some other issues I'd like to mention.

    The first one is when you said "export lightmap data", I assume you meant exporting the lightmap data lump as well as the lightmap offset in each face. Because in VHLT, the lightmap offsets can be different even if all lights are static.

    The second one is the compiler does not guarantee that you get the same output when you compile again. I suggest you to do a '-onlyents' compile to update the entities after adding some lights, and then only run hlrad to update the lightmap. In this case, only entity data and lightmap data are changed.

  24. #824
    Fagnus the Gay Pink Dragon DoomMusic's Avatar
    Join Date
    May 2013
    Posts
    26

    Re: Custom ZHLT by vluzacn

    Quote Originally Posted by vluzacn View Post
    Yes, it was multithreading. But there are some other issues I'd like to mention.

    The first one is when you said "export lightmap data", I assume you meant exporting the lightmap data lump as well as the lightmap offset in each face. Because in VHLT, the lightmap offsets can be different even if all lights are static.
    Thanks for your reply. I'm not exporting the lightmap lump, I go through each surface of the world model and export the 24-bit color data stored in each one's lightmap data pointer. It's not the cleanest way but I figured it'd be the simplest and fastest, and I'm a slob. So far it's always worked just fine.

    Quote Originally Posted by vluzacn View Post
    The second one is the compiler does not guarantee that you get the same output when you compile again. I suggest you to do a '-onlyents' compile to update the entities after adding some lights, and then only run hlrad to update the lightmap. In this case, only entity data and lightmap data are changed.
    Edit: Disregard the previous, I misunderstood. Yeah you're right, I'll do that instead of doing a full recompile. Though I never had issues, it is best to be safe, thanks for the advice.

    One other thing I'd like to mention, is that in some places I still see problems with faces being invisible, mainly on stuff like the roofs I have on buildings, let me show you. I also have some elsewhere, but that I can solve by making a column into a func_wall. I've attached these to the post.
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	holesinmap1.jpg 
Views:	39 
Size:	235.1 KB 
ID:	15290   Click image for larger version. 

Name:	holesinmap2.jpg 
Views:	39 
Size:	218.3 KB 
ID:	15291   Click image for larger version. 

Name:	holesinmap3.jpg 
Views:	41 
Size:	291.5 KB 
ID:	15292  
    Last edited by DoomMusic; 12-05-2013 at 11:45 AM.

  25. #825
    Administrator Sniper's Avatar  
    Manager
    Join Date
    Aug 2001
    Posts
    7,102

    Explosive Crate Re: Custom ZHLT by vluzacn

    I've decided to close this thread, it's getting too long.

    Please start a new thread to continue this discussion. Thanks.
    - David "Sniper" McDermott
    Sven Co-op Lead Programmer
    "I mean it's like a koala bear crapped a rainbow in my brain!"

Page 33 of 33 FirstFirst ... 232930313233

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •