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
New beta:

Has the .map conversion feature in qbsp, so you can do:
qbsp.exe -convert valve
and it will write out a copy of the map in Valve 220 format to 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  
at least one of the causes is gone. 
I think you may have added in a cause:

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. 
thanks for noticing that, should be harmless but I'll fix it! 
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. 
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??? 
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) 
Uhm, how come this QBSP generates a whooping 11k more clipnodes than other compilers on my map?! 
Hmm, I don't remember touching anything related to clipnodes since this forked from tyrutils.

I just tried compiling 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. 
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. 
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. 
But lava glows on its own. So does slime, doesn't it? 
I don't think slime necessary glows or doesn't glow, though it depends on what kind of slime it's supposed to be...

In Lava's case, you'd never realistically be able to see underneath the "surface" so no one can say if it glows or not :P

I feel like this effect could already be possible with negative lights - those subtract from the lightmap right? You could place a bunch of them underwater and it'd probably be possible to have the desired effect. 
Light Entitys With Negative Values? 
Never knew they exist... 
I've never tried using them myself but it's in the docs. 
I was thinking of Quake 2 where (all?) liquid textures had surface light. So I guess that's actually irrelevant.

Quake's palette shifting effect tends to make underwater areas too bright anyway but negative light would probably still help. 
Attenuate faster if the trace crosses a water surface.

How do you see this working with moving liquid bmodels? 
How do you see this working with moving liquid bmodels?

Let's follow the current standard:
"_shadow" "n"
If n is 1, this model will cast shadows on other models and itself (i.e. "_shadow" implies "_shadowself"). Note that this doesn�t magically give Quake dynamic lighting powers, so the shadows will not move if the model moves. Default 0.

Liquid faces from inline bmodel entities should only be taken in consideration if their entity's self._shadow is 1.

Shadows are, essentially, instant attenuation. Faster attenuation can be considered semi-related to shadows. 
The volumetric water attenuation is certainly do-able; the raytracer is already set up to have side effects when a ray hits certain surfaces.

The latest stable release from last fall has "stained glass" support, i.e. if you make bmodel with "_shadow" "1" and "_alpha" "0.5", light rays going through the entity will be partly attenuated and pick up the color of the texture.

So a simplified version of water attenuation would be not considering the distance traveled underwater, but just attenuate the ray when it goes through the surface. But on the other hand, I can imagine it would look cool to have bright sunlight at the water surface fading to black (thinking of an e1m4 type environment).

Anyway it's a cool idea to add to the todo list. My first priority now is fixing the breakage that Pritchard reported a while back, which I'm making good progress on but kind of a bit drained on tbh. 
"Bit Drained On..." 
That's fine, just know that what you are doing is really really great! There is no going back to the old tools now.

Incidentally, is your light or qbsp multithreaded? I know vis is, which changed light to be my current bottleneck (bounce fun notwithstanding). 
Thanks, appreciate it :)

Light is multithreaded, qbsp is not. Qbsp could get a lot faster, it spends most of its time in CSGFaces checking if each brush intersects each other brush in the map. Quake 2's qbsp is multhreaded.

The main performance tip for light is to avoid using -extra or -extra4 except on your final compile, and also add -gate 0.1 or something to reduce the overhead of delay 2 lights. 

No problem, I can wait. 
Light Diff 
When a map is recompiled, compare its entities with the entities in its previously compiled BSP file, and use the radius of each light to determine which surfaces had their lighting changed.

This way, when recompiling lights, the light tool can simply copy all unchanged lightmaps from the BSP file, and compile only the modified lightmaps rather than recompiling all lightmaps.

Bounce lighting can make this complicated, so I'm not sure if it would be possible. 
I feel like if you're testing within each light's radius to see what brushes have changed, you're already doing a lot of the grunt work for compiling a new lightmap...

It could work for a rough and messy sketch if you were willing to let a lot of edge cases slip through and accept the odd corrupted face or two, but then you invite the possibility of someone releasing a map compiled with that option turned on... 
testing within each light's radius

Only for the light entities that changed. Quite often, it will be only 1 light. 
What I've been thinking of, that's sort of related to that, is making a light preview tool; it would be a small GUI application with a 3d view with WASD+mouselook. You would open a map file and the tool does qbsp and light and displays the result, except the light baking is done on faces near the camera first, and the 3d view updates as each face finishes baking. Then it would refresh whenever the .map file is re-saved. I think this would be pretty sweet. 
yeah, what I have always wanted is a tool that lets me edit the lighting in realtime. I think that a diff-based approach to recalculating lightmaps would be fast enough to make this possible. Most edits would only affect one light, which has only local effects. Of course editing the sun values would not be as easily optimized. 
I'm not really sure what happens if you use old light data on a new BSP, but wouldn't it be pretty broken if you edited the brushwork around a light that hadn't changed. Say you made a ceiling, put a light on it, ran qbsp/light, then built the rest of the room and tried to patch.

I don't know what that would look like but I imagine it'd be quite bad... 
Yeah, that would be quite broken.

There are also complexities around light styles, combining lights with the same style, and packing in new lightdata/updating light offsets, which may in theory require to recalc for the entire BSP. 
Question: Does ._phong work across multiple entities when combined with ._shadow, to make multiple func_wall, func_illusionary, etc blend smoothly with the world's func_detail "entities"?

Right now I'm on mobile and can't test it. 
Pretty certain it does mankrip 
Iirc, separate func_detail / group will be blended if the _phong settings allow it. But other bmodels never blend with each other or world. 
The Cursed Words... 
Having a real time lighting renderer like ericw would be really neat. If you were able to cull light calculations to the player's view (You'd have to be very generous - bouncing their view around corners to find lights that should cast but would otherwise be missed), you could potentially have an engine that displayed in the traditional quake style, while keeping the main benefits of lighting in real time like moving lights.

I can already imagine a whole set of horrendous edge cases arising from this sort of thing, but it'd be a pretty neat thing to see and something that I'd hope modern computers would have the power to pull off... 
I have ZERO issue in paying for a light preview tool to be created. Even if its separate from TB. 
Mapper's Most Wanted List 
�WYSIWYG Editor (lighting, models, anims, particles, the works)
�Leak indicator light: red dot on status bar means leak, green means you're good, updates in realtime during editing. (Plus toggleable prt lines, yes this is same concept as lighting preview)
�Auto entity naming and quick linking/pathing (JACK is pretty good actually)

In earnest, having a simple little window with a 3D fly view and a button click to "render", even if it took about 20sec, would be an awesome help to have over on my 3rd monitor.

sleepwalkr might be able to integrate something into Trenchbroom's 3d view if you mocked it up.

Go for it ericw! Would make adding all the nifty features easier, such as testing phong or bouncescales. 
Yeah, I've just tested, and it doesn't work:

The back of the column is a func_detail with _phong 1. The front of the column is a func_wall with _phong 1 and _world 1.

If _phong 1 worked on mixed entity types with _world 1, we could work around some of the BSP's planar/vertex accuracy limitations by alternating between func_detail and func_wall brushes. This would make the engine clip their planes at the rendering level, which is completely accurate and doesn't produce distortions. 
#821 @mankrip 
quake's lighting logic has some bias on its dotproducts that increses the amount of light on surfaces that are nearly perpendicular to lights (which is important for lights placed near said surface).
You can disable the effect with _anglescale 1 (I think it is now - vanilla hardcoded it to 0.5)

the '_phong' key simply calculates surface normals on a per-sample basis instead of per-surface (thus meaning its misnamed as it doesn't change the lighting formula). It affects the lighting, but not the shadows. While it would be possible to push the sample worldspace positions according to the same calculated normals, and determining shadows based upon those, such things would be quite unreliable in practice - for instance, a concave surface curve would logically push those sample positions inside the surface, which would result in all traces being obscured with the surface shadowing itself.

so yeah, that's why you get sudden lighting changes on the edge of pillars - because -anglescale is biasing the light on one side while the other side is in pure shadow.

if you want to try it anyway, this is the maths I use in FTE for tessellation:
vec3 w = p0*bary[0]+p1*bary[1]+p2*bary[2];
vec3 t0 = w - dot(w-p0,n0)*n0;
vec3 t1 = w - dot(w-p1,n1)*n1;
vec3 t2 = w - dot(w-p2,n2)*n2;
w = w*(1.0-factor) + factor*(bary[0]*t0+bary[1]*t1+bary[2]*t2);
you should be able to shove something like that into GLM_InterpolateNormal (and convert from glsl to cpp - I already renamed stuff from glsl). You'll then need to return the smoothed position back through multiple callers to the point where its copied into the lightmap samples array.
Bonus points if you can calculate the barycentric coords (read: interpolation weights) for general polygons instead of just triangles.
like I say, you'll need to clamp the shadow-point to never be behind the surface to avoid the more obvious glitches. once implemented properly you'll get smoother lighting around corners (although due to the nature of traceline shadows, it'll probably still be somewhat sudden without anglescale 1). 
@mankrip, smoothing between separate models is too difficult to attempt, imho, because smoothing relies on the model having been processed by QBSP. i.e. it involves walking around the mesh (exploring neighbouring faces to a vertex, and neighbouring faces to a face, etc.). If the models weren't clipped against each other, the smoothing wouldn't work.

@spike in current git, I wiped out the "traceline to position sample points" thing. Instead I'm trying to use the same code as phong shading, so exploring the mesh by following connections between faces. So in a concave surface, it should work properly and give world space positions that are consistent with the interpolated normals.

Only problem is, it needs some more work.. Pritchard's case in #773 was failing because of t-junctions in the bsp. I want light to work properly if qbsp didn't add t-junc vertices, so I'm making light do it (in memory only).

re: GLM_InterpolateNormal, apologies for the current mess I made in the code and weird names.. I tried using the glm library a bit, then decided I didn't like it. (100 layers of indirection/ abstraction for basic vector operations, slow as hell debug builds,..)

On the plus side the test suite is growing slowly. 
Is there an automated way to import the configuration from the non-Steam version?

I've just bought JACK on Steam, and upon launch it didn't detect that the non-Steam version was already installed. 
Dumb Me! 
Wrong thread. Wrong tab.

Anyway, thanks for the explanations, ericw and Spike. I'm already going to implement something which should serve as a partial workaround, but I'll keep this info in mind for future research. 
Quake's dotproduct is a simple dot(L,N) * 0.5 + 0.5; i.e a rescaling from -1..1 to 0..1 (excluding the spotlight cutoff for simplicity):

angle = DotProduct (incoming, l->facenormal);
angle = (1.0-scalecos) + scalecos*angle;

But scalecos is 0.5 (, so substituting:
angle = (1.0-0.5) + 0.5*angle;

And evaluate (1.0-0.5):
angle = 0.5 + 0.5*angle; 
Fence Volumes 
Is it possible to make brushes with fence textures be compiled in a similar way to brushes with liquid textures?

By that, I mean making them become properly see-through. Currently, any brush with fence textures will clip any polygons from other brushes that touches them, which results in open holes where the other brushes should be visible.

The only difference to liquid textures is that the pointcontents of fence brushes would have to be set either to solid or to empty. I guess the first case would give problems to the renderer, and the second case would give problems to the physics, but from the top of my head I'm not sure. 
I'm not sure how much interest there would be in changing how fence textures are compiled as it's already quite easy to resolve the "clipping" by making brushes using fence textures be a func_ brush such as illusionary or wall. 
Lighting Artifacts 
Pic. What's going on there? Any way to get rid of this without anglesensing the shadows from the spikes away? 
Apparently it's related to the increased texture scale (2.5-3x). Jury-rebbed BJP light doesn't seem to have a problem with it (but it lacks several feature I require). 
Make sure to use v0.15.9, the .10-beta1 turned out to be broken.

If that's not the problem, I'm not sure from the screenshot, could I have a look at the .map (just for what's in the screenshot would be fine)? 
There's a specific problem I'm having with it, when BSP entities partially inside of walls gets darker edges because part of their surfaces is in pure darkness.

If such entities were part of the world, their surfaces would be clipped by the compiler and there wouldn't be any parts of them in pure darkness. But to be part of the world, they would have to be compiled similarly to liquid volumes, without clipping other brushes.

Currently I can work around this by making the other brushes that touches them into func_wall entities too, but IMO this isn't the most efficient approach. 
the renderer doesn't care if something's solid or not, just that its a leaf or node.
same with physics, really.
just make sure those fence-solid leafs don't get merged in to leaf 0 like all other solids, and that vis considers them transparent despite solid (can't say I've really looked into the vis tool itself, maybe it already goes by leaf 0 instead). 
Thanks for the explanation. The BSP tree architecture is something I've not started studying deeply yet. 
Devil In The Detail 
I also came across an issue with detail brushes. Not sure if it's a bug or simply a technical restriction and downside of the way detail brushes are done in Quake, and also not sure if it's a general thing or only applies to certain special cases.

I had a compact bit of architecure flush to the wall of a building and turned it into func_detail in order to use phong shading on it. The building's wall behind it remained solid world geometry. As it turns out, having the detail brush touch the wall like it did caused the compiler to disregard visblocking for the wall which resulted a situation where a large part of the interior was being rendered despite being completely out of view, causing wpoly to increase by 1500. Making the func_detail 'flatter' by including only the front part of the detail architecture didn't change anything; it seemed to be entirely related to the touching of detail and world brushes on that particular part of the wall.

Now, this might be an edge case caused or faciliated by the shape and construction of that particular area (sloped brushes, same brushes for inside/outside etc), but still a potential risk to keep in mind, especially if remaining unnoticed until the final release of a map.

If anything, this is meant to raise awareness that excessive func_detailing can be detrimental, too. Perhaps the code can be tweaked to make sure this can't happen, or maybe it something to live with due to the hacky nature of it. 
Some screenshots to clarify.

The face is the func_detail in question. The wall below is a door, but instead of only rendering the corridor behind it (hell knight), it even draws the atrium way out sight, much of its upper and lower parts. 
isn't a catch-all.

I have found in a number of my maps that I get a speed gain in compile times but not always ideal results in culling in the game. 
That Face... 
Is so Tron. 
Tyricutils Func_detail 
Good lighting and faster vis time and same, worse PVS splitting.

Source engine func_detail: Good lighting, faster vis time, and clean PVS since it treats them as func_walls.

Thing is, I don't know how you would gain the benefits of true func_details (the Source way, the right way) unless the compiler turned them into info_notnulls or func_walls. Otherwise, the mod would need to support func_detail entity in its progs.dat


Unless engine support for func_details was added. Currently the compiler de-entity-ifies them into normal brushes. But if they were kept... 
What you describe about detail brushes in the Source engine sounds close to my suggestion about see-through solid volumes. 
Isn't all VIS/PVS data precompiled in quake? Why do we need to turn brushes into a specific kind of entity in order to get a desired effect?

Would it not be possible for VIS to just look at a func_detail, say "I'm going to treat this as if it were a func_wall" and be done with it?
How does it work currently? 
Yeah, I'm going to take another stab at fixing func_detail's PVS issues. mankrip your suggestion sounds good to me, and it sounds like it'll share the same implementation.

How about (assuming I can get these to work :-)

- func_detail_fence - same as "func_detail" but doesn't clip away world faces, so it's usable for fence textures. Like func_wall, but doesn't use up an entity.
- func_detail_illusionary - same as func_detail_fence but no collision hulls. Like func_illusionary, but doesn't use up an entity, and as a downside it would block gunfire. Not sure if this would be useful? 
That's good.

func_detail_illusionary would actually be really useful to simulate crouching. The real ground would be lower, with a func_detail_illusionary ground a little above. Of course, this would affect monsters too, so its usage may be limited to small areas. 
I don't care much about quicker VIS times; all I want to achieve is phong shading and occasinally minlighting on brushes without taking up additional entity/model slots. Although marksurfaces eventually forced me to turn many of them into func_wall after all.

As for the issue I mentioned above, there's a workaround. As it turns out, phong and minlight also work on func_group, so making the big face a group instead of detail gets all the effects without the PVS problems. Good to know, albeit even more hax... 
Is there a way of increasing the lightmap resolution? 
Use A Bigger Texture Than Scale It Down 
texture scale is linked to the lightmap resolution. 
LIT2 (see the opening post) supports increased lightmap resolution and we all went round the block with it a few years ago. No clear community consensus formed.

My own opinion is that it's a poor trade off for hugely increased file sizes, and it doesn't even look as good as you'd think owing to losing the soft edges on shadows. 
It could be useful to add a compiler/worldspawn option to set portal brush contents to CONTENTS_EMPTY, because as it is, using CONTENTS_WATER, portals can't be (partially) placed inside of slime and lava. 
By the way, Quake's episode 4 already has maps with underwater portals. So, allowing portals under slime and lava would bring more feature consistency to mappers. 
Azure Agony 
Used black for its teleport texture.

I think you mean teleport. Portal is something created by vis.

That's not a terrible idea but I think it would serve better as an entity field: _overridecontents 1 or something to that effect. 
Just copy the teleport texture and call one copy *lavateleport and the other one *slimeteleport in your wad file. 
thats brilliant. 
New Stuff 

I've been working on qbsp, and did a rewrite of func_detail to fix the vis problem. The big change is, func_detail no longer seals the map (which makes more sense anyway IMHO). No more of this! (baker's shot of a way-too-big-PVS from some spot in ad_mountain).

Also, I added a bunch of func_detail variants (illusionary, wall, fence) described in more detail on the release page. Thanks for the suggestions, mankrip, and Spike a while ago.

This is still bleeding edge so it's marked as a beta, and I still haven't fixed the light issue you reported Pritchard. 
I didn't think that had ever cut vis. I know it doesn't in GoldSrc/Source. Was func_detail something third-party FGDs added to Quake? 
Yeah it was something added later to the Quake tools - afaik originating in Quest.

It's not that func_detail blocked vis, but certain setups would cause bogus portals (what negke is reporting in #835) resulting in bogus vis results. 
light: styled lights no longer bounce by default, set "_bouncestyled" "1" to enable.

Just want to confirm this means bounce is disabled on id's lightstyles "flicker, pulse" etc.?

Is that set in worldspawn or on the light entity or both? 
Yep, it's for flicker/pulse and also lights that start off and are switched on. The "_bouncestyled" key is on worldspawn and affects all the flickering / switchable lights in the map.

(The first release I did with bounce lighting didn't support having those lights bounce; now they can, but it's opt-in.) 
great. thanks for all your hard work on these tools. 
thanks for -forceprt1 - I was always editing prt file in text editor to load it to JACK :P 
thanks for -forceprt1 - I was always editing prt file in text editor to load it to JACK :P 
Why Is The Win32 Download 
about half the size of the Linux and Win64 versions? 
32 Is Half Of 64 
Oh, Ummm, Haha, Yeah... 
I'm still running a 32-bit system, I didn't realize that doubling the bits would also double file sizes. Makes sense. 
would it increase compiling time if i added "_phong_ to my "func_detail" entry in FGD and thereby all my func_detail? 
would it increase compiling time if i added "_phong_ to my "func_detail" entry in FGD and thereby all my func_detail? 
If "_phong" "1" is set on every func_detail there will be a little overhead, maybe 10% slower, but nothing major.

The main thing I would watch for is unwanted smoothing. The default _phong_angle is 89 which might be a bit high (face normals up to 89 degrees apart will get smoothed together). Check with a "-phongdebug" compile and set r_lightmaps 1 in the engine to see what is getting smoothed. 

- light: add "_shadowworldonly" bmodel key - only cast shadows on world, not other bmodels.
- light: switchable bmodel shadows (requires QuakeC support, see light manual).
- light: accept "_minlight" in worldspawn as an alias for "light"
- light: handle degenerate faces, print out the vertex coordinates

- qbsp: misc_external_map prefab system (see qbsp manual)
- qbsp: don't write unused texinfo
- qbsp: rewrite outside filling similar to q3map
- qbsp: revert change to SubdivideFace which was increasing faces a bit (see 53743dd)
- qbsp: add -expand option to dump the hull expansion to a "", from q3map
- qbsp: add -leaktest option to abort compilation when a leak is found, from qbsp3
- qbsp: fix handling of duplicate planes, which was causing id1 maps to leak
- qbsp: try to get more reliable leaf content assignment (see a910dd8)

- bsputil: --check: print BSP tree heights at the first few levels of the tree
- bsputil: --check: check for unreferenced texinfo, vertices, planes
- bsputil: --check: print number of used lightstyles
- misc: travis-ci now runs qbsp on all id1 maps, the build fails if any maps leak 
Hey, thanks for this!
I was using beta for a while.
Awesome improvements! 
Weren't there changes to how func_detail brushes are handled? My map's more like a sieve now...

In other news, the removal of the Reload pointfile button from TB was a crime. A CRIME! There is far too much clicking involved now.

Do you know if that lighting bug I reported when the beta first came out was ever fixed? It's still an open issue on Github, but flying around my map I haven't spotted anything particularly nasty (by quake lighting standards) 
Don't use func_detail to seal your map. 
DoN'T UsE FuNc_DeTaiL TO SeAl YoUr MaP 
It was never my intention to use func_detail to seal my map. Think of it more along the lines of func_detail sealed my map, so when I ran QBSP it didn't catch the leaks and instead allowed the map to be VISed etc.

Most of the map is actually func_detail. And most of it is capped off with far simpler world brushes to seal it. But I missed a good two dozen tiny corners and gaps it seems, and that wasn't revealed until now.

Anyway I'm sure that's the least of my bad practices when it comes to VIS. Half of the map is in a giant box right now... 
Func_detail Doesn't Seal Anymore 
I know it's a disruptive change, and makes a lot of existing maps leak, but it was necessary to fix the longstanding bug with vis seeing through walls when func_detail is used.

qbsp has an -omitdetail flag now which should make it easier to see the worldspawn leaks in-engine, or hide all func_detail in trenchbroom; hopefully it's not too bad to seal up the leaks.

Do you know if that lighting bug I reported when the beta first came out was ever fixed? It's still an open issue on Github
I think I still need to do some work on that.
However, there are 2 things that will help for now:
- enable phong shading on the ground
- seal the map (the way I have light set up currently, it needs t-junctions in order to find neighbouring faces.) 
A func_ that actually behaves as a func_ now!

Pritchard: ah the box trick. I used that for a section of a map once with a lot of angled brushes. Tsk tsk, pure mapping laziness. ;) 
RE: Prefabs 
awesome! However, why the weird behavior with the entities? Why do you not just simply move worldspawn brushes to worldspawn, and copy over all others? 
Yeah, it's a bit weird.. I guess I wanted to be able to tweak keys/values per instance. So for example you can make several misc_external_map entities that get turned into func_door's, they all use the same external map file, and each one has different func_door settings like "angle" etc. 
Make it optional!

also, I'd assume "angle" gets rotated with the angles key. 
J.A.C.K Fgd 
Updated my JACK editor fgd file for the latest release of these tools

CLICK THE HELP BUTTON on the entity properties window, it explains all the new stuff in detail for everything. Thx :) 
Have you considered putting the compile command line in the worldspawn of the output .bsp?

Consider this scenario:

1) Someone makes a map
2) Releases the map source

But the number of possible command line options is nearly infinite. The author of the map isn't going to remember. So even with the map source, no one would know how to compile the map to produce a similar result.

This has proven in the past to even be a bit of a pita for even the id Software Quake map sources.

/End random thought. 
That sounds cool. I'd like that for Source maps too. 
Started Using 0.15.10 
Thanks for your continued work on these tools ericw. I recently compiled with the new version and I did notice a slightly faster compile time for light. I didn't notice any issues on the map compared to compiling with the previous build.

I posted this screen in the screenshots forum:

The pillar on the right is a bottom half func_detail with _phong 1 and the upper half is func_breakable with _phong 1, but you can see a clear line where they meet. Do you recommend anything to make this look better? 
try reducing the angle so that it doesn't try smoothing the lighting over the caps of the cylinders? this should normally happen if the caps are completely flat, but if they're angled even by 1 degree then the default angle cutoff will be too high. 
Oh yeah, that makes more sense than my idea. I should probably lower the default angle cutoff a bit. The key for that is "_phong_angle" and default is 89.

To confirm it is that, add the flag "-phongdebug" to light, and enter "r_lightmap 1" in the console (for Quakespasm). 
+1 that would be handy. I recommend worldspawn keys for everything except -extra4/-extra anyway, but it would be useful to have a record of what command flags were used (could even add a key for saving the tools version, though that would bloat the bsp by a few bytes) 
I Broke The Universe... 
Ok I tried ericw's methods by adding the new shadow keys, didn't see much happen as the breakable was still darker.

Here is what happens with r_lightmap 1:

I guess you can still see the shadow here. Now these breakables are only a cosmetic part of the map so this is not crucial, and I could just make the pillar a good old detail brush. But if there is an easy way to fix this it would be awesome. 
Pillar Caps 
I forgot to mention, the pillar caps are indeed angled as Spike mentioned, so if that means its something to do with the phong shading, maybe that helps to diagnose this. 
I set the phong angle on the breakable to a lower number 45 randomly, and noticed some improvement viewing from certain angles, but still darker from others.

Should I also change the phong angle on the detail pillar as well, to match the angle on the breakable. What kind of decrease would you suggest? 
Try adding -phongdebug to your light command line, it will compile very quickly and just give you a visualization of the phong shading.

What you want it to look like (with r_lightmap 1) is the pillar caps to be solid and the curved surface of the pillar to be a smooth gradient. It might help to move the breakable to the side so you can see if the phong shading is blending around the cap edge. 
Also 45 is the right value for "_phong_angle" if it's an octagonal pillar, any lower and the 8 sides of the pillar won't be smoothed together. 
I Think Its Fixed! 
Ok here's what I'm seeing with phongdebug added:

After changing all of the breakable pieces and the detail brush pillar to _phong_angle 45 the darker shadowing is gone!

Thank you Spike and ericw. Great help and this map is looking good once again. 
Hi! I've added a "_falloff" light property. It allows to specify light diameter in map units (this decouples light brightness from light falloff). 
That's a feature I think a lot of people would want. Does brightness increase with light diameter though or does it stay the same? 
It stays the same. 
Sounds Really Good 
I hope it gets implemented.

I imagine you can make very bright spotlights on floors too with this. 
Agree with Fifth. Sounds very useful and more control of any attribute is always welcome. 
Better Than Having To Calculate From Wait 
PS I like your star ceiling Redfield. 
Hi! I've added arghrad-style sun setup using light entity.

Allows to set most of sun properties using a light entity with "_sun" key set to 1.
If the light targets an info_null entity, direction towards that entity sets sun direction.
Light itself is disabled, so it can be placed anywhere in the map.

Following light properties override corresponding worldspawn properties:
light -> _sunlight;
mangle -> _sunlight_mangle;
deviance -> _sunlight_penumbra;
_color -> _sunlight_color;
_dirt -> _sunlight_dirt;
_anglescale -> _anglescale.

Here's a compiled version (x86 build, also supports "_falloff" property I've added earlier). 
Cool. I will try this on the stand-alone version of my SM179 map. I was very displeased with the sunlight and didn't have time to tweak it as it was a 24hr jam.

MaxEd Is there a default falloff for the _sun entity or is it 0? Will pointing this to an info_null effect the falloff? 
Is there a default falloff for the _sun entity?
The default falloff for the _sun entity is 0.

Will pointing this to an info_null effect the falloff?
Thx Again 
I merged in features, _sun and _falloff (only for delay 0/linear falloff for now) 
Will pointing this to an info_null effect the falloff?

Actually, that's a neat idea for spotlights, so I've added that:

Added "_spotlightautofalloff" worldspawn key. When set to 1, spotlight falloff is calculated from the distance to the targeted info_null. Ignored when "_falloff" is not 0.

Calculated falloff = [distance from light to target_null] + [cone radius at target_null]. 
Sorry for such a newb question but are there binaries for this version? or is it just added to the code at this point? 
What Is The Point Of External Map Prefabs? 
Not trying to be a smartass but... if you have a prefab map with brushes you want, why not just open that map and copy them into your current map?

I mean mapping like that seems clumsy and complicated. You won't get a visual in editor and more than likely it'll be trial and error going into the game back and forth to make sure your key settings are correct.

What's the advantage, what am I missing? 
You can make a change to the main prefab and it carries over into all external uses of it.

Copy+Paste means youd have to manually change each instance. 
I am guessing but I think ericw is trying a sneaky way to get prefabs added to Trenchbroom someday. SleepWalkR has resisted adding them to the editor for his own reasons and this is a work around that could be added to any editor in theory. I assume with very little work.

Again I am guessing... or day dreaming. I copy and paste just fine using TB2 but it would be nice to treat the prefab as a group without having to define it as a group. I dunno. Maybe I am just missing something here myself. 
duh... what muk said: that too!! 
One of the advantages of it if you're stuck with vanilla .map format is, you can rotate the prefabs at weird angles that would normally require valve map format to keep texture alignment, and the texture alignment will not get messed up.

along the same lines, you can map something complex in the prefab file, keeping it on-grid, then rotate the instance off grid, then go back and make further edits to the on-grid prefab file. 
Thanks Guys 
I knew I just had to missing something. Seems it was alot of somethings! 
@ericw : "_mirrorinside 1" 
When you mentioned you added this did that means it's already in the binaries for use/download? 
I didn't do a new release yet, but there are dev build binaries here that have it (click on x64 or x86, then go to the "artifacts" tab). Only gave it a quick testing but it seemed to work fine. 
Oh Cool... 
Muchas gracias :) 
Ummm, Actually... 
With DarkPlaces I have no z-fighting with "_mirrorinside 1" set, everything looks fine.

But with Quakespasm there is z-fighting, from both the outside looking in and on the inside.

Was I supposed to make sure the brush doesn't touch other brushes? 
I think you need to make all of the faces "skip" except for the water surface. Qbsp doesn't clip bmodel faces against the world, so that's the cause of the z-fighting.
(in the past you had to use "*waterskip" as the skip texture for water brushes, or you'd get "Mixed content" errors, but with my qbsp you can just use regular "skip") 
*waterskip Not Necessary?? 
Is this the same for *lavaskip? 
you can just use skip 
Ah, Got It. 
But another question, hehe... sorry :(

I think this is a side effect/limitation of the QCat play here, but items or brushwork inside the "water" don't have, hrmm how to say this... correct perspective? Does that make sense. They just look strange.

I've seen this before but can't remember what it was. 
I think it's a limitation of the QC; if you run it in an engine that has the swirl effect underwater like winquake, you don't get that with func_water, you only get the screen tint. I dunno if func_water is messing with the fov cvar or something? 
more of an engine limitation in that the vanilla engine doesn't bother to check submodels for pointcontents, both in the physics+qc builtin as well as clientside too.
(you also need a qbsp that doesn't claim water to be solid, along with generating inwards faces.)

one of the ladders mods has something like 3 different glitches relating to said mod's ladders (breaks at certain framerates, leaves players stuck in walls, etc.
so watch out for that. 
Is there any risk in using the 0.15.9 light binary with the rest of the 0.15.10 release? I've posted screenshots on the mapping help thread and github showing my reasons why.

Having all the qbsp improvements from 0.15.10 would be nice, after all... especially the func_detail fixes. 
It's Safe 
The only problems would be stuff like: func_detail_illusionary will always cast shadows, and func_detail_wall would cause lighting issues if it's covering world geometry.

I would go for it; the func_detail fix in .10 is worth using.

Sorry I haven't fixed this earlier, also noticed some light seams in shib1.bsp that are probably coming from 0.15.10. Fixing the code or reverting the relevant parts will be my priority for the next version! 
_minlight Being Ignored? 
Getting Your Christmas Jam On I See 
That's Messed Up 
let check if I can reproduce it 
I couldn't reproduce it. tried both 0.15.9 and 0.15.10's light. Mind uploading a sample to github? Hopefully this should be a quick bug fix. 
Emailed you a .map and .bsp/.lit

And yes, this is for the Christmas Jam :3c 
Sorry For The OT, But 
if you look just below your pic in the first link, there's a pretty badass fan art of Vader slaughtering Ewoks. 
Does _mirrorinside 1 not affect {fence textures? It's not working for me. Do I need both light and qbsp, I'm only using the qbsp from version 0.15.10 
It's not in 0.15.10, I posted a dev build link in though #910
Should work on fence textures 
Still didn't work. 
@Qmaster: Worked For Me. 
I had func_detail_fence, skip textured all sides except for 1, which had the AD vines.

Saw them from both sides. 
Would it be possible to have model->geo baking like q3's misc_model(static) 
I've played with that in the past, but I didn't understand QBSP as well so it didn't work very well. It's probably doable to bake in a model without converting it to brushes, but it would be illusionary only (doesn't stop bullets, no collision) so I'm not sure if it's worth the effort.

If you want collision (player / monster / bullets) qbsp needs brushes, so you can use obj2map or something to convert to .map first (turning triangles into tetrahedrons with obj2map will probably give you a bloated / inefficient bsp, though). 
Do I need to use func_detail_fence only? I've been using func_illusionary. 
no, I tested it with func_illusionary. I don't know why it's not working for you, check spelling? "_mirrorinside"
Build version should be "tyrutils-ericw-v0.15.10-12-gd86913a" 
Func_illusionary Also Worked. 
No, not func_detail_fence only.

When I first tested I used func_illusionary and then thought, "Oh wait, he mentioned fence!" So my brain connected dots that weren't there :(

What didn't work for me was standard func_detail and func_detail_wall

"but it would be illusionary only (doesn't stop bullets, no collision) so I'm not sure if it's worth the effort. "

Still worth it, imo. 
I think I figured out my shadow bug on my trees - it was the old "intersecting brush with func_illusionary" bug.

My trees have a little solid brush in the center as a "trunk", and making it into another func_illusionary seems to fix the issue.

Still, having a fix for that bug would be nice... 
Hang On 
Turns out it wasn't compiling with the ericw qbsp at all in either version. I usually just hit yes whenever JACK warns me that prt wasnt made since I know my test map isn't sealed.

Not sure what's up. The output says almost nothing to the compile dialogue. Just says the compile path and path to file which are correct and nothing else.

Do I need any sort of compile parameter to compile 220 map format? Already tried the usual admin privileges. 
Ya going back to tried and true txqbsp modified by mh and it compiled just fine.

Hmap2 Works Too 
Does anyone else have trouble with using JACK, valve 220 format, and the tyrutil's qbsp? Light and vis work fine for me but not qbsp. Qbsp produces nothing and gives no output. Must be something wrong with my setup but not sure what. I'm not seeing anything obvious in the docs about compiling for 220 .MAP format. Sorry for the multiple posts but this is wierd and I really want to be able to use all the awesome features ericw has added. 
Hm.. there is no special flag for compiling valve 220, it should just work :/ 
Just Work (c) 
Got it. Mirrorinside working too!! Yay! I manually draggedndropped the .map onto qbsp amd it gave me a couple errors for missing dll's.

Needed to download:

And put into same directory as qbsp.exe. I guess it has to do with Windows 10 missing some VisualC packages. 
Experimental Build 
Is giving me some wierd gray patches where walls aren't getting drawn...tried changing the brush work significantly with no effect. I can send you my .maps if you'd like? 
Sure, I can check it out. 
Pics included to show the problem spots. Let me know if you can't find where they are. 
This is awesome. 
Error Message Related To -bsp2 Vertices? 
Hey there,

My next map is approaching completion. I'm working on the beta build and just recently encountered a few errors when compiling that seem to have been alleviated with the use of bsp2 format.

The first time unfortunately I did not record entirely but it stated something such as: Error: " many vertices... try compiling with bsp2..."

Now this was most certainly not a leak. The map is sealed, there are no warnings of entities exposed to the void, no pointfile, etc. and using bsp2 fixes the problem. When I compile now with bsp2, the map compiles with vis and all is good.

However, I cannot replicate the original error message. If I remove -bsp2 the compiler reports error:
" Q_assert<v1 == edge->v[1] & & v2 == edge->v[0] failed."

Using bsp2 gets rid of this error as well and all is good. Now, I'm not sure what this error is, but the first message was a lot more useful and allowed me to fix the problem on my own, which is great. Maybe this error message should say something similar.

Backslashes Missing Sorry. 
The error reads:

"13:C:\projects\tyrutils-ericw\qbsp\ Q_assert<v1 == edge->v[1] & & v2 == edge->v[0] failed." 
The current code to detect if bsp2 is needed isn't very good.. I think those crashes just mean that the map needs the -bsp2 flag, but qbsp didn't detect it properly. Improving that is on the todo list. 
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-2019 John Fitzgibbons. All posts are copyright their respective authors.