Quaddy
#157 posted by generic on 2015/01/26 20:25:44
Looks inviting :)
What compilers and settings did you use?
"Please Enable Antialiasing By Default "
#158 posted by Lunaran on 2015/01/26 20:33:04
does typing -extra4 take that long?
That Too
But I meant quakespasm.exe, not light.exe.
#160 posted by Lunaran on 2015/01/26 21:26:13
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:
#161 posted by - on 2015/01/26 22:16:39
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.
TB1 Doesn't Support Quake 2
Yeah I Saw That
But TB2 has full support built in.
Echoed
#165 posted by Preach on 2015/01/27 00:12:11
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.
This sounds like a really good way to do it.
@ Generic
#166 posted by Breezeep_ on 2015/01/27 00:20:17
I use Negke's compiling gui and my settings forl ight are -dirty -addmin -soft -extra4.
Or...
#167 posted by metlslime on 2015/01/27 00:30:53
how about adding keys to the worldspawn, this would be less work and easier to view/edit later
"_surfacelight_slite1_4" "50"
"_surfacelight_*lava01" "100"
#168 posted by Lunaran on 2015/01/27 00:59:15
Well, you can copy/paste lights more easily from one map to another than worldspawn keys, and you can specify all the wait/delay/color/style/etc shenanigans you want instead of just a brightness. I like scampie's method.
Thanks, Quaddy!
#169 posted by generic on 2015/01/27 01:29:43
#170 posted by JneeraZ on 2015/01/27 01:56:50
That has the same limitation tho ... every time you use that texture, it's going to emit the same light value.
Well
#171 posted by Lunaran on 2015/01/27 02:04:25
I didn't say that's why I liked it. It seems like a pretty reasonable way to set per-map texture light automation if that's a thing people want, I just don't personally.
#172 posted by - on 2015/01/27 02:40:02
I WOULD use a system like this, because most of my lighting I just copy identical lights around everywhere anyway. I never really tweak individual lights that often.
I think the value here is that you can use it when you need it... if you have a million little 16x16 lights that are mostly accents, it makes it very easy to set them all up as a single _surface light and you can tweak them all at once. But you aren't required to use the system for all your lights, and can do per-use lights for anything else and tweak to your hearts delight.
Iirc
#173 posted by ericw on 2015/01/27 02:54:55
Adding worldspawn keys for the various -dirt flags should be super easy.
Awesome shot, quaddy! It makes me curious how much phong shading within the light tool would help avoid some of those sharp edges in the lightmap - interpolating normals of the sample points if the angle between faces is leas than some value.
I Was Thinking...
#174 posted by quaketree on 2015/01/27 04:05:42
...more along the lines of some very specific textures in the control of the person making the level instead of someone else deciding for you what the brightness, delay etc was going to be.
Most (not all just to cover the bases) levels use the same textures over and over again. So, for example, *lava might emit a bright but short radius and it "Should" be consistent throughout the level.
Lighting, for me anyway, was always where I stopped mapping. I'm too picky about it.
A tech level might use the same light "Fixture" several times over so consistency might be desirable in some cases.
There's nothing stopping a mapper from taking tech_lite(X) and renaming a copy in the .wad as tech_lite(X+1) with tech_lite(X+1) having a default lightmap value attached to it.
#175 posted by Lunaran on 2015/01/27 07:10:43
But you aren't required to use the system for all your lights, and can do per-use lights for anything else and tweak to your hearts delight.
If the light texture is getting the same light entity cloned onto it by the compiler every time, how would I create an exception, besides duplicating the texture?
#176 posted by - on 2015/01/27 08:58:59
Sorry, I guess I was confusing by stating something obvious for no real reason.
I simply meant that you could set it up for just the light textures you wanted it use it for (such as lots of little lights), and light by normal methods for anything else (such as you might not set up larger light textures and do those by hand to fill the specific areas they are used it)
#177 posted by - on 2015/01/27 09:17:10
I really liked when doing Quake3 maps that I just put a light texture on something, and BOOM, it was lit. But I would get really annoyed having to edit a .shader, or create a new one, to modify the lights, for me it always feels like a distraction to leave the editor to change things... so being an object you set up for yourself in the editor is key for me. And if some mappers don't want to use the system, than there's nothing wrong with doing things the old fashioned way, or just limited use of it!
That's All I Meant
#178 posted by - on 2015/01/27 09:17:54
sorry, I ramble a bit
#179 posted by JneeraZ on 2015/01/27 11:18:37
You COULD do something like that to create sort of a lighting prefab system tho ...
Like in the worldspawn set up a
"light_hot" "light:450,wait:4.0,blahblah"
And then in your light entities use:
"prefab" "light_hot"
to refer to that setting ... might be interesting.
Or not.
Whatever.
#180 posted by czg on 2015/01/27 14:20:31
When I was making honey I had already written a converter from my editor's native format to .map, so for a moment I toyed around with adding functionality for a light stylesheet of sorts, where you'd place a light, give it a "class" and it would grab the correct values from a file. What was nice was that it could also generate secondary lights, so you could place a single spotlight in the map, and the tool would create fill lights and bounce lights in the right places.
In the end it wasn't really worth it and I refactored it out because copy/paste is so simple in the editor anyway, and mass-changing values was also quick because there were some advanced search tools that let you find similar entities in an instant.
#181 posted by JneeraZ on 2015/01/27 16:40:39
"and mass-changing values was also quick because there were some advanced search tools that let you find similar entities in an instant. "
Hmm? I don't think I know about this ... how and in which editor?
|