No, there's no gamma correct downsizing, that's something to try! 

I'm guessing it's the same reason shadows look bad on doors; the shadow should be stationary when the door opens, but in Quake the shadow moves with the door texture.

So it's just to lessen the effect? Disable the dirt so the moving shadow is less noticeable? 

Also, interesting idea about the dirt falloff. I don't think it'd be difficult to do.

For me, that would be really lovely as it would cleanly preserve the 1/x^2 falloff characteristics of my point lights, whilst also giving me precise distance control over when the dirt kicks in, as well as simplifying the whole setup. 

I feel like the introduction of all these new features etc is being held back a huge amount. 

What new map spec do you have in mind? 

 

higher def light maps sound like they'd be useful 

 

Higher res lightmaps have been talked about and we actually had an implementation at one point. Turns out they're one of those things that it's nice to talk about but when reality hits nobody really seems to want them. See the comment about "lit2" in the opening post of this thread, even.

This is something that came up a lot when I was doing the original BSP2 design. There is a degree of conflict between what people want and what's practical to implement. One of the overriding design goals of BSP2 was that it needed to be something that people would actually use. It needed to be quick and easy to implement and with a high degree of compatibility.

That's why it doesn't have all of the additional features that people might wish for. If you ask 10 different people you'll get 10 different answers, and any given 5 of those answers will probably be incompatible with the other 5.

So it doesn't have coloured light built-in, it doesn't have 32-bit textures, it doesn't have high-res lightmaps, it doesn't even change the .map format so you can continue using your favourite editor. Implementing it is just a handful of functions and structures and even software engines get to join the party.

That's why it's been successful where previous "let's design a new map format by committee" attempts have failed.

I think that I've a good idea of the kind of map/bsp format that people actually do want however, and I think it looks a little like Q2 BSP but with embedded textures, BSP2 extended limits and a Q3A lightgrid. 

Yes, what mh said. See here for the start of a discussion on it when it was trialed: http://www.celephais.net/board/view_thread.php?id=60967&start=382

Feedback was rather mixed.

I'm in the "meh" camp. It's funny how, once you start to increase the lightmap resolution, how quickly your thoughts seem to shift to "hmm looks a bit too crisp actually, how can I make this softer?" Heh. 

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.