I'd be curious to know what Fifth is thinking about with surface flags. 

My experience is that people asking for a feature typically have a very specific problem right now that the feature they're asking for would solve.

For example: "can I have high-res lightmaps?" - meaning: "I'm shining a light through some grating and I'm not seeing the detail I'd like in the shadows".

Thing is, they can sometimes get so caught up in the specific problem they wish to solve that they forget about the knock-on effects of the feature they want.

So "can I have high-res lightmaps?" turns into "everything looks like crappy hard-edged Doom 3 shadows".

Fence textures were another example. I was asked could player movement be clipped by sprites, but it turned out that the problem was that sprites were being used for gratings/etc. Fence textures were an easy addition, everything works the way it should, and the end result is more generally useful.

There's more mileage in asking about what you wish to solve than there is in asking about how you wish to solve it. 

It's interesting reading my post on higher res light maps. I think I would still be interested in 2x detail (4x at a push) but it would have to be surface-dependent (specific areas only). I think when I did those tests I might have just done it on all surfaces (wasnt needed).

When I said surface flags that was certainly one example. Lots of features have been added to the compilers already that cover functions (_phong on groups, this is done by surface flags in Q2, same with alpha textures and scrolling surfaces). Maybe something that will allow terrain in the future and curved surfaces.

I dunno, I was just riffing ideas tbh. My next mapping projects will not be grandiose ones like with ad_tfuma so I am not in the market for new toys and gizmos just yet. 

I don't think it would look good if a 4x surface was beside a 1x surface. Unless you set things up very carefully there would be quite a jarring effect where the surfaces meet. 

One thing that I would like to see added is a way to project textures at full resolution. I wanted to do that with my noirjam map to get a smooth, natural transition between grass and dirt but was unable to due to the low resolution lightmaps.

I agree with the issues that high-resolution lightmaps raise, but better texture projection would be a nice feature to have. It would be a niche addition though, and like mh said, design by committee rarely works out... 

Sorry I can't get my head around why you'd want to fake texture blending via some kind of textured light projection.

Opening up photoshop and making some transition textures would be by far the best option.

If there was enough demand for proper texture blending, it would have to be an engine thing, perhaps done in a similar way to how Quake 3 does it. 

I got _dirt_on_radius / _dirt_off_radius up and running, if you want to check it out here is a snapshot.

For now the feature is only active if you set both keys, and there is no safety check that the _dirt_on_radius is larger than _dirt_off_radius.

This does seem like a cool feature.. here is an (ugly) screenshot with:

"_dirt_off_radius" "100"
"_dirt_on_radius" "500"

http://i.imgur.com/zWQAOtS.png

The light is in the upper left of the screenshot, and the dirt is only really visible on the back wall to the right 

Blend it manually! tool screenshot results screenshot

I never knew I turned that into a tool, but a month ago I noticed someone talking about that tool.

I guess Spirit saved off a copy. 

Wow :) Thanks, that was fast! I've had a play with it and it makes a big difference - that will practically cut in half the number of lights I need. It looks great - torches in corners and alcoves now look correct, and the dirt nicely fades in as the light diminishes. A great addition imo :) 

I've never had much success with tools designed to blend textures; in general, my experience with working with .wad files has been pretty awful. So far the only hassle-free, bug free experience I have had has been with (our lord and saviour) ericw's defullbright tool, which actually does what it says on the tin without refusing to load half the formats it "supports" or failing to save changes properly...

Quake Texture Tool is nice, but in my experience it mangles the colours from time to time. I had to get some blended textures for my current map made by hand because everything QTT produced wouldn't match up when put next to either source texture.

In any case, projecting/blending textures is a much simpler, less painful experience that can easily be achieved with a map editor and the requisite format support. If it worked like it currently does, all you'd need to know is the names of the texture you want and how to set up a spotlight. No messing around with buggy tools from the 90s/early 2000s and no messing around with things like GIMP or Photoshop. 

@baker - looks useful!

@pritchard - sorry still not seeing it - leaving aside the issues associated with having an uber-high-res lightmap, you're still just projecting coloured light - it will just glow, like a stained glass window effect surely? 

Why would it glow? If you're projecting a texture, not a light, you're not projecting coloured light. Perhaps that's how it works now?

To be honest I just miss being able to paint textures in Cube 2. As far as I know that was done through some kind of "map" of the level, but I don't know the specifics of how it worked. But if you're familiar with that, that's the sort of functionality I'd like to have. Probably a pipe dream... 

In any case, projecting/blending textures is a much simpler, less painful experience that can easily be achieved with a map editor and the requisite format support. If it worked like it currently does, all you'd need to know is the names of the texture you want and how to set up a spotlight. No messing around with buggy tools from the 90s/early 2000s and no messing around with things like GIMP or Photoshop.

What are you smoking? 

Why would it glow? If you're projecting a texture, not a light, you're not projecting coloured light. Perhaps that's how it works now?

When you project a texture with a spotlight, you are adding positive light to the lightmap. Let's say you project a green grass texture onto some gravel - all that will happen is you are adding some greenish light to the gravel texture - you'll see the gravel texture brightened up a bit and tinted green 

You can project a texture and set up any blend func you wish. Do it before lighting, do it after lighting, whatever.

Just because it's commonly used for spotlights doesn't mean it can only be used for spotlights.

So project a green grass texture onto gravel and set up the blend as GL_ZERO, GL_SRC_COLOR and you get a straightup modulation of grass and gravel. Set it up as GL_ONE, GL_ONE and you add grass to gravel. Set it up as GL_ONE, GL_ONE_MINUS_SRC_ALPHA and set up the alpha channel of the grass texture and you get a masked overlay - kinda like Quake's sky. 

All my comments are assuming we're just using the existing system but with just a higher-res lightmap. 

So it seems obvious to me that the people who work most on the engines should drive any changes they want to see / would see to be beneficial to the community. So Baker / EricW / Spike... What would you want to see in any future map format?

Regarding the screenshots from the upscaled lightmap experiment.

The jaggies were gone, which was nice... But the sharp shadow edges were a bit much. It seems that some quantity of blending is nice. 

The "jaggies" disappear in regular resolution lightmaps when you compile light with -extra4. 

Lately I've been learning lots of simple shit that I should already know.

Thanks OTP. 

Any changes you make to the map format are useless if noone ever uses them
until them we have bspx, to embed optional stuff that noone else even realises is there. 

So, leading off of my post in the Mark V thread, is there any particular issue with these compiler settings that might cause lit water not to work?

http://i.imgur.com/q1gWtTZ.png 

Aha, should be "-splitturb" without the "s"..
qbsp should be printing an error about unknown option I think? 

Really obscure, odd thing that had me stumped for quite a while! Posting in this thread because it seems to be something to do with the compile.

AD mod - create a misc_textbook and just put (for example) "\\bTest Message\\b\\n\\n" in the "message" field, and "\\bTest Message 2\\b" in the "message2" field (without quotes).

If you do an -onlyents compile, the \\b gold lettering breaks and you see the backslash character in the text. If you do a normal compile, then the gold lettering appears properly. Does this happen to anyone else or is it just me? 

This board treats backslashes different when you preview a post versus actually posting.

In my above post, please ignore the double-backslashes.

They are supposed to be single-backslashes (so in my example above I am actually typing single-backslash-b etc. in the message field in the quake editor.

How confusing is that! 

Try doing an onlyents light compile (after the qbsp -onlyents); I think that'll fix it.

the \b handling is in done in light.exe for some reason; it probably should be moved to qbsp.