|
Posted by ericw on 2015/07/14 00:34:45 |
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. |
|
|
Re: #75/76, #77
Thanks very much for the extensive response, ericw! I'll give that a shot.
Spirit, no, I'm on Mint -- but thank you for offering.
Beta For Next Release
#79 posted by ericw on 2015/08/10 18:10:42
download
Changes since 0.15.1:
* qbsp: make "mixed face contents" and "degenerate edge" non-fatal, from txqbsp-xt
* qbsp: make "-oldaxis" the default. new "-nooldaxis" flag to get the previous behaviour.
* light: add "-surflight_subdivide" flag to control amount of surface lights created
* light, vis: use below normal process priority on Windows
* light: allow negative surface light offset
* light: ensure light values in the bsp equal the average of the lit file color components. This fixes "dark" colors (where all components are < 1), on some engines (such as MarkV), which require the bsp lightmap brightness to match the .lit brightness as a cheat prevention mechanism.
* light: fix lighting of hipnotic rotating entities.
* light: fix crash in "Bad texture axes on face:"
Thanks to everyone for testing & reporting bugs :D
Thank You!
#80 posted by mfx on 2015/08/10 18:47:23
#81 posted by Rick on 2015/08/10 21:15:17
I've run my lava map through this new lighting program about 20 times this morning and I'd have to say that the sub_divide switch has definitely helped.
There is one room with a large rectangular area of lave (320x2048) which does not get lit (well, it does but very dim). In game, r_drawflat shows this lave as one single color. I think adding some structure to break the lava surface up more will fix the problem.
I still have problems getting enough light near the lava without having it light up the entire cave, but I've got it pretty close. I'm up to wait 18 and my puny little 200 value delay 5 lava surface light still lights the the ceiling 1200 units above, but not a lot.
Negative Offset
#82 posted by Rick on 2015/08/10 22:49:28
The negative offset is very useful. You can sink the lava lights down below the surface and eliminate much of the spotty appearance, doesn't help much with default delay lights though. Those just basically paint the walls/shores up to a point then stop, which looks pretty bad, I've decided default delay is mostly useless for lava lights.
I'm working on a map for Jam 6, like so many others, and in experimenting with surface lighting using the beta Tyrutils posted earlier, I've run into a problem.
As far as I can tell, 'samples' on a light entity is being used whether 'deviance' is set or not. Even in a simple box test map, making one light and setting its texture name to the floor texture, with the deviance key either unset or set to 0, I get a certain number of total lights reported. Lowering the samples value down from its default 16 to 1 reduces the total count. With the total light count being a new addition, I can't confirm whether this is new behavior or not.
I've had one other problem, where light exits with no errors after reporting "X entities, Y are lights" but before actually computing any lightmaps, but I'm still trying to find a minimal repro for that one. The deviance/samples thing is either more pressing, or just me being an idiot, so I thought I should speak up now. Am I just misunderstanding how to use these features?
Martin
#84 posted by DaZ on 2015/08/12 05:20:48
If you are using that fgd I created for JH I strongly suggest getting the latest version at https://dl.dropboxusercontent.com/u/33279452/quake4ericwTools.fgd as an old version set _samples 16 (which is default, but doesn't need to be set by the fgd) which caused some lights to use deviance automatically.
With the new fgd this doesn't happen (but you will still need to remove the _samples key from any lights that had it assigned before you got the new fgd).
And err, if you aren't using that fgd, then ignore all of this post. YAY!
Aha
Yes, I was indeed using an outdated version of your FGD. The new one fixes it, thanks! If I may, I'd humbly suggest the tool docs and FGD be updated to clarify the _samples description, which says "Default 16 (only used if "_deviance" is set)." I didn't understand that any value of _samples activates the feature regardless of the _deviance value.
Thanks, Wiiki! (Can you guess where my username comes from? :P)
Now I just need to figure out why the beta tools are producing maps missing some textures. I'm using ID1, lavacity1a, and mapjam666 wads, and a few textures from each are missing. Others load just fine. Switch back to 0.15.1 with no other changes and all the textures show up. Any ideas?
*sigh* Of Course...
...as soon as I post I realize the problem isn't exactly as I describe. It looks like the texture thing I mentioned isn't spotty, I mistook a few textures as belonging to a different set. The problem looks like two of the three wads aren't being loaded at all, with only mapjam666 (the last one listed in worldspawn's 'wad' string) being used.
Yo
#87 posted by DaZ on 2015/08/12 14:45:11
The _samples thing iirc was a bug in the tools, the description was copied directly from Eric's site! It may already be fixed in his latest version of the tools.
Making that fgd has certainly upped my appreciation for programmers, and how they make stuff compatible across different apps/versions! What a pain in the arse :D
#88 posted by Breezeep_ on 2015/08/12 21:31:26
http://i.imgur.com/jUcJ0Jn.png
I'm not really sure why the Lighting FGD just adds these unnecessary entity keys to all the light entities in my map, and It's just tedious to remove all of these different keys.
These Seem To Be The Default Values For Those.
Are they actually in the .map file when you save it?
Default Keys Are Always Added
#90 posted by XaeroX on 2015/08/14 15:55:22
That's why they are called "default". :)
@ItEndsWithTens
#91 posted by ericw on 2015/08/14 22:28:00
I didn't understand that any value of _samples activates the feature regardless of the _deviance value.
Crap, I forgot to fix that :-(. Will fix it and put it in the next beta.
re: textures not loading with the beta, but working with 0.15.1, that is messed! Any chance you could send me the wads and map so I can double check what is going on? I don't think I changed anything that should affect texture loading.
Sure Thing!
Eric, I just sent you an email, thanks for the offer! You'll get the map, wads, and a readme with details. Hopefully I'm just doing something dumb. :)
What The Hell, Daz?
#93 posted by Breezeep_ on 2015/08/15 22:47:38
If I don't select every single light entity in my map, the lighting would end up like this: http://i.imgur.com/37pGUH0.png
Honestly, I'm getting tired of being forced to select all the light entities and removing all the unnecessary entity keys for each light. Are there any workarounds for all this crap>
Well
#94 posted by DaZ on 2015/08/15 23:11:29
are you using the latest fgd I made? https://dl.dropboxusercontent.com/u/33279452/quake4ericwTools.fgd
You don't have to use this fgd, there is a default one provided with Jackhammer. I made it for myself and thought others might find it useful!
#95 posted by Breezeep_ on 2015/08/15 23:33:17
Yeah, I'm using the latest fgd.
#96 posted by Breezeep_ on 2015/08/15 23:41:34
Is it possible to changing the defaults to 0?
Suggestion For A Dirtmap Setting
#97 posted by ptoing on 2015/08/15 23:42:07
Looking at this screenshot (also had a similar thing myself playing around with mapping recently) http://i.imgur.com/81RoXoQ.png You can see that there is AO applied at very shallow angles. Maybe something like -dirtangle [degrees] would be a good setting to add. Where of course stuff under that angle would not be dirtmapped or something like that.
Defaults
#98 posted by DaZ on 2015/08/15 23:47:58
All the values selected on the lights when you create them are the defaults.
The Default
state for any light entity is 300 light.
This is how it has always been.
Or...
#100 posted by ptoing on 2015/08/16 01:29:18
I guess not all of that stuff is from dirtmapping but just how light works. So maybe something that makes faces with angles under a certain threshold have averaged normals, basically like angle threshold controlled smoothing groups.
#101 posted by necros on 2015/08/16 01:38:47
you can reduce _anglesense below 0.5 to help alleviate the shading problem in that tube. it may make the light look a little odd because it won't attenuate based on face normal as much. might take some tweaking to look good.
#102 posted by ptoing on 2015/08/16 02:05:51
Is anglesense something you set per light?
|
|
You must be logged in to post in this thread.
|
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.
|
|