Thread: Vluzacn's ZHLT v33 Update

Page 1 of 3 123 LastLast
Results 1 to 25 of 58
  1. #1
    Registered User vluzacn's Avatar
    Join Date
    May 2010
    Location
    China
    Posts
    274

    Vluzacn's ZHLT v33 Update

    2014/2/2

    ----Improved the smoothness of bounced light and sky light
    Click image for larger version. 

Name:	triangulation.png 
Views:	1119 
Size:	448.5 KB 
ID:	15667
    The new advanced interpolation algorithm produces better lighting from the per-patch lighting information.
    The improvement is more clearly visible under the fast mode of hlrad where all lighting are only calculated on each patch.

    ----Added a feature to create fake lightmap on transparent entities
    Because the lightmap of transparent entities is ignored by the game engine, transparent entities like glass usually looks white without the tint from lightmap and doesn't blend in well with the environment.
    The new feature solves this problem by altering the texture of a transparent entity. It creates a new texture for each face and embeds the lightmap into this texture.
    This feature is currently experimental, because it has a big disadvantage: the texture memory will increase significantly. For example, the three glasses in the picture consumes about 135KB texture memory.
    To enable this feature, just add key 'zhlt_embedlightmap' value '1' into the entity.
    Click image for larger version. 

Name:	embedlightmap1_small.png 
Views:	1068 
Size:	170.0 KB 
ID:	15668
    Click image for larger version. 

Name:	embedlightmap2.png 
Views:	574 
Size:	60.7 KB 
ID:	15669
    The textures whose names start with '__rad' were created by the compiler. You can remove them and restore to the original texture by running 'ripent.exe -deleteembeddedlightmaps [mapname]'.

    ----Included 64-bit version of hlrad
    The following tool chain should be used on a 64-bit computer:
    hlcsg.exe
    hlbsp.exe
    hlvis.exe
    hlrad_x64.exe
    However, the 32-bit version of hlrad can still be used, with the limitation that it runs a little slower and cannot access more than 2GB of RAM.
    Note that hlcsg, hlbsp and hlvis are still 32-bit, because the compiler must rely on 32-bit code to finish some part of the compile, to be more specific, calculating face extents.
    If you get "Couldn't open extent file" error when using the 64-bit hlrad to recompile the lighting of an existing map, please run 'ripent.exe -writeextentfile [mapname]' to calculate the face extents.

    ----Now all temporary intermediate files are automatically deleted after hlbsp
    The only intermediate files that won't be deleted are .prt file, .wa_ file and .ext file.
    The prt file is required by hlvis and the wa_ and ext file are required by hlrad. They are not deleted so that you can recompile hlvis or hlrad after an entity update (hlcsg '-onlyents').

    ----Fixed a bug in wad auto detection
    Attached Files Attached Files

  2. #2
    Nothing to see here. BackAssward's Avatar
    Join Date
    Aug 2006
    Posts
    388

    Re: Vluzacn's ZHLT v33 Update

    In the first pic, the changes to the diffusion of the light on the right wall is pretty nice! The most obvious thing I noticed was that circle of shadow between the boxes at the far wall. Pretty cool.

    I'm no mapper but I was curious about 2 things. The box on the back left, should the shadow on the floor be darker to match the shadow on the wall where they meet (left most wall and floor)? Further forward, the opposite, should there be a shadow on the lower wall to match that on the floor? I guess I never pay enough attention when I play, so I am sure that is was probably always that way with shadows like that.

  3. #3
    QPU-aligned Silencer's Avatar  
    Contributor
    Join Date
    May 2006
    Posts
    6,076

    Re: Vluzacn's ZHLT v33 Update

    Transparent objects affected by light is one of my oldest Goldsource wet dreams. Awesome! Should probably only be used when absolutely needed, i.e. the transparent object is partially occluded by a dark shadow.

  4. #4
    Level Designer CryoKeen's Avatar
    Join Date
    Aug 2001
    Location
    United States
    Posts
    4,451

    Re: Vluzacn's ZHLT v33 Update

    I will download and enjoy, ty!

  5. #5
    Craazy! the-middleman's Avatar  
    Artist
    Join Date
    Sep 2012
    Location
    Entity-Guide
    Posts
    514

    Re: Vluzacn's ZHLT v33 Update

    You are a magican! Thanks so much for your work!
    ZN progress:

  6. #6
    warrior spy-warrior's Avatar  
    Contributor
    Join Date
    Nov 2006
    Location
    Europe, France, Paris
    Posts
    2,941

    Re: Vluzacn's ZHLT v33 Update

    good software x64

  7. #7
    Registered User
    Join Date
    Jan 2014
    Posts
    16

    Re: Vluzacn's ZHLT v33 Update

    Congratulations vluzacn!

    Hey, you can tell me how to use this following textures?

    - black_hidden
    - boundingBox
    - clipbevel
    - clipbevelbrush
    - cliphull1
    - cliphull2
    - cliphull3
    - contentempty
    - contentwater
    - noclip
    - solidhint

    Please

  8. #8
    Registered User
    Join Date
    Jul 2013
    Posts
    9

    Re: Vluzacn's ZHLT v33 Update

    Good work !

  9. #9
    Registered User Dynamite's Avatar
    Join Date
    Nov 2004
    Location
    Europe
    Posts
    2,826

    Smile Re: Vluzacn's ZHLT v33 Update

    I managed to compile ripent on Linux. It's dirty but it compiles and runs. Based on VHLT33 and some old Linux builds.
    Look for "~Dynamite" comments in the code for my changes. Note that I don't know c++. So poor decision making in the code is because of that.

    Thanks to Meld and Solokiller for helping me out.

  10. #10
    Registered User
    Join Date
    Nov 2010
    Posts
    70

    Re: Vluzacn's ZHLT v33 Update

    I like the embeded lightmaps but is it necessary for it to generate tons of 256x256 textures to do this? Cant it just reuse a _rad texture generated from a previous surface and be no greater than 64x64? Its not like players would be able to see any high detail from them. The _rad textures makes up for about 70% of total textures adding 7MB to a tiny little map with only 6 glass walls. For large maps this will be a pretty big problem as it could add over 20MB to the file size.

    EDIT: Having an option to only generate gray scale embeded lightmaps would be good. If your map has a lot of colorful lighting near windows the glass gains a colored tint which doesn't look natural.
    Last edited by Urban_Ninja; 17-02-2014 at 04:52 PM.

  11. #11
    Advanced Leveldesigner SourceSkyBoxer's Avatar
    Join Date
    Apr 2011
    Location
    Germany
    Posts
    787

    Re: Vluzacn's ZHLT v33 Update

    Good update! I will try it later. Because i am still busy and i am working at Away3D with AS3 and Flex 3.6.0. Don't worry for me! I always am here.
    Hello guys, Svencoop. I am sorry Please respect me! I am deaf. Thanks, Sven-Coop Forum!

    Please do not share to shit dropbox! Please share only Mega.nz!
    Muhahaha, Facebook crashed!

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

    Re: Vluzacn's ZHLT v33 Update

    Quote Originally Posted by Dynamite View Post
    I managed to compile ripent on Linux. It's dirty but it compiles and runs. Based on VHLT33 and some old Linux builds.
    Didn't know some people want this for Linux. I'll test it on Linux someday.


    Quote Originally Posted by Urban_Ninja View Post
    I like the embeded lightmaps but is it necessary for it to generate tons of 256x256 textures to do this? Cant it just reuse a _rad texture generated from a previous surface and be no greater than 64x64? Its not like players would be able to see any high detail from them. The _rad textures makes up for about 70% of total textures adding 7MB to a tiny little map with only 6 glass walls. For large maps this will be a pretty big problem as it could add over 20MB to the file size.

    EDIT: Having an option to only generate gray scale embeded lightmaps would be good. If your map has a lot of colorful lighting near windows the glass gains a colored tint which doesn't look natural.
    Good idea. The resolution reduction will be included in the next version. It is quite easy to implement.

    The tint is the original intent. I think what you need is to manually darken the texture with photoshop. This might require more effort but will allow you to reuse the same texture.

  13. #13
    Still learning wolf-3d's Avatar  
    Tester
    Join Date
    Jan 2011
    Location
    Somewhere Warm.
    Posts
    1,449

    Re: Vluzacn's ZHLT v33 Update

    Quote Originally Posted by vluzacn View Post
    Didn't know some people want this for Linux. I'll test it on Linux someday.

    Good idea. The resolution reduction will be included in the next version. It is quite easy to implement.

    ...
    Thanks for all the hard work you put in and also for providing so-many enchantments.
    Regards
    Wolf-3D

  14. #14
    Registered User
    Join Date
    Mar 2012
    Posts
    13

    Re: Vluzacn's ZHLT v33 Update

    Quote Originally Posted by wolf-3d View Post
    Thanks for all the hard work you put in and also for providing so-many enchantments.
    Seconded. You rock!

  15. #15
    Registered User
    Join Date
    Nov 2010
    Posts
    70

    Re: Vluzacn's ZHLT v33 Update

    Quote Originally Posted by vluzacn View Post
    The tint is the original intent. I think what you need is to manually darken the texture with photoshop. This might require more effort but will allow you to reuse the same texture.
    I knew the tinted windows is the whole point of this. What im saying is adding an option for it to only give windows a grayscale tint would be great. I like this feature because its soooo convenient to give windows a more natural tint without without having to manually set each windows render amount through trial and error to suit the rooms lighting level. But in a multicolored environment having rainbow set of windows to go with it isn't always desired.

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

    Explosive Crate Re: Vluzacn's ZHLT v33 Update

    Quote Originally Posted by BackAssward View Post
    I'm no mapper but I was curious about 2 things. The box on the back left, should the shadow on the floor be darker to match the shadow on the wall where they meet (left most wall and floor)? Further forward, the opposite, should there be a shadow on the lower wall to match that on the floor? I guess I never pay enough attention when I play, so I am sure that is was probably always that way with shadows like that.
    Yes, these are computer artifacts, just like other artifacts such as shadows cannot be as sharp as they are in real world. They are hard to eliminate due to the sparseness of samples. There are only 25 samples on the far wall.


    Quote Originally Posted by Urban_Ninja View Post
    I knew the tinted windows is the whole point of this. What im saying is adding an option for it to only give windows a grayscale tint would be great. I like this feature because its soooo convenient to give windows a more natural tint without without having to manually set each windows render amount through trial and error to suit the rooms lighting level. But in a multicolored environment having rainbow set of windows to go with it isn't always desired.
    Perhaps you can try the 'info_translucent' entity, so that the glass will take lighting from both sides.
    As for grayscale, it is not as simple as it seems to be. There is no absolutely grey color. If you stay long enough in a blue room, your eyes will perceive blue as grey, and a grey object in that room will be perceived as orange. So the best way to make an object not stand out in an environment is not to make it grey, but is to give it the same tint.

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

    Re: Vluzacn's ZHLT v33 Update

    Good to see progress on the 64-bit tools. When compiling them today I noticed the solutions must have definition "VERSION_32BIT" or "VERSION_64BIT" inside. You might prefer this block in "cmdlib.h" to select this based on the code compiler platform used. Place before the "You must define one of these in the settings of each project: VERSION_32BIT, VERSION_64BIT, VERSION_OTHER. The most likely cause is that you didn't load the project from the sln file." message.

    Code:
    #if defined( _M_X64 ) || defined( _M_IA64 )
    #define VERSION_64BIT
    #elif defined( _M_IX86 )
    #define VERSION_32BIT
    #else
    #define VERSION_OTHER
    #endif
    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

  18. #18
    Registered User
    Join Date
    Mar 2012
    Posts
    13

    Re: Vluzacn's ZHLT v33 Update

    Any estimate on when a new version will be released?

  19. #19
    Registered User
    Join Date
    Mar 2012
    Posts
    13

    Re: Vluzacn's ZHLT v33 Update

    Hey Vluzacn, I've been messing around a bit trying to get good looking shadows with zhlt_lightflags 2 (opaque) together with { (transparent) entities, and found out that the lower the scale of the textures the shadow got projected onto, the smoother and more defined the shadow would be. Obviously this is not really ideal for several reasons, even when not taking engine or compiler limits into account, as really small textures both look out of place and of course causes the flashlight to become equally tiny.

    Therefore I was a bit curious when I noticed the _chop ("grid size of sampling") attribute of the light_surface entity. It says in zhlt.fgd that this is not affected by texture scale, which led me to believe I could use textures with 1.0 scale and instead just increase the _chop value of light_surface to get really defined shadows. However, this seems not to be the case. Here's a shot where the adjacent walls have a texture scale of 1.0 and the _chop of light_surface is set to 512 (the highest value that made any difference, anything higher didn't seem to change anything). Then I scaled the walls down to 0.3, and as one can see, the shadows are considerably more defined.

    Now, have I misunderstood something completely here? I guess this wasn't what these entities and attributes (opaque, _chop, etc) were designed for in the first place, but shouldn't it be possible to get a really high grid sample size from the light without having to scale down any textures? If not, then this would be a cool feature for a future update (if it's even feasible). And yeah, I understand this probably increases lightpatches like crazy, but it would be neat either way.

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

    Re: Vluzacn's ZHLT v33 Update

    One basic thing that no mapper or compile tool can change is that the lightmap grid in Goldsrc is tied tightly with texture scale. So small texture scales must be used if one want to get detailed lightmap. An example is "The Core" mod, where the textures are in higher resolution and are used in 0.5 scale.

    I think this could explain your problem. Apart from this, there is a common misunderstanding about the function of "chop". Many people thought that "chop" can have significant impact on the effect. Actually smaller "chop" does make the lighting more accurate, but the improvement is very limited as the lightmap grid cannot be changed. The default "chop" should be suitable for most of the cases and larger "chop" can be used to reduce compile time.




    Quote Originally Posted by Kaffikopp View Post
    Any estimate on when a new version will be released?
    It will be released soon. This update will be small and only cover the things reported in previous posts.



    Quote Originally Posted by AdamR View Post
    Good to see progress on the 64-bit tools. When compiling them today I noticed the solutions must have definition "VERSION_32BIT" or "VERSION_64BIT" inside. You might prefer this block in "cmdlib.h" to select this based on the code compiler platform used. Place before the "You must define one of these in the settings of each project: VERSION_32BIT, VERSION_64BIT, VERSION_OTHER. The most likely cause is that you didn't load the project from the sln file." message.
    Thanks. But I just wanted to make this option more explicit, because VERSION_64BIT corresponds to some quite different branch of code.

  21. #21
    Registered User
    Join Date
    Jun 2014
    Posts
    1

    Re: Vluzacn's ZHLT v33 Update

    Hello,

    I was just making map and tried to make mirror even thou on the other side is another room. I was half success thanks to BOUNDINGBOX textured brush in func_illusionary so I wasn't see reflection when I entered room on the other side. But if I'm in hallway and look inside room with mirror I can see small part of reflection when I'm not supposed to.
    Video

    So I got idea for new feature ensured by VIS - If I could create a brush entity and set name of target entity which is supposed to be visible or always invisible only if player is touching this area then I would be able to set mirror visible only when I'm in room with it and when I exit then just change surface of mirror to solid glass.

    If it would be possible to implement I think it would be also useful for more tricks with visibility.


    And I also want to thank Vluzacn for this great compilers which is better every update. I would be lost if I had to start using ZHLT for some reason again.


    (Sorry for my bad english I'm czech)

  22. #22
    Registered User
    Join Date
    Mar 2012
    Posts
    13

    Re: Vluzacn's ZHLT v33 Update

    Quote Originally Posted by vluzacn View Post
    One basic thing that no mapper or compile tool can change is that the lightmap grid in Goldsrc is tied tightly with texture scale. So small texture scales must be used if one want to get detailed lightmap. An example is "The Core" mod, where the textures are in higher resolution and are used in 0.5 scale.
    I see, thanks for your explanation. So it wouldn't be possible to maybe create a function that when compiling would automatically alter pre-defined textures (like with the creating fake lightmaps for transparent entities hack) by scaling them up by a chosen value, say a 128x128 texture to 512x512 and then down again, thus making the lightmap four times as detailed while retaining the 1:1 scale of the original texture?

    Forgive me if I'm talking nonsense here, I'm not very savvy to how things like this work on the very technical level.

  23. #23
    Registered User Kachitos's Avatar
    Join Date
    Jun 2014
    Posts
    2

    Re: Vluzacn's ZHLT v33 Update

    Great updates. I have a small issue with fake lightmap on transparent entities tho. I'm trying to use zhlt_embedlightmap on a func_illusionary with a water texture. The water texture loses it's ingame distortion animation because the name is changed from "!water" to "__rad...". Any chance that the renaming of the textures could be done with post-nominal symbols in future releases so we can keep the different functions on them (scroll, liquid, animated, transparent, etc...)?
    Ex.: "!water__rad...."

  24. #24
    Still learning wolf-3d's Avatar  
    Tester
    Join Date
    Jan 2011
    Location
    Somewhere Warm.
    Posts
    1,449

    Re: Vluzacn's ZHLT v33 Update

    Quote Originally Posted by Kachitos View Post
    Great updates. I have a small issue with fake lightmap on transparent entities tho. I'm trying to use zhlt_embedlightmap on a func_illusionary with a water texture. The water texture loses it's ingame distortion animation because the name is changed from "!water" to "__rad...". Any chance that the renaming of the textures could be done with post-nominal symbols in future releases so we can keep the different functions on them (scroll, liquid, animated, transparent, etc...)?
    Ex.: "!water__rad...."
    Nice find, it appears that something has changed between VL31 and VL33 that is causing a problem, at least for me, as I have just checked and my own "fake lights" with zhlt_usemodel to reduce model count (doing something different to you but it appears related) and they are okay in VL31 but "Solid" in VL33.
    Regards
    Wolf-3D

  25. #25
    Mapper Nih's Avatar  
    Manager
    Join Date
    Dec 2002
    Location
    Denmark
    Posts
    5,466

    Re: Vluzacn's ZHLT v33 Update

    Using one of the older versions of these tools, I have gotten used to using settings.txt to set the folders to search for .wads in, rather than setting each individual .wad in the wad.cfg and I think I prefer it. Is there any way I can use that functionality again? Was it removed and if so, could it be readded?

    Also, I have an issue with the compiler telling me that "Only one origin brush is allowed". However I can't find this origin brush... Why can't the compiler tell me which brush is causing the problem?

Page 1 of 3 123 LastLast

Posting Permissions

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