Thread: [ARCHIVE] Custom ZHLT by vluzacn

Page 12 of 33 FirstFirst ... 2891011121314151622 ... LastLast
Results 276 to 300 of 825
  1. #276
    QPU-aligned Silencer's Avatar  
    Contributor
    Join Date
    May 2006
    Posts
    6,083

    Re: custom version of ZHLT by vluzacn

    Yeah the effects keyvalue works nicely for dynamic light. It's pretty uncostumizable unfortunately. (Though the engine DOES support varying brightness, color and flickering effect) Still, it throws no shadows.

    When I was talking dynamic lights, I meant toggleable lights/lightmaps all the time, btw; in case that was confusing.

  2. #277
    Registered User
    Join Date
    Oct 2002
    Location
    Socal
    Posts
    49

    Re: custom version of ZHLT by vluzacn

    Of which entity are we speaking? If I use a light or a light_spot, and give it some flickery values, the flickers cast shadows in the generated light maps, but they still count against the max light styles. :/






    (255 58 36 200, Slow, Strong Pulse [style 2] - VHLT compile)
    Last edited by Thothie; 10-06-2011 at 09:47 PM.

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

    Re: custom version of ZHLT by vluzacn

    Quote Originally Posted by Thothie View Post
    Of which entity are we speaking? If I use a light or a light_spot, and give it some flickery values, the flickers cast shadows in the generated light maps, but they still count against the max light styles. :/

    (255 58 36 200, Slow, Strong Pulse [style 2] - VHLT compile)
    Arbitrary visible entity (must has an origin). Set the value of its 'effects' key to 4 or 8.

  4. #279
    Registered User
    Join Date
    Jan 2011
    Posts
    32

    Re: custom version of ZHLT by vluzacn

    Hi there, I have a question to make, I noticed that in these compilers faces assigned with a texture light will come out extremely bright, brighter than ZHLT 3.4 and since I am using a modified GoldSrc version which already increases global gamma around texture light faces will come even brighter, I wonder if there is a way to cap brightness for these faces, because their so bright it even hurts sometimes lol.

    I left an attachment showing how bright it looks.
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	hlep2_aft040001.png 
Views:	187 
Size:	287.3 KB 
ID:	14664  

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

    Re: custom version of ZHLT by vluzacn

    why dont you just turn down the texture light brightness?
    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 ]

  6. #281
    Registered User
    Join Date
    Jan 2011
    Posts
    32

    Re: custom version of ZHLT by vluzacn

    I don't think that works, regardless of light brightness the face always seems to come out like that, but even if it does work I need an alternative because the overall lighting is just perfect right now I wouldn't like to mess with it. I am not using the info_texlight entity by the way that is just a regular func_wall.

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

    Re: custom version of ZHLT by vluzacn

    i am also not using info_texlight but lights.rad and when i switched to vluzacn's tools, i also had to reduce the texlight brightness.
    other lights should not be affected because it's a texlight - it depends on the texture.
    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 ]

  8. #283
    Administrator AdamR's Avatar  
    Manager
    Join Date
    Mar 2004
    Location
    Cardiff, South Wales [UK]
    Posts
    8,606

    Re: custom version of ZHLT by vluzacn

    ^ that.
    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

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

    Re: custom version of ZHLT by vluzacn

    Okay turns out I was wrong, I can actually make the face less bright by decreasing the value in lights.rad but like I was expecting, lighting becomes dim, I just was just wondering if there would be a way to do so, but not actually affecting the lighting caused by that one texture light I want brightness to be lower in.

  10. #285
    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
    Hi there, I have a question to make, I noticed that in these compilers faces assigned with a texture light will come out extremely bright, brighter than ZHLT 3.4 and since I am using a modified GoldSrc version which already increases global gamma around texture light faces will come even brighter, I wonder if there is a way to cap brightness for these faces, because their so bright it even hurts sometimes lol.

    I left an attachment showing how bright it looks.
    The problem is, the entire texture is bright.
    Solution:
    Build a texture that represents the amount of light emitted from that like this (attachment).
    Place it 1 unit in front of original texture with rendermode 'additive'. Then add texlight for this texture and remove the texlight of original texture.
    Attached Images Attached Images  

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

    Re: custom version of ZHLT by vluzacn

    Okay thanks for the tip.

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

    Re: custom version of ZHLT by vluzacn

    Hi Vluzacn,

    Futher to your discussions with AdamR as per 8/6/11 post 262 or below.

    You might want to know I had a bit of a strange one with texture limits / reporting differences between compiler and hammer.

    Firstly the line of code added by adam is partially in the compiler allready:

    textures 498/512 498/512 (97.3%)
    498 textures referenced

    My strangeness was that I added a new wad to hammer, then used 1 texture from the new wad and did a compile. (prior I was at 496 textures referenced as per VL23 and at 410 unique textures per Hammer 3.4/3.5

    After the additional one texture I was over the limit of 512, so I assumed it was to do with animating textures (1 texture could have 3 or more animations ?) or duplicate textures within existing wads and the new wad.

    However the test I did threw up something different. Removed all but one wad texture from hammer. The created a new map/box room using one non animating texture, player start + light. Hammer reports 1 texture, VL23 says 3 textures. (didn't bother with trying an animating texture or simulating duplicates as I have no idea what is going on.)

    Anyway just a heads up that something different is happening between hammer and the VL23. (NB: Also note there could be some corruption of my system or a general cock-up on my side, so i would confirm the differences.)

    As always there is a simple work around that I can use in the meantime, so no priority or rush to look at it.

    regards
    Wolf-3D

    Quote Originally Posted by AdamR View Post
    Got your VL23 code compiled and working Vluzacn -- I see you've done more lighting fixes, my light_spot's are producing light with less black patch problems (nearly none at all now).

    I do have an issue though. In the screen shot, the room in the white border does not get compiled correctly. It's the newest room in the map. The room has some buttons in, and the room itself is there and working, but all the textures inside are null'd out. I can no-clip to the room and walk inside, and use the buttons (as I know where they are).

    I thought this could be because I was exceeding MAX_MAP_TEXTURES, so I changed just a few to get me down to 511. The map compiles fine, but didn't fix the issue. I compiled my custom ZHLT 3.4 code to allow more than 512 textures (as it claimed I had 513 in the map rather than 511 yours did), the map compiled fine, but more importantly ran fine in game -- nothing null'd out.

    Edit: This happens on VL20 too.

    Do you have any idea what could be causing this? Here is the final BSP memory chart (ignored HLRAD stage)
    Code:
    Object names  Objects/Maxobjs  Memory / Maxmem  Fullness
    ------------  ---------------  ---------------  --------
    models            298/512        19072/32768    (58.2%)
    planes           6628/32768     132560/655360   (20.2%)
    vertexes        35959/65535     431508/786420   (54.9%)
    nodes           14876/32767     357024/786408   (45.4%)
    texinfos         1899/32767      75960/1310680  ( 5.8%)
    textures          498/512          498/512      (97.3%)
    faces           26955/65535     539100/1310700  (41.1%)
    clipnodes       26198/32767     209584/262136   (80.0%)
    leaves          10256/32767     287168/917476   (31.3%)
    marksurfaces    36419/65535      72838/131070   (55.6%)
    surfedges      126122/524288    504488/2097152  (24.1%)
    edges           63104/262144    252416/1048576  (24.1%)
    texdata          [variable]    2061028/33554432  ( 6.1%)
    lightdata        [variable]          0/33554432  ( 0.0%)
    visdata          [variable]     843552/2097152  (40.2%)
    entdata          [variable]     326881/524288   (62.3%)
    498 textures referenced
    === Total BSP file data space used: 6113677 bytes ===
    That "texttures 498/512" line is one I added if you want it for your own code.

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

    Re: custom version of ZHLT by vluzacn

    Did some more playing around and on what appears to be standard textures (no + - { or [ in front of the names some times VL23 reports multipule textures used sometimes agrees with hammer. (I am guessing compiler is correct and creators of textures got naming wrong.) My Appologies on that.

    I have also noticed that both hammer and VL23 appear to be counting non-rendered textures. For example I use a lot of different aaa_textures, several versions of hint, clip etc.
    (which is adding to my used texture limit but helps to navigate design).

    Regardless have removed two animating textures from real map and reduced the count to 500 textures referenced.
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	temp.jpg 
Views:	118 
Size:	65.2 KB 
ID:	14669  

  14. #289
    Administrator AdamR's Avatar  
    Manager
    Join Date
    Mar 2004
    Location
    Cardiff, South Wales [UK]
    Posts
    8,606

    Re: custom version of ZHLT by vluzacn

    Quote Originally Posted by wolf-3d View Post
    aaa_textures
    AAATRIGGER is completely redundant. If your trigger is visible you'd use a regular texture, but if not you should use NULL. AAATRIGGER is invisibly rendered, NULL is not.

    ANY brush you don't intend to be visible in game should wield the NULL texture.
    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

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

    Re: custom version of ZHLT by vluzacn

    Quote Originally Posted by wolf-3d View Post
    Did some more playing around and on what appears to be standard textures (no + - { or [ in front of the names some times VL23 reports multipule textures used sometimes agrees with hammer. (I am guessing compiler is correct and creators of textures got naming wrong.) My Appologies on that.

    I have also noticed that both hammer and VL23 appear to be counting non-rendered textures. For example I use a lot of different aaa_textures, several versions of hint, clip etc.
    (which is adding to my used texture limit but helps to navigate design).

    Regardless have removed two animating textures from real map and reduced the count to 500 textures referenced.
    yeah, as of animated or tiled textures every frame counts. hammer is rather silly there, counting only the one you put on the face.
    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 ]

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

    Thumbs up Re: custom version of ZHLT by vluzacn

    Thanks Puchi & AdamR,

    WRT
    Quote Originally Posted by AdamR View Post
    AAATRIGGER is completely redundant. If your trigger is visible you'd use a regular texture, but if not you should use NULL. AAATRIGGER is invisibly rendered, NULL is not.

    ANY brush you don't intend to be visible in game should wield the NULL texture.
    Confirmed AAATRIGGERS-> to Entity-> to Trigger adds to my model count and Texture usage in Hammer & VL23, whereas NULL texture -> to Entity-> to Trigger adds to Model count in VL23 only. (In Hammer it adds to both.) Thanks for the insight, will try and add back some textures as VL23 determines what will load/run

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

    Re: custom version of ZHLT by vluzacn

    Use the texture replace tool

    Does Vluzacn's ZHLT have a copy brush feature that Silencer added to his?
    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. #293
    Still learning wolf-3d's Avatar  
    Tester
    Join Date
    Jan 2011
    Location
    Somewhere Warm.
    Posts
    1,482

    Re: custom version of ZHLT by vluzacn

    WTF 2nd line did not appear on my screen until, I choose quote/reply.
    PM or something ? or have I got some sort of glitch.

    Quote Originally Posted by AdamR View Post
    Use the texture replace tool

    Does Vluzacn's ZHLT have a copy brush feature that Silencer added to his?
    Whatever I guess you are refering to "texture replace tool" in hammer or are you saying it is possible to use Wally + PSP etc to replace the AAA_triggers with the attributes of NULL but retain the outward appearance of the AAA_texture. (If that makes any sense what so ever) but I kind of know what I mean. Just don't know if it is possible. For example I know that to get "weapon_grapple" to attached/rappel you need a "Special texture" (just don't know how to make my own one).

  19. #294
    QPU-aligned Silencer's Avatar  
    Contributor
    Join Date
    May 2006
    Posts
    6,083

    Re: custom version of ZHLT by vluzacn

    NULL-texture being stripped is a compiler-thing. There are no texture attributes other than those hinted at by their name. (starting with "+"/"-"/"!"/etc.)

    And Vluzacn does have something similar to copy_brush. He implemented it differently. Browse the thread.

  20. #295
    Administrator AdamR's Avatar  
    Manager
    Join Date
    Mar 2004
    Location
    Cardiff, South Wales [UK]
    Posts
    8,606

    Re: custom version of ZHLT by vluzacn

    I'm not reading through 15 pages ¬_¬ the first post also isn't too clear.

    Do I just make a null box and give it "zhlt_usemodel" and "zhlt_copylight" and set the value to the source entity to copy? Does this copy it in a way that texture lights will be applied to the cloned brush?
    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

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

    Re: custom version of ZHLT by vluzacn

    Quote Originally Posted by wolf-3d View Post
    Hi Vluzacn,

    Futher to your discussions with AdamR as per 8/6/11 post 262 or below.

    You might want to know I had a bit of a strange one with texture limits / reporting differences between compiler and hammer.

    Firstly the line of code added by adam is partially in the compiler allready:

    textures 498/512 498/512 (97.3%)
    498 textures referenced

    My strangeness was that I added a new wad to hammer, then used 1 texture from the new wad and did a compile. (prior I was at 496 textures referenced as per VL23 and at 410 unique textures per Hammer 3.4/3.5

    After the additional one texture I was over the limit of 512, so I assumed it was to do with animating textures (1 texture could have 3 or more animations ?) or duplicate textures within existing wads and the new wad.

    However the test I did threw up something different. Removed all but one wad texture from hammer. The created a new map/box room using one non animating texture, player start + light. Hammer reports 1 texture, VL23 says 3 textures. (didn't bother with trying an animating texture or simulating duplicates as I have no idea what is going on.)

    Anyway just a heads up that something different is happening between hammer and the VL23. (NB: Also note there could be some corruption of my system or a general cock-up on my side, so i would confirm the differences.)

    As always there is a simple work around that I can use in the meantime, so no priority or rush to look at it.

    regards
    Wolf-3D
    Textures that are not referrenced by any visible face are removed in the end of hlbsp compiling. See "Reduced xxx textures to xxx" in the log. If the number of textures before reducing is over 512, hlcsg will error out.
    I should have made hlcsg to allow more that 512 textures, but I thought no one will use that many textures.

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

    Re: custom version of ZHLT by vluzacn

    Quote Originally Posted by AdamR View Post
    AAATRIGGER is completely redundant. If your trigger is visible you'd use a regular texture, but if not you should use NULL. AAATRIGGER is invisibly rendered, NULL is not.

    ANY brush you don't intend to be visible in game should wield the NULL texture.
    Should the compiler change all aaatrigger textures to NULL?
    A downside is that they will not be visible in bspviewer.

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

    Re: custom version of ZHLT by vluzacn

    Quote Originally Posted by AdamR View Post
    I'm not reading through 15 pages ¬_¬ the first post also isn't too clear.

    Do I just make a null box and give it "zhlt_usemodel" and "zhlt_copylight" and set the value to the source entity to copy? Does this copy it in a way that texture lights will be applied to the cloned brush?
    Add [key: zhlt_usemodel value: name of the source entity] to the target entity. Both source entity and target entity should have origin brush or be point entiy.
    'zhlt_copylight' is a hack to correct brightness of mdl placed in the map by changing the color of face lightmap sample under the mdl. It is not useful in your case.
    A sample map of 'zhlt_usemodel' (in attachment):
    Attached Files Attached Files
    Last edited by vluzacn; 25-12-2011 at 09:22 AM. Reason: Forgot attaching sample map

  24. #299
    I am yummy LemonSoda's Avatar
    Join Date
    Jul 2007
    Location
    Finland
    Posts
    719

    Re: custom version of ZHLT by vluzacn

    Could you make VHLT so that it wouldn't create "mixed face contents" errors when I use null texture on non-visible faces of doors and other visible brush entities? Now the only reason I'm using SHLT to compile my map is because it allows these brushes. Or are the null textured faces rendered on visible brush entities like normal textures and don't work normally there at all?

  25. #300
    Administrator AdamR's Avatar  
    Manager
    Join Date
    Mar 2004
    Location
    Cardiff, South Wales [UK]
    Posts
    8,606

    Re: custom version of ZHLT by vluzacn

    Quote Originally Posted by vluzacn View Post
    Textures that are not referrenced by any visible face are removed in the end of hlbsp compiling. See "Reduced xxx textures to xxx" in the log. If the number of textures before reducing is over 512, hlcsg will error out.
    I should have made hlcsg to allow more that 512 textures, but I thought no one will use that many textures.
    Polar Rescue is at 511
    Using ZHLT 3.4 or SHLT it's at 510, but stays like that to the end. Your tools claim there to be 511 at CSG stage but then strips out a few, down to 508 I think. I guess we could ignore the limit until everything that needs to be stripped out has been?

    Quote Originally Posted by vluzacn View Post
    Should the compiler change all aaatrigger textures to NULL?
    A downside is that they will not be visible in bspviewer.
    Personally I'd say yes, but add a parameter to not do it. Other mappers may object to this though.

    Quote Originally Posted by vluzacn View Post
    Add [key: zhlt_usemodel value: name of the source entity] to the target entity. Both source entity and target entity should have origin brush or be point entiy.
    'zhlt_copylight' is a hack to correct brightness of mdl placed in the map by changing the color of face lightmap sample under the mdl. It is not useful in your case.
    A sample map of 'zhlt_usemodel' (in attachment):
    Works. I did need to copy lighting too as the models are func_trains, and only the template model has lighting (it contains texture lights).

    One thing I noticed is that after the model has (successfully) cloned, texture lighting does not happen from the cloned model position. Is it possible to do this? I may need to PM you to explain further what I intend to create.

    Quote Originally Posted by LemonSoda View Post
    Could you make VHLT so that it wouldn't create "mixed face contents" errors when I use null texture on non-visible faces of doors and other visible brush entities? Now the only reason I'm using SHLT to compile my map is because it allows these brushes. Or are the null textured faces rendered on visible brush entities like normal textures and don't work normally there at all?
    Those mixed face contents messages are only warnings to tell you that something may not work properly in game. I've never encountered this warning to prevent a map compile though. When I was compiling Royals2 for you I had a few of these, but none of them threw any errors to stop the map from compiling.

    SF me if it is causing problems

    Content types are as follows (can be used in map entities that have the contents property):

    CONTENTS_EMPTY = -1 (NULL texture uses this)
    CONTENTS_SOLID = -2
    CONTENTS_WATER = -3
    CONTENTS_SLIME = -4
    CONTENTS_LAVA = -5
    CONTENTS_SKY = -6
    CONTENTS_ORIGIN = -7 (removed at CSG)
    CONTENTS_CLIP = -8 (converted to solid, only used if a custom hull is used)
    CONTENTS_CURRENT_0 = -9
    CONTENTS_CURRENT_90 = -10
    CONTENTS_CURRENT_180 = -11
    CONTENTS_CURRENT_270 = -12
    CONTENTS_CURRENT_UP = -13
    CONTENTS_CURRENT_DOWN = -14
    CONTENTS_TRANSLUCENT = -15
    CONTENTS_HINT = -16 (converted to empty by BSP, engine never sees this)
    CONTENTS_NULL = -17 (removed by CSG and BSP)
    CONTENTS_DETAIL = -18 (detail textures? not sure)
    CONTENTS_BOUNDINGBOX = -19 (similar to origin)
    CONTENTS_TOEMPTY = -32 (empty brush)

    As it happens a brush entity mixing regular textures and null textures does not appear to have any negative side effects. I checked out the compiles of Royals2 and none of the brush entities in question had any bad rendering, they were all as you intended. If there are no objections I guess we could add a sub-condition to ignore this warning if the contents are a regular texture and a null texture.
    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

Posting Permissions

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