News | Forum | People | FAQ | Links | Search | Register | Log in
Tyrutils-ericw V0.15.1
Hey, I got around to setting up a website for my branch of tyrutils: (complete with lots of screenshots of different settings of AO, sunlight, etc!)
http://ericwa.github.io/tyrutils-ericw
and making an "official" release of it.

Nothing major changed compared with the last snapshot (may 1st), but a couple new things:

* .lux file support from Spike, for deluxemapping
* gamma control with -gamma flag and "_gamma" key
* rename -dirty flag to -dirt for consistency
* fence texture tracing is now opt-in only with the "-fence" flag.
* light should run a bit faster


This doesn't have lit2. Not sure what to do with that, tbh.

If there's a demand for it, I was thinking I could make a tool that upscales all textures in a wad by 2x or 4x, and adds a "-2x"/"-4x" suffix to the names. You could then manually get the higher-res lightmap on certain faces by applying the upscaled texture, and lowering the texture scale to 0.5 or 0.25 in your editor.

The only real disadvantage of this hacky method over lit2 is more face subdivision by qbsp. This isn't great, but it shouldn't be an issue if the hack is used sparingly (and bsp2 can be used if needed for higher face/vert limits.)

Anyway, enjoy, I hope this is pretty bug-free.
First | Previous | Next | Last
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.) 
YAY! 
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. 
Easy 
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 https://twitter.com/tdDaz/status/893588140560089090

CLICK THE HELP BUTTON on the entity properties window, it explains all the new stuff in detail for everything. Thx :) 
@ericw 
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. 
Baker 
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:
http://imgur.com/vCdP9Ee

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). 
Baker 
+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:
http://imgur.com/tzeRgMp

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. 
Angles 
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:
http://imgur.com/rOVWyNN
http://imgur.com/GTlWNtQ

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

http://imgur.com/yrkURID

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). 
Nice!! 
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. 
@MaxED 
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. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.