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
Looks Fine Here 
Seems to just be shadows from the chain! 
Lovely Stuff Warren! 
Hmmm wonder what my map would look like with this AO pass now... 
God Damn 
that is some sexy looking dirty brushwork! 
Is very nice. The lighting and shadows are very believable. Maybe we need an "ikebony" type texture set. 
that's awesome! Would love to see a whole Quake level that looked like that 
I have to think that perhaps the ikwhite jam maps would have looked about 10x better with these tools *HINT HINT* 
E4M3rmx_lun Confirmed 
eh, the geometry sticking out over the shadowed areas looks all wrong or are those bars actually floating and not connected to walls and floor? 
How did you do that? What compilers did you use? 
Photoshop + Levels adjustment layer I believe. 
Yeah, Photoshop ... 
Willem, Is Your Computer In Your Yard? 
The shot is me trying to add the sky-scatter that metlslime described somewhere earlier. (taken with r_lightmap 1.) still playing with it.

I want to try it on lava, too, because I lit my jam2 map mainly by trying to match what a feature like that would look like. 
Is yours in the broom closet? :) 
After Experimenting With The Compilers And Lighting Tricks... 
Holy Crap! 
Ericw Please Enable Antialiasing By Default 
Looks inviting :)

What compilers and settings did you use? 
"Please Enable Antialiasing By Default " 
does typing -extra4 take that long? 
That Too 
But I meant quakespasm.exe, not light.exe. 
People have suggested using an external text file to specify what surfaces should give off light. This is exactly what Valve did for hl/hl2/etc via "mapname.rad."

This is sensible enough as a decision on its own, but one of the pains of the Source engine is that everything is in a different text file with its own syntax parsed by a different command line tool. If you take the Quake engine and add features piecemeal over 20 years, making a lot of small sensible decisions in a vacuum without building toward some kind of more perfect ideal, you're recreating the exact steps for creating the Source engine. :)

So: is there something better we can do? Someone suggested the Q2 map format, which, yes, it does that, but then we all need a level editor that loads Q1 texture wads but has a Q2 surface property dialog and saves the Q2 map format, which is zero editors. It could be one editor, if sleep puts it in TB, but everyone assumes sleep is adding everything to TB and not everyone uses TB anyway.

I'm a fan of worldspawn keys - something I've considered adding to tyrlight is mirroring worldspawn keys on the command line, and command line flags as worldspawn keys. If I decide on a specific set of dirt variables or whatever that looks good with map A, I don't have to have a special set of map A batch files, I can just save the settings into the map. Or, if I want to fine-tune my sunlight I can just relight it with a different -sunmangle over and over at the command line without having to edit the map and do an -onlyents repeatedly each time too.

I personally wouldn't use a surfacelight definition, though, since it's more important to me that every room is tweaked to look its best than a texture emit the same amount of light every time it's used, specifying light per texture name just takes away that ability. With a 16 unit luxel, area lights are never very visually distinct from pointlights anyway, unless you're talking about a significantly large surface, like the sky or a pool of slime or lava. I don't think that's enough to justify light emission on a per-texture basis - do you need two different light levels emitted from two different lava textures? Per-content-flag is enough for that, which is how sun and skylight already work. 
For Surface Lights: 
What if you just had light entities (likely placed in a box outside the main level) and you could add a "_surface" key to them that you declared a texture name. The light compiler would then do q2/q3 style light from all surfaces with that texture name using clones of that light entity. This makes it compatible with all editors, and isn't that difficult a setup. 
Sleep Puts Everything In TB 
I could very simply enable the surface flag editor for Quake 1 maps, yes. But you'd have to wait for TB2, as TB1 doesn't support Quake 2 at all. 
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.