News | Forum | People | FAQ | Links | Search | Register | Log in
Tyrutils-ericw V0.15.1
Hey, I got around to setting up a website for my branch of tyrutils: (complete with lots of screenshots of different settings of AO, sunlight, etc!)
http://ericwa.github.io/tyrutils-ericw
and making an "official" release of it.

Nothing major changed compared with the last snapshot (may 1st), but a couple new things:

* .lux file support from Spike, for deluxemapping
* gamma control with -gamma flag and "_gamma" key
* rename -dirty flag to -dirt for consistency
* fence texture tracing is now opt-in only with the "-fence" flag.
* light should run a bit faster


This doesn't have lit2. Not sure what to do with that, tbh.

If there's a demand for it, I was thinking I could make a tool that upscales all textures in a wad by 2x or 4x, and adds a "-2x"/"-4x" suffix to the names. You could then manually get the higher-res lightmap on certain faces by applying the upscaled texture, and lowering the texture scale to 0.5 or 0.25 in your editor.

The only real disadvantage of this hacky method over lit2 is more face subdivision by qbsp. This isn't great, but it shouldn't be an issue if the hack is used sparingly (and bsp2 can be used if needed for higher face/vert limits.)

Anyway, enjoy, I hope this is pretty bug-free.
First | Previous | Next | Last
 
New beta:
https://github.com/ericwa/tyrutils-ericw/releases/tag/ericw-v0.15.10-beta1

Has the .map conversion feature in qbsp, so you can do:
qbsp.exe -convert valve mymap.map
and it will write out a copy of the map in Valve 220 format to mymap-valve.map. It can also convert to "quake", "quake2", "bp" (quake 3 brush primitives).

I labelled it "beta" because it's not tested enough, light has a large change to how sample points are positioned. (so unexpected black faces should never happen any more, e.g. this
My God 
so unexpected black faces should never happen any more  
Hopefully.. 
at least one of the causes is gone. 
 
I think you may have added in a cause:
0.15.9
0.15.10

Also, would it be possible to turn off the bouncing for styled lights with an option? It's causing a lot of "too many lightstyles" warnings on my map.

In more positive news, converting my map seems to have gone off without a hitch! :D 
 
So it's the black artifacts around the floor tiles? Was that shot with -extra4? I should be able to reproduce it.

re: bounce, good point, it should be opt-in, I guess. "_bounce_styled" "1" worldspawn key?

Thanks for testing and glad the .map conversion worked! It should be pretty trouble free because all the brush planes are passed through losslessly. 
 
No, no -extra4 or soft. I haven't been using those parameters as I test the map. If you like I can create a github issue with the .map and perhaps a compiled .bsp/.lit? I did just try splitting off the problem area into its own map but I couldn't even reproduce the exact lighting I have... 
 
Sure, or just emailing me the .bsp + .lit is fine too. I was just trying to reproduce it now. 
 
Also, interesting tidbit but nothing of any real issue: Converting the map to valve format through your tools seems to have reversed the order keys are listed in for TB2. Classnames are now at the bottom rather than the top. Not the case for newly created entities of course. 
Lol 
thanks for noticing that, should be harmless but I'll fix it! 
Question 
Can sunlight be assigned a lightstyle? Thinking it could be cool to fade it in/out via QC. 
Not Atm 
It's really easy to add though, i'll add it after fixing Pritchard's issue. 
Whoa 
Can sunlight be assigned a lightstyle?

Man that could open up some interesting visuals. 
 
It's really easy to add though, i'll add it after fixing Pritchard's issue.

Cool! Sounds like a good addition

Man that could open up some interesting visuals.

Random dipping of light from clouds in an overcast sky...the strange pulsing of an alien sun...a simplistic day/night cycle (obvs no moving shadows but whatevs, it's not as if you can animate the skybox)...

You could sync up the light variation with some variation in the fog and skyfog settings to sell the effect better.

I did think it might be interesting if it was possible to have multiple different sunlight setups, all on a unique lightstyle (well you'd be limited to 3 I think) - morning, midday, evening - and you lerped their light intensities in QC (along with "night", but that wouldn't be a lightstyle, just an absence of light). But that's probably overkill and the shadows might still look odd.

I'm not really sure what the performance implications are with massive amounts of lightstyled surfaces though. Are there any these days? 
 
I just looked up how lightstyles work, is there any limit to the length of the string? Or could you actually have a light that took a really long time to complete it's cycle? That would be a lot of letters...

Also seriously? It's done with letters of the alphabet??? 
#783 
Yeah, you can set up those strings and have the light cycle automatically, or you can just set a single brightness value explicitly (e.g. say you wanted a slow day/night cycle thingy, I guess you'd want to set up a slow think function and increment the brightness in the think) 
Clipnodes 
Uhm, how come this QBSP generates a whooping 11k more clipnodes than other compilers on my map?! 
@negke 
Hmm, I don't remember touching anything related to clipnodes since this forked from tyrutils.

I just tried compiling ad_zendar.map and it looks like I can reproduce that:

bjptools_xt_290914_phong2: 38011 clipnodes
tyrutils-ericw_0.15.10_beta1: 44953 clipnodes

So it's producing 18% more clipnodes than bjptools_xt. Is that the same kind of percent increase you're seeing / what are the total numbers of clipnodes? 
 
Around 41% in my case if my math is correct.

bjptools_xt 1.2.5: 27174 clipnodes
tyrultils_ericw 0.15.9: 38372 clipnodes

(Also roughly 700 more marksurfaces with tyrultils) 
Fun Fact 
Hmap2 produces an even higher count: 43601

So it's settled then: Bengt Jardrebb ftw! 
 
I don't mind using the old txqbsp_xt in order to not exceed the standard marksurfaces limit, but I'd like to use this light.

I was wondering if the problem of light not passing through sky had been fixed. 
 
Negke thanks for the info, I'll look into optimizing the clipnodes sometime.

Rick: sometimes this qbsp will produce fewer marksurfaces, so try both.

About making ordinary lights go through sky faces, I tried it a while ago and I don't think it's worth the code complexity, and it caused a significant slowdown.

If I added a way to add entities to specify multiple suns would that help? Alternatively just make a hollow box connecting to the window, it should only add 1 extra leaf and a few sky faces. 
Beta 
Tried latest beta and I receive too many light styles on faces when I didn't on the latest stable version. Going to assume that's with styles now bouncing?

A few notable black faces I was keeping track of are still showing as pure black. Just reporting! 
 
latest build from here has a bug.
Rotate_object arent lit, leaves them all black. 
Thx 
i'll look into it. The git master and 0.15.10-beta1 versions of light are half-baked at the moment, I recommend the stable version 0.15.9. 
Light Absorption For Deep Liquids 
When a deep lake full of mud or slime is in a very bright area, the lighting from the outside will illuminate it as if the liquid didn't exist. This is specially true for lakes under open skies with sunlight.

How complicated would it be to implement an option in the light tool for underwater faces to receive gradually less light according to their distance from the water surface?

I suppose it could work this way:
1) If the face is underwater, check if the light entity is not underwater;
2) If the light entity is not underwater, make a list of all liquid surfaces between it and the underwater surface;
3) For each ray, check which liquid surface in its path is closest to the light entity;
4) Calculate the distance from the liquid surface to the underwater face, and use it to reduce the brightness received by the lightmap.

Note: Light entities placed underwater shouldn't be affected by this, because their underwater brightness was deliberately set by the map author.


I think this feature could be very useful, specially in areas with both water and slime - the slime would look more muddy than the water, because the bottom of it would be harder to see.

Maybe this could be implemented through an entity field in func_detail liquid brushes. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.