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. 

That did the trick :) 

http://i.imgur.com/1poBXfp.png Some of my func_detail gets really dark in the middle and has obvious seams with the nearby brushes. Here's how it looks in the editor: http://i.imgur.com/y6JHK4r.png

Any ideas? I can mask the effect by adding another nearby light but the seam is still visible. Changing the geometry works to fix it as well, which is what I've chosen to do. 

Hmm, it's tough to say. It could be a few things:
- try a light compile with "-phongdebug" and set "r_lightmap 1" in engine.
- try adding "-novisapprox" to light. This disables some light culling that can be over-aggressive and can cause artifacts like this, although it shouldn't be messing up in this case.