|Posted by ericw on 2015/07/14 00:34:45|
|Hey, I got around to setting up a website for my branch of tyrutils: (complete with lots of screenshots of different settings of AO, sunlight, etc!)
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.
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:
sunlight_color: 211 163 139
sunlight_mangle: 90 -55 0
sunlight2_color: 147 115 135
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?
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 light...so 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.
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\outside.cc:97: Q_assert(p->nodes->planenum == -1) failed.
#### Finished with exit status 1
|1 post not shown on this page because it was spam|
Website copyright © 2002-2019 John Fitzgibbons. All posts are copyright their respective authors.