News | Forum | People | FAQ | Links | Search | Register | Log in
TyrUtils V0.11
TyrUtils v0.11 has been released:

*Support BSP2 format (qbsp requires the "-bsp2" command line option)
*qbsp: Fix animating texture bug when brushes are textured with alt-animations
* qbsp: Fix a crash in tjunc calculations
* qbsp: Exit with error if verticies exceed 65535 (BSP29 limit)
* qbsp: Add experimental "-forcegoodtree" command line option (thanks Rebb)
* vis: reduce "leaf recursion" error to a warning and continue processing

Download from the utils page as usual (Win32 / OSX / source).
First | Previous | Next | Last
Ericw 
unchecking extra 4 seems to make the compile quick anyway and when I'm just testing I will also uncheck dirty to speed that up too.

I guess putting on crappy graphics mode was standard back in the day anyway when you're deep into mapping? 
Oh Ok 
Yeah -extra4 should be 16x slower than plain mode, -extra should be 4x slower.

With stuff like AO and the options that make 100s of suns, you end up with way more processing per light sample than before, it makes sense to go back to using non-extra mode while mapping, and only doing -extra4 for the final compile. 
Ijed 
Sure, I can add an option for the quality of _sunlight2 and _sunlight_penumbra, the only reason I didn't is to avoid adding too many command-line options.

Though the bjptools solution of automatically scaling up the number of suns with -extra and -extra4 is kind of elegant. 
So.... 
when is someone going to add extra8? ;)

Get dem high def shadows 
Mmm 
when you use -extra4, it's like using a raytracer to render a 400x400 pixel image, then scaling down to 100x100 in photoshop, versus rendering at 100x100 directly. The final resolution is the same, the -extra4 version just has imperfections smoothed out.

For actual HD shadows, you'd need a new file format, like a high-res version of .lit, and engine support :(. I was just asking spike yesterday, no one's build such a format for q1bsp as far as he was aware. 
 
.lit2 go! 
Ericw 
That's quite interesting to know, I thought it was genuinely higher res. :) 
Nah 
I meant just make it less controllable to avoid weird numbers messing up the distribution.

But using the levels of 'extra' makes much more sense. 
 
But using the levels of 'extra' makes much more sense.
it does and it doesn't. decoupling sun count from -extra means you can do tests with higher number of suns without the lighting pass taking 30 minutes. 
Compiles Slow But It Looks Great... 
 
how is the tree casting a shadow if it's a model? 
Loon 
_shadows 1. 
 
Could be anti-lights, or skip textured invisibrush 
MFX Wins 
it's a func_wall with a skip texture and _shadows 1. 
Light Thoughts 
I wonder would a radiosity solution work better for sunlight than just spawning multiple fake light entities. It needn't have bounced light (that's not radiosity, that's indirect lighting), just surfaces emitting light.

Using visdata (if present) to accelerate lighting seems to be something that nobody has ever done in the Quake tools. The Quake 2 tools do this and it should work quite well.

High res lighting could in theory be done by just taking the output of a -extra (etc) pass and using it directly. Would need engine support, dynamic lights and animated lightstyles would become slower to update, and shadows would start becoming harder-edged with more noticeable stair-stepping. I'm not sure it's a great idea. 
 
How hard would it be to add an option to up the resolution of lightmaps? That alone I think would improve Quake visuals a ton. I know it would require some engine level fiddling and tool changes, but I wonder how much REALLY. 
High Resolution Lightmaps 
The biggest problem with these is updating of dynamic lights and animated lightstyles. It's not a question of work, it's a question of performance. 
 
@mh
Just thread it? 
@Spike 
Nice idea for software but in GL it all happens in glTexSubImage2D. 
 
Sorry for noob question, but I saw some comments in the Beyond Belief in one map thread that made me wonder if I can add AO to maps by recompiling them with TyrLite? I saw some AO screenshots and it looked really nice. In short, can I recompile the vanilla game's bsp's (and other ones as well of course) and get those nifty effects - or is it more involved than that? 
 
Nope, it really is that easy. Extract bsp from pak, relight with -dirtwhatever, play and ogle.

Should distribute a batch file that does all the stock maps. end.bsp might even look half decent. 
BTW Lunaran 
When you have a chance to play with it, curious how the _sunlight2 in the latest build compares to what you were doing!
The actual sun positionong I took from the "skylight" feature in q3map2 
 
i redid the quake maps but found dirt mapping isn't as awesome in those as you would think.

the real benefit comes from outdoor areas that use the modern _sunlight method because that yields completely flat light on its own, and the dirt mapping comes in and makes it awesome.

id had done all their lighting with point lights which already gives a bit of a dirt mapping look.

so yeah, dirt mapping does improve the lighting in oldschool lit maps, but the real benefits will be maps that relied a little too much on minlight or had big outdoor _sunlight areas. 
 
eric, will test, recovering form hard drive replacement 
Hah 
eric, will test, recovering form hard drive replacement minor surgery. 
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.