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
Quake2 Plans? 
Any plans to ever include radiosity in the light compiler for Tyr like in Quake2's Light compiler?

Regarding Quake 2... possible support for it using these compilers at some point in the future? I read it does support the map format but does it output quake2.bsp files?

Currently I think ArghRad is the lighting one for quake2 maps correct and no other tools came after that outdid it? I would love the AO / Dirt / Skylight / Sunlight from Tyr tools to be usable for Quake2. The main things Q2 still had is Smooth Shading and Radiosity though..

Just wondering because I love this toolset and some offshoot in the future would be great. 
It's actually important to understand that there are not one but two major differences to the Quake 1 lighting model in Q2. When people say "radiosity" it pays to be clear about which of these two is actually meant.

First one is actual "radiosity", as in the ability of surfaces to cast light.

Second one is bounced/indirect lighting.

Thing is, these two don't actually have any dependency on each other. It's possible to implement each without implementing the other.

So you can have surfaces casting light but without light bounces - similar to what these tools already do with lava surfaces.

And you can have indirect lighting but have it coming from light entities which the mapper must place rather than from surfaces.

Or you can have both; but presence of one doesn't demand presence of the other. 
Dirt/AO makes radiosity a bit redundant at this point. It's also slower. 
Also, Quake 2's radiosity actually created a result the same as if you'd just floodfilled the lightmaps with the same flat shade of orange/brown. 
That said, a single bounce could be interesting.

I'm sick of adding fake bounce lights. 
Yeah,maybe I shouldn't dismiss it out of hand. and with multicore lighting, it's maybe not so bad anymore. 
That is not dead which can eternal compile. And with multicore lighting, even death may die. 
Light bounce is indeed what I am looking for. Light bounce that picks up the colors from the surfaces it hit is one thing I liked a lot from Q2 lighting. And we all know the Orange lighting was just them having too much fun with colored lights as it was relatively new technology in games and folks sucked at using color for lighting their levels.

And no Radiosity is not redundant because we have dirt / AO... that is a hack of light occlusion not the spread of lighting.

But yes Radiosity is an old way of doing GI. There are better ways to do it these days which are also much faster. Ultimately I would love to see this toolset support quake 2 and include the smooth shading and Radiosity features from Arghrad. 
Skiffy, yeah I'd like to implement some kind of bounced lighting, like this article:
Probably just supporting 1 bounce to start with. It actually looks very similar to how dirtmapping works currently.

I'm not sure how hard it'd be to add Q2BSP output. Spike might know?

Also, I should have a new beta soon. 
q2 renders much like q1bsp.
its the tracelines that are very different. that said, I think you can still use the q2 bsp tree as a point-sized hull, so that's fine for light.
this is of course ignoring all the changed structs that you'd have to deal with somehow (easiest to do at compile time). 
Sweetness! 1 bounce would already be a great start. 
One or two bounces would be fantastic. It could save a lot of trouble. As it is now, for indoor areas I probably place 3 to 5 fills for every actual light. 
1 bounce with light diffusion would be cool. 
Personally I'd suggest adding a "_bounce" key to light entities; default if there's no key is no bounces (makes sense to keep defaults same as stock Q1 tools) and the value specifies the number of bounces.

That way lighting could be easily recreated at any time and by other tools without needing to know the command-line options that were originally used. 
weird, I don't use notepad++ but it should have a "goto line" feature that should take you to the right line. Anyway, I don't think "Brush With Duplicate Plane" is a serious warning, it's more a warning that the editor saved some redundant data.

It's not that I can't find exact line which correspond to log output - notepad++ shows line numbers. Problem is compiler treats line numbering differently.

I think I found the problem - it doesn't count comment lines.

Tested on my map backup.
Compiled as is
*** WARNING 03: line 45402...
added a bunch of commented out lines("//asdasd") , in the beginning of the file and line number didn't change in the log.
Then I replaced commented lines with empty lines, just a line break. No spaces, tabs etc
Now log says
*** WARNING 03: line 45406...

If it is the case, then every line with entity/brush number gets ignored and line numbers 'shift' from what you would get in text editor. 
Don't Let Your Dreams Be Dreams 
Sorry for little OT.
There is nice BSP importer for Blender. I would love to bake static Lightmap there and export it back to BSP.

In overall some lightmap import option would be great. I know it's hard, because BSP is just fragmented mesh "dump" and lightmap is low res, but we can think about some solution. 
You could create external LIT files � but that requires writing an exporter plug-in for Blender. 
LIT Files 
hmmm.... any link to proper LIT documentation? 
External Lighting And Settings 
Hmm being able to read and write the lighting from and to BSP would be a rather fantastic addition but then you run into a world of pain if you want more light styles supported. how to handle flicker lights and so forth because those get layered on top and limited to the polygons they affect if I remember correctly.

As for the _bounce you could do that or just add it to the compiler as a global option. Same goes with bounce multiplier and saturation. How much energy is maintained when it bounces and how much color is picked up when it hits the surface. In Unreal you can tweak these values so its more saturated and propagates lighting further by not losing as much energy on the first bounce. 
yeah, I know about light styles being problematic in this situation. I'm going through source to fully understand how it works. 
As for the _bounce you could do that or just add it to the compiler as a global option.

Then make it a worldspawn key, so that way lighting could be easily recreated at any time and by other tools without needing to know the command-line options that were originally used.  
There is a port of the half-life 1 radiosity lighting tool to quake 1 you could look at? It does bounce and phong but lacks modern features from these tools... It's called q1rad. No link sorry I'm mobile 
I Think It Will Be Hard To Get Q1rad Source 
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.