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!)
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
Mostly a bug fix update:

- light: add "_sun" entity key to configure sunlight in an entity instead of worldspawn. More than one "_sun" entity is supported.
- light: add "_falloff" light entity key to configure light falloff in map units. Only supported on linear (delay 0) lights.
- light: add "_spotlightautofalloff".
- light: fix light cutoff on curved surfaces
- light: adjust -soft to fix regression in 0.15.10
- qbsp: add "_mirrorinside" key for mirroring the outside faces of bmodels so they are visible from inside. for func_water, or func_illusionary fences, etc.
- qbsp: fix CSG issue with overlapping off grid brushes
- qbsp: fix HOMs introduced in 0.15.10, which were caused by an attempt to fix leaks-through-solids in 0.15.10. To re-enable the buggy code that may fix leaks through solids but add HOMs, use "-contenthack"

Thanks for everyone who reported bugs and m-x-d for the contributions to light :)

Btw - I want to rename the project at some point, any suggestions? something that doesn't have my name in the title, haha. 

or LUMEN for short 
Just call it tyrutils-0.16 to confuse everyone and annoy tyrann (if they're still alive)

I'll have a look to see if the bugs are fixed for me yet, fingers crossed :)
Also, what's the purpose of _sun on an entity? And the purpose of having more than one? 
Yay Thanks 
Lame Name ideas:
Wizann (ericw the wizard + Tyrann)
Map2Bsp (lame i know)

I had been using an older light it seems for the black faces bug. I'll let you know if I run into anymore bugs. 
Yeah - it's time to bump the version to 0.16 soon. I don't want to use "tyrutils" since that makes it sounds like tyrann endorses the tools, I think I have a good name idea though.

I'll have a look to see if the bugs are fixed for me yet

Also, what's the purpose of _sun on an entity? And the purpose of having more than one?
Just convenience, really - figuring out _sun_mangle is a pain; this way lets you target an info_null to set the sunlight vector. It doesn't enable any new features that you can't do with the worldspawn keys, currently.
However, there are some things that would be easier to do with sun settings on entities, one that comes to mind is having a targetname to make them toggle-able (you could totally fade the sunlight with QC if that was implemented.)

Having more than one sun entity is for when your skybox has 2 suns on it. :D 
YAQC - Yet Another Quake Compiler 
Has anyone done this name yet? I've used a lot of "Yet Another X" software over the years.

Other ideas:
QTOOLS - already used for a few projects sadly, but not quake ones.
func_compiler - ???
ericutils - because I know you mentioned not wanting to, but it's TRADITION, DAMMIT!
W(X) - WQBSP, WLIGHT, WVIS etc. Another name reference but a subtle one.

There have been a lot of different tool packages over the years. Most of them have been branded with their author's name, sadly.
It's hard to be creative about something so clinical. 
I can't pretend I'm an engineer or anything, but the urge to come up with cute names for things was irresistable, so I spent a few minutes doing a little research.

Your toolset is aimed at letting people prepare their architectural designs for a Quake, so how about "Strand" or "Tendon"?

I tried working in some reference to Tuned Mass Dampers at first, mainly because I like the phrase, but nothing catchy or meaningful was forthcoming. Maybe somebody else can run with that. 

Believe, BeLieVe or Be_Lie_Ve (Bsp, Light Vis)

Quandary (because you have so many options in LIGHT utils!) 
Quake Is Brown, So 
BrownBrush (bsp)
BrownEye (vis - eye, visibility, geddit?)
BrownStar (light - starlight I guess) 
Brown eye? really??? hahah 
CLEric (compiling & lighting from Eric)


Grammaton Cleric 
Func_compiler Has Several Votes Now 
I'm proud of myself :3c 
Summoning Great Strength 
eQtools. Erics Quake Tools. 
What's wrong with ericw-tools? 
"func_compiler" does have a certain charm.

Or maybe "qompiler" although perhaps that's too vulnerable to typos?

Trying to think of other terms besides "compile"... "quakebake"? 
One I thought of was "arcaneutils".
"ericw-tools" is nice and straightforward though.
"func_compiler" is good, disadvantage is it's hard to say and it would be hard to read without the underscore (e.g. funccompiler). 
God no... 
Just Pick A Simple Grim, Quakey Word And Stick "tools" On The End 

you get the idea 
Definately "Browntools" 
funcTools functools
funcUtils funcutils
fooTools footools
kungfew kungfew 
Arcaneutils is ... ich. The eu in the middle alone is distasteful, let alone the confusion with AD. Plus its so long and just not catchy. Func_compiler is cool, but also long.

func_piler maybe
Arctane maybe
Qtils (q utils)
Lichtools (off the infamous nonexistent Lich Fiend)

Maybe just Func_tools:
The Compiler of Erich Zann

The Tools That Compiled Sarnath 
I like ClEric and Qompiler (maybe shortened to Qompil?). Putting a Q instead of an initial C is a Quake tradition and it would be a nice nod to it.

I agree with Qmaster that Arcaneutils is meh for the exact same reasons. Oh, and whoever came up with The Compiler of Erich Zann is an evil genius! Reminded me of a Mekong Delta album. 
I have a batch file called qompiler :P

its kind of broken right now though. 
I Knew It Sounded Familiar! 
Map jam where every map title is a possible toolset name and the best map wins the right to name the tools

Cue "penispiler" 
The Lesson To Be Learned 
Don't ask Func for name/theme/feature suggestions... 
Better End The Suggestion Period 
ok - scratch arcaneutils. Thanks for the ideas.
probably "ericw-tools" is the pragmatic choice becuase I've heard people refer to it as that anway.. hm. 
You've added so much to TyrUtils that your fork is not really Tyrann's anymore. It deserves your own brand. 
Keep Your Name In It 
It's casual and easy to remember. Plus reminds everyone who's working on it. 
If a func_wall entity has skip-textured faces that goes deep inside the world's brushes, crossing multiple VIS areas, will said entity be "visible" across all those VIS areas, even though it has no faces to render in there?

Maybe this is more of an engine problem. 
I am guessing "yes" they will be visible. skip faces are deleted towards the end of qbsp so they're included in the model mins/maxs - I think.

To optimize for this case I think the engine could build a tighter visible mins/maxs by iterating over all faces/vertices of the model. 
I am guessing "yes" they will be visible. skip faces are deleted towards the end of qbsp so they're included in the model mins/maxs - I think.

To optimize for this case I think the engine could build a tighter visible mins/maxs by iterating over all faces/vertices of the model. 
the qbsp must(imho) calc model bounds according to the maximum of both rendered geometry as well as related collision structures.

Failure to account for collisions means you'll end up missing initial collisions, resulting in entities getting stuck and unable to leave again (more than just a precision error). This is true (although perhaps rarer) even in vanilla. 
played with _falloff, its pretty damn handy. is support for the other delays feasible? 
It should be possible to support for delay 1/2/5 as well. it would be a bit different for these because they extend forever, so maybe "_falloff" would set the distance where they hit 1/255 brightness, or something? 
Shadows On The Snow... 
Using TyrUtils v0.15.11, working on my Frozen map and have encountered some strange shadows. Look at the rock shadow just below the crosshair, this occurs in a few places in the map, the shadow is not very soft and has harsh transition between dark and soft:

Current settings:
sunlight: 200
sunlight_color: 211 163 139
sunlight_mangle: 90 -55 0
sunlight_penumbra: 4
sunlight2: 200
sunlight2_color: 147 115 135
dirt: 1
dirtdepth: 96
dirtgain: 0.75
dirtscale: 0.75
bounce: 1

Its strange because the shadows look good in other places. Any ideas what's going on here? 
Is this the seam you mean?

Are the faces that meet in the rectangle I drew phong shaded? Are they on the same plane?

I guess it's the sample-point-positioning code not working properly. Is the map sealed? Sealing it may help if it's not.

Aside from that all I can suggest is tweak the geometry. Unfortunately there's no easy fix on the tools side and any time I adjust this code it tends to break some maps and make others better.

In general it looks like 0.15.9 was the sweet spot. I would revert to that but it can't handle faces that are partially covered, e.g. func_detail_wall. 
The map is sealed. I changed the geometry of the ground so that there was no seam between brushes near the shadow and the issue cleared up. Only the rock was a detail brush with phong, the ground wasn't.

It is tricky to get rid of all these seams. If I revert to using v0.15.9 can I still use bounce lighting? 
Yeah - bounce was added in 0.15.5.
All the old releases are on the GitHub releases page:

Sorry to hear but I'll try to fix it in the next release :-/ 
Looks like I can use bounce. I may go with v0.15.9 for now. Thanks. 
Ran Into An Issue With Some Lights Being Removed 
Tried re-lighting the stock id1, hipnotic and rogue BSPs with -extra4 -soft. The result is, many badly lit patches sticking out from brush seams and various corners are finally gone, and the shadow edges are just so much better, see an example here.

However, in hipnotic some maps lose some of their lights and become too dark. E.g. the start map loses the lighting from the two lamps in the room where you spawn, even if I run light.exe with no extra options. Any way I can fix this? 
Some More Findings On This Weird Issue 
Okay, so I ran hipnotic's start.bsp through several different versions of light.exe and the results are curious.

I've tried the original TyrUtils, then BJP's enhanced tools, and then finally found the original light.exe from the official hipnotic devkit. The exact same compiler that the original developers used. Still no dice, the map loses some of its lights if re-lit.

Why does this happen? Did they delete some entities from the compiled .bsp file to save on memory usage or what? Really disappointing. 
Apart from hip1m5, hip2m6 and hip3m2, all the other hipnotic maps seem to be build with -range 1. Adding this option restores the original lighting. (The original hipnotic compiler also supports -extra, and they used it.)

Sorry for wasting your time, but maybe this will be helpful to somebody coming from a Google search. 
@ericw Or Other Tools Experts 
Working on my AD Advent map. I have a specific need to have the boundaries of my map func_detail with _phong 1. So i've enclosed the map in a skybox. I know that's inefficient but I need it to be this way. So my question is: should I use skip textures on the outward facing brushes of the func_detail? Will it make any difference in compiling or more importantly, performance? I am using 0.15.9 because of some issues other have already posted about before.

I ask because there are a large number of brushes in this case. 
If the outward faces of the func_detail touch the skybox, there's no need to texture them as skip because qbsp will clip them for you.

The time to use skip is when the faces are not clipped away by qbsp, i.e. you can noclip over to them and see them, but if you know the player can never get to a position where they can see the face, you can mark them as skip so they are deleted from the bsp. It gives a tiny performance boost and reduces the file size / limits a little. 
Will it make any difference in compiling or more importantly, performance?

None whatsoever. 
Thanks. and @OTP in this case I am using FraQuake to make cave walls made up of hundreds of brushes. Sounds like it may be worth the effort in this instance. I'll do a log before and after and share the results. 
Probably irrelvant in your particular example, but keep in mind skip isn't like caulk. It's really just an invisible texture that otherwise behaves just like a normal surface. You won't improve performance by putting skip on out-of-sight faces. More important than the texture used is how QBSP merges the surface.

For instance, if you have a large even wall made up of multiple brushes, all on the same plane, you can optimize the unseen faces (provided they're not removed by QBSP in which case it doesn't matter) by giving them all the same texture and all the same offset (!) - and, depending on size of the wall, upscale the texture by 2/3/4/... This is to make QBSP merge all of them into a single surface and, if the texture scale in big enough in relation to the size of the surface, it'll generate fewer polys.

Example: unlike modern compilers, back in the day QBSP wouldn't automatically optimize sky brushes, so the trick was to upscale sky textures on big outside areas or void maps in order to have each side of the sky box only be made of two polys. Otherwise it would have a lot of unncessary polys affecting the performance. 
Here's what I am up to. Judging by ad_sepulcher I should be okay in this case as you said. But good info on BSP merging. I recall reading how Levelord scaled up black void texture on HIPDM1. Now it makes sense. 
Bear in mind that a lot of tricks to reduce polycount are probably more relevant to 1996 class hardware. 
It may not have a big impact on performance nowadays, but there's still the old protocol/bsp limits. Granted, most people don't care much about these things anymore... I even upscale the texture on large triggers. :E

Another thing that comes to mind regarding that sceenshot is that, at least by the looks of it, the amount of terrain detail may be somewhat excessive for Quake. Like, how much of it is visible to the player - is it well lit or hidden in darkness, or how clearly distinguishable while playing in the first place. Not saying you should make it a flat wall, just maybe a little less 'granular' (bigger brushes)? I think it's what they call the "the ionous dilemma". 
You'll have to wait until Christmas to find out. Or until I get a decent screenshot. But most of this is viable to the player and in some cases lit fairly well. 
If I understand this correctly, I can enable phong shading on a single func_group and leave the rest of the map without phong shading:

Phong shading is enabled on a brush entity using "_phong" "1". It can be used on func_detail or func_group

However, I can't seem to do this in TrenchBroom -- when I edit the entity properties of a func_group containing worldspawn brushes, it changes the properties of all the world brushes in the map... What am I missing? 
TB groups are not the same as func_group, you want to use func_group for this. 
You add it to the func_group itself NOT the brushes within the func_group. 
Thanks, Ericw & Mukor 
TB groups are not the same as func_group

Ah, I did not know this. 
so, how is the progress with the quake 2 lightmaps?

i think this is the most waited stuff for those who wants to dabble with Quake 2 Unit mapping. 
Been using the bsp, vis, & light tools. I've had significant issues crop up while mapping for Hexen 2, in all the maps I've made. Occasionally, seemingly random areas become HOM's in-game. The issue is very odd. I'll make a standard brush, often just a cube, and then the area is HOM in-game. I can delete it, and the problem will go away. But if I make another similar brush in the same place, the problem re-appears. The map is sealed (it should be, since -leaktest has been used). There are no error messages in the compilers (except for "texture skip not found", although I havent used it). It can't be the new textures, because the problem occurred when I wasn't using any. And it probably isn't a port issue because it happens in all the ones I've tested. Here are two example screenshots, with views in-game and in-editor:

The area in the second screenshot seems to have a separate issue from the first - there's no HOM from afar, only when you walk into the specific area. It can't be seen in the still, but the whole screen just stutters with that one frame while in the area. Also different is that no matter how I change & remove brushes in the area, the problem persists. 
Have you tried snapping vertices to grid and vertices to integer on those brushes?

Also I have seen this happen on brushes that intersect.

Not sure if this is helpful. 
Unfortunately that doesn't seem to help. I was able to fix one brush's HOM by deleting a brush next to it. But neither of them intersected, both of them were snapped to the grid, and remaking the deleted brush didn't make the problem reappear. It's so random and frustrating, it feels like it must be a glitch/bug somewhere in the process. 
Another Thing To Try 
Go to an older version of the tools. Might be an issue with the version you are running. 
I overcome the same phenomenon.
Not to blame the new tools, more my poor mapping skills.
I have several maps I restarted after some months and experienced rare anomilies that earlier tools just lacked to cause.

Sometimes an earlier version of the tools come out clear, while older ones causes homs and leaks. 
while the newer ones cause home and leaks. 
Yeah Madfox Is On Point As Always

these tools do a great job at compiling sub-grid/float precision verts.

Maybe give them a try.

Sadly the author vanished. 
If the area is already on grid there's probably not much you can do from the mapper's side (of course even off grid shouldn't break like this); if you can post an issue on github with the .map or a reduced test case that would help fix the problem.

Alternatively trying older versions is a good idea. Maybe check 0.15.9 which was right before I did some major changes to qbsp (func_detail rewrite).

I can't promise a quick fix, I'm taking a break from working on tools right now and I have a backlog of bugs piling up, but I do intend to get back to it and try to fix things at some point. 
I tried some older versions and the problems persisted. Will post an issue, thanks. 
Good Ol Bengt 
Seems like a vis issue ...just throwing this out but maybe try -fast vis?

It is wierd how switching to txqbsp actually hsndles stuff better in a lot of cases of wierd geometry. You should still at least use ericw's vis and much faster. 
Not wanting to start an argument over whats better, but I'll say that I have built some of the most absurd, overly detailed and off grid architecture and ericw's qbsp has never given me a weird error or HOM that wasn't specifically my fault. 
Some Ideas 
Random HOM like this could happen in q3 if the vis wasn't optimal, sealing or cutting sections up with hint faces could fix it. Also try increasing your engines limits; or dividing your map up so it's not rendering so much at once. 
Compile Error For Qbsp 
when I qbsp-compile a(non-trivial, more than 1 room)map with a detail-brush in it, and use the cmd-switch: _forcegoodtree.
I get the error message: "C:\projects\ericw-tools\qbsp\ Q_assert(p->nodes[1]->planenum == -1) failed.
#### Finished with exit status 1
1 post not shown on this page because it was spam
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2020 John Fitzgibbons. All posts are copyright their respective authors.