misc_models and .ASE models
j/k 

Wow that was quick :)

Here's a test map in the Quake3 BP format: https://dl.dropboxusercontent.com/u/61424391/Quake%20Stuff/testq1q3.map

I compiled it with your new build and it seems to work fine, cheers!

So, here's how you set up NetRadiant to use the BP format:

Edit the q1.game file located somewhere like here:
"C:/NetRadiant/netradiant-custom/netradiant-custom-20160911/games/q1.game"

All you have to do is set brushtypes="quake3" and maptypes="mapq3".

Then in the editor, go to preferences->settings->brush and make sure the "brush primitives" checkbox is turned on.

Restart the editor. Now, when you are in quake 1 mode in NetRadiant, you will be reading and writing maps in the Quake3 BP format. Everything else is still Quake 1 style - wad textures work fine and all that.

I still need to pester the NetRadiant guy a bit more though. In the test map, I have included a crude terrain ceiling to illustrate the main problem with the editor's handling of the BP map format - which is ironic considering the format was created for Radiant in the first place...

When in BP mode there currently seems to be no way of telling a face to use the old axial projection - it's face projection all the time. Face projection is great to avoid the weird skewed textures on certain angled surfaces that you'd get in quake's original map format, but for stuff like gentle terrain you would almost always want axial projection to get seamless texturing.

The terrain in the map looks terrible because of this. But yeah I just need to pester the guy maintaining NetRadiant to add the ability to choose face or axial projection on a surface.

A little bonus thing you could do that is not important, but might be worth doing, would be to read Quake3's "detail" flag on brushes, as an alternative to using func_detail - this might come in handy for people who want to try converting existing Quake 3 maps over to Quake. 

Hmm...not sure this is a bug or not, jpegs below:

Func_wall no _shadow: computer_noshadow
Func_wall with _shadow 1: computer_shadow1

See the hard line where the face changes textures at the trim baseboard?

Tried messing with the brushwork and got these:
uh-oh
and_more_breakiness.jpg

.MAP: asset_library.map (ya you can guess what this is eventually going to be ;) ) 

and_more_breakiness 

I had that happen to me once on a map I was working on, my solution was to reduce the intersection of the brushes as much as possible. So the wall behind would need to be cut to shape around the computer panel rather than having them simply overlap. Try it and see if it helps, I guess. 

I think that bug was fixed in v0.15.7 :) If you're on an older version, updating to the latest should fix it. 

So I was messing about with flashing lights and realised that due to limitations of the engine there are certain things I can't do that are pretty simple. Things like having alternating flashing lights (without needing extra trigger/relay entities). Or having a light that has a fade and a flash sequence.

So I was thinking about custom lightstyles. Here is the idea:

A light entity with the tag "_lightstyle" which allows users to have cusom "id" format lightstyles: string value a-z (example: "aallzzll").

What are your thoughts? 

I think something like that could be done in quakec. 

but that won't apply to vanilla or to AD or quoth, etc. 

read that as "can only be done in quakec" 

Phong shading and Deviance are easy to understand as "options" you can exercise in your mapping. But I am a little confused about bounce(radiosity) and dirtmapping(AO).

Bounce:
From my limited knowledge IIRC radiosity lighting is superior to standard Q1 lighting, yes? And if so, would that be considered to be the default choice(standard) for mappers from now on going forward?

Dirtmapping:
Should this also become standard practice in lighting a map, or more still just an option for giving a certain design/artistic "look"?

Thanks. 

Both options can provide a pretty significantly different look. Bounce lighting is one that I personally see as almost always desirable, with the exception that it makes it quite difficult to have stark contrasts in your lighting (which you may or may not want to have depending on specific situations) due to the fact that light will, well, bounce! I can't think of a situation where it's made a map look bad, but by no means is it necessary to use if you want your map to look good.

Dirtmapping, in my mind, is a bit more subjective. It certainly helps to add a "look" to your map, although depending on how you tweak the values that can either be very intense or very minor. It's certainly not appropriate for all situations, but taken in moderation I think that it's generally useful.

I think the same really goes for a lot of the modification's ericw has made; yes, they do have a distinct look that changes how the final product uses, but it's generally a tasteful, inoffensive change that most people would take as being an improvement. I mean, compared to coloured lighting (especially when ported back into older maps i.e. the original game) it's pretty harmless, and we've learned to live with the existence of that technology...

Anyway, I'm not exactly prolific enough to have a "default" for my maps, since I have about... 3 to my name, none released, but so far I've always used bounce and dirt with varying settings in my creations. 

I haven't tested it in a while but I believe you can use lights with negative brightness to combat the horrors of bounce lighting (even though it saves time putting in fill lights). 

ericw: would it be possible to compensate for lightmap seams as described in this paper?

One of those "would be nice" features. 

I tried 0.15.8 a bit tonight. There seems to be problems with lights inside sky brushes or something. Or maybe a problem with very low values for light?

Here's one that seems to have just disappeared.

BJ/MH Light

http://quaketastic.com/files/screen_shots/wish13_i.jpg

0.15.8 Light

http://quaketastic.com/files/screen_shots/wish13_i_2.jpg

That light shining through the window is in a sky brush, but just barely. It's almost in the void. The values are light 75 delay 5 wait .02 and the range is set to 1.0 on the command line.

I saw other differences, but that's the most obvious. 

Thanks; I didn't realize regular light entities were supposed to pass though sky faces. Should be an easy fix. 

The thing is, most of them still did. The only one I noticed that didn't was the one in those screenshots. That's why it stood out. Is it possible it got "nudged" into the void?

On the good side, about 10 of the 30 or so lights it found "in solid" actually were old misplaced lights.

Also to note, there was no reduction in marksurfaces using -forcegoodtree. The number actually went up a bit. Using txqbsp_xt always gives a drop of around 1200 or so. 

Download here

Changes:

- light: fix black fringes on bmodels that are touching against the world
- light: light passing through glass lights up the back side
- light: bmodels with "_alpha" < 1 and "_shadow" "1" set cast tinted shadows
- qbsp: support Quake 3 "Brush Primitives" .MAP format
- qbsp: save "_mincolor" for func_detail/group to the .texinfo file, now used by light
- qbsp: performance improvements


To elaborate on the "fix black fringes on bmodels" thing, v0.15.8 had a pretty severe bug where every func_door (or any bmodel) would have black edges wherever it touched the world, like an ugly/broken looking version of AO.

The reason I broke that in v0.15.8 was, I was trying to fix another bug, where bmodels (func_wall, etc.) that intersect the world, or have a face touching the world, would have broken lighting (usually all-black faces). Typical case where this would happen would be a large func_wall window that has a world brush slicing through it (or just touching the front).

So, that bug is back, because the "fix" I tried was much worse (black fringes on all bmodels). If you have a func_wall with black faces / broken lighting, the fix is to manually clip it against the world so it doesn't stick into the world anywhere. I'll see if I can come up with a better fix next version 

That's great to hear, I encountered the black fringe issue before and it is good to know it may be fixed on this release! 

Would it be possible to hit both bugs by having the compiler test if the bmodel intersects or not? Or would that require multiple passes or something like that? (Assuming extra passes would suck, which when it comes to speed they probably would :/) 

Performance improvements - intrigued, my latest maps have been bottlenecked by Qbsp which is wierd since vis always took the longest until recent improved versions. Curious what improvements you've made. 

@Qmaster - performance improvements are from undoing some mistakes I made when C++-izing bits of qbsp (unnecessary std::map lookups). Qbsp could be made a lot faster, though. e.g. Quake 2's is multithreaded.

Pritchard, I'm not sure if knowing if the bmodel intersected the world would help. I think I need to do something like: test whether each sample point is in the void or not, and just not use the ones that are in the void. 

How do you do lit liquids? I tried the commandline flags people are talking about here (-litturb etc.) and it just gives an error and doesn't run light. Was it removed or something? 

-splitturb option for qbsp.exe should do it; light.exe will automatically detect this and save lightmaps for the water. Looks like that option is missing from the docs.

Engine support is fairly rare (?) - I don't know what supports it, off hand.