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
 
Tried implementing it, download available on the github issue

It might be handy for Quake too.
Hope I did it right.. if there is a brush in a brush entity with the "origin" texture, the center of that brush is used as the model origin (qbsp translates the model so that point is at 0 0 0, and sets the "origin" key).

Also light no longer cares about the classname starting with "rotate_", if the brush entity has an "origin" key set to something other than "0 0 0", the faces will be translated to that position during lighting (hopefully doesn't break anything?) 
Im Wondering 
Is there a standard for final compile settings? I assume people leave BSP and VIS parameters alone, except maybe -bsp2 for BSP? Is that something everyone uses, or only if the map somehow doesn't compile as a regular BSP? Is there any reason not to use BSP2?

For light, judging by the doc page on Eric's site, I'd guess people use -extra4, -gate 1, -bounce 1, and maybe some -soft? 
Final Compiles 
Yeah, the main thing is to use -extra4 on light; the other tools can stay with the default settings.

-gate 1 is probably fine but it's actually a faster/lower quality option than the default. -bounce 1 is something you want to use from the beginning if you are going to use it, since it'll change the entire look of the map. -soft is personal taste, it will make the final lightmap softer.

Is there any reason not to use BSP2?
It's best not to use the -bsp2 flag unless it's needed so the map will run on the widest range of engines (including vanilla ones). qbsp will print an error if the map exceeds limits so that it requires -bsp2. 
Also 
-bouncescale .8 or so? What about sunlight and dirt settings in the worldspawn? 
 
Tougher to generalize as those are more artistic choices. The screenshots / settings on the website give some starting points, you can also check map sources for ideas. 
Yeah 
I did check out some of the AD maps and was surprised to find very little dirt is used. Judging by the 1000 Cuts screenies I'd expect a lot more dirt, but maybe that's because of the greyscale. Sock seems to use 96 dirt, I'd think an intermediate between 256-512 would look nice. 
 
Sock seems to use 96 dirt, I'd think an intermediate between 256-512 would look nice.

Sock's 96 dirtdepth is not a bad value actually. A dirtdepth of 256-512 is something that works when looking at a distant shot of an otherwise fullbright map, like in the preview image on ericw's page. For a normally lit map, it means surfaces 256-512 units away will be darkening your target surface, which can just suck all the light out of interior rooms quite easily. 
Kinn 
I know it's probably a good value; Sock chose it. I have no Quake experience so all I have to go on are Eric's pics and various worldspawns. I need to jump in and make myself a test map. 
 
I prefer to set things like bounce in worldspawn and keep my compilation configuration as "universal" as possible. I just use -extra4 and -soft on my light config, and I usually use bsp2 for qbsp because what current engine doesn't support it, anyway? 
Lol... 
Don't use bsp2 if you don't need it. 
Pritchard 
You can use the bounce parameters in the worldspawn? It doesn't say that on Eric's site. 
 
Yeah, i'm pretty sure. Also, because of otp, i'm only going to release my maps in bsp2 from now on. (Not that I release any maps...) 
#665 
Same. I only use in my compilation setup are the ones that can ONLY go in there. Otherwise the rest go in worldspawn.

Actually, speaking out loud, I need to add those to my .fgds. 
Derp. I Meant #668 
 
#669 
I have .fgd with all Tyrutils-ericw options for my JACK setup, should be easy to transfer to TB2 if you want. 
Wait 
You can put this stuff in the fgd? How are you doing that? 
#672 
Open the .fgd with a text editor and add/edit worldspawn fields like you would with any other entity. 
 
You can use the bounce parameters in the worldspawn? It doesn't say that on Eric's site.

Good spot. Looks like the "Worldspawn Keys" section needs updating http://ericwa.github.io/tyrutils-ericw/doc/light.html 
So Then 
Which fgd are you guys using? I have a quake.fgd that came with JACK and then the AD fgd. 
Dirty Choices 
I did check out some of the AD maps
Every mapper did their own thing and there are some who did not use detail brushwork or utilize lit files. Personally I compiled all my maps in AD with dirt parameters which are setup on the worldspawn so everyone can reproduce the results for themselves.

Sock seems to use 96 dirt
Its dangerous to take that parameter in isolation because the dirt AO system has several parameters which all play key roles in how the dirt is applied. You also need to remember the dirt parameters work with 2 other key systems, architecture and light entities!

I did countless tests with the new dirt AO system and found I wanted a strong dirt in corners that worked with finer brushwork detail. I also only added dirt to strong light source (excluded from all small/ambient light sources) and excluded it from most func bmodel entities.

There are many examples of different ways to setup lights and I would highly recommend anyone to look at Honey by CZG and The Hell that's coming by warrenm because both have source files included.

Honey uses strong point lights with many low fill (delay5) ambient lights and THTC uses many strong fill (delay5) lights for large windows and subtle fill lights for the rest. Both systems have different advantages and both create a different atmosphere. They are both pre dirt AO options, but they are useful for understanding lighting.

The final piece to the puzzle is architecture and in my AD maps I often have _dirt and _minlight parameters on bmodels and certain architecture to correct the overall dirt parameters I use. Its impossible to expect one global setting will fix all light issues and that is why I requested Eric add the ability to all map entities to switch lighting features on/off.

I also recommend everyone stop using the compiler for options and use the worldspawn instead! Why you might ask? Well so that everyone can learn from your source maps and try to understand how you did things.

I usually use bsp2 for qbsp
As I have said to Eric, this parameter should be on the worldspawn, it is really annoying to have to keep switching stuff around for different maps. The more parameters on worldspawn the better.

Which fgd are you guys using? I have a quake.fgd that came with JACK and then the AD fgd
Just edit/update either file with all the extra stuff you want. You can open a FGD in a text editor and cut and paste stuff around. Jack will run an error check on the file for you when it loads up a map, so its easy to spot errors. The format is not overly complex, the AD version should have plenty of examples of how to use the 'base' function and syntax formats for entity key types. 
Back To Front 
I also only added dirt to strong light source (excluded from all small/ambient light sources)
Sorry it is the other way around, I have not checked my parameters in a long time because I just use the same setup each new map.

Strong source lights = no dirt
Ambient source lights = AO dirt

The dirt is excluded from the strong light sources so that you get the hotness effect around lights. Remember Dirt AO will make every surface look darker and make strong lights sources feel dull.

Here is some more lighting tips to think about. 
 
I also recommend everyone stop using the compiler for options and use the worldspawn instead! Why you might ask? Well so that everyone can learn from your source maps and try to understand how you did things.


That's a really good point. 
Also 
Having as many compile settings as possible inside the map file makes it much more portable.

Imagine working on the map on different PCs (cheeky bit of lunchtime mapping at work anyone?) or on different editors, or after upgrading editors.

If as many settings as possible are properties of the map file, then it should reduce the time it takes you to sync up your settings across different environments.

That would be ideal anyway. 
 
It seems the only ones that ARENT worldspawn are things like -extra/-extra4, -lux, -onlyents... things that arent followed by some sort of value.

is it possible to convert these to be usable as worldspawn as well? 
Well... Not So Fast 
If the idea is that you find a good value and keep it for that map - no matter what sort of compile you are doing - then it's a property of the map and it should be a worldspawn value (sunlight, dirt blah blah)

If it's a setting that you keep changing to do different types of compiles (e.g. fast / final / onlyents /dirtydebug etc. ), then it's not a property of the map, and thus should remain as a commandline switch 
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.