Those are already there. They're called func_wall. 

Don't be dense. 

1) func_wall's don't cast shadows

2) using an brush-entity in the same manner as detail brushes are used in Q3 will result in you exceeding entity-related limits imposed by the engine VERY fast. 

3) brush models are rendered very ineffeciently compared to world brushes, resulting in much higher wpolys, and other things like #clipnodes. 

Talk to a coder and he'll tell you the samething. You would need to rewrite the .bsp format to have Q3-style detail brushes work. 

what rpg said and func_illusionary works too.
as for the shadows, use antilight dammit ;) 

You would need to rewrite the .bsp format to have Q3-style detail brushes work.

I'm not arguing with that. But that's not what you said.

Funcs only work as a detail substitue in small, isolated places. And even then, they still add to the bmodel count and mess with the lighting if, for example, you want to make all your protruding light fixtures detail. It would likewise become impractical, or at least difficult and undesireable, to make all of the faceted psuedo curved architecture in a map funcs.
For e.g. a terrain map, Q3 detail makes the whole process easier to implement with vastly reduced compile times. Funcs are - take my word for it - not an option in this case.

Yes, detail isn't going to happen because of the bsp format, but that's no justification for declaring funcs a perfectly acceptable alternative anyway. Because in many cases, they're not. 

Yes, detail isn't going to happen because of the bsp format, but that's no justification for declaring funcs a perfectly acceptable alternative anyway. Because in many cases, they're not.

Of course they're not. But they're the closest you're going to get in all practical situations. I was assuming Jago was familiar with the limitations of using bmodel ents, and thus he could make an informed decision regarding when to use them and when not to. 

The fact that can sometimes manage to pull off some impressive geometry does not mean I am an engine expert :) As a matter of fact, I am pretty clueless when it comes to the inner workings of the Quake engine (or Unreal for that matter, even though I released 10 maps for that)... 

about bmodels and lighting. There is a place in my map where I have a brush model "fence" thing sticking up out of the terrain. Now, it had to be bmodel obviously, because you just don't want to go around arbitrarily jutting other brushes into triangulated terrain, but of course I don't get the shadows cast. Now I'm not too bothered about that, but I wondered if any light gurus (*hint* *hint* Aguirre ;) )had considered the possibility of making selected bmodels cast shadows. Considering how it would only seem to involve changes to the light.exe, and not to the .bsp format or engine, I was just wondering if it would be a theoretically possible thing to implement, or not. 

is that what you mean ...? 

I did find some Fullbrights that were not noticable in Fitzquake - that I can fix.

Ah, this must be the bug in fitzquake that doesn't show color 255 as fullbright, even though winquake treats it as fullbright. Fixed in the next version, BTW :) 

I didn't know about that. And that makes it easier for me now as Texmex did not correct one fullbright pixel in one of the problem textures even though it corrected the others.

Now, if I can just clear this packet_overflow problem a 'new' SP map is in the offing ... 

I am building my Q1SP in 2 parts for faster compile times and general convinience. Today I have realised that if I put both pieces together now and properly detail places which are missing detail, I will easily hit ~3500 brushes (without clip brushes and such). And this is Q1. AND both "pieces" are still missing many rooms. This puts my rough estimate of the final brushcount to 4000-4200 brushes. What kind of problems should I be expecting when I will eventually start merging both pieces together? 

Difficult to say with only those figures. # brushes is no problem for the compiler and brushes don't even exist in the engine (transformed into other objects).

Typical problems are clipnodes (especially if the map leaks) and marksurfaces, both related to complexity of architecture. Then comes entity overflows and vis problems if you're not careful with layout or brush amount/alignment.

Try to make complete builds as early as possible to get indication of problems. Then post here to get tips on how to proceed. 

My current Q1 map is around 7700 brushes and like aguirRe says, the brushcount doesn't really matter for the compiler - it's what the compiler turns those brushes into that can be a problem. Without clipbrushes, my #clipnodes is around 50,000. With loads of clipbrushes applied to out-of-reach areas I can bring the #clipnodes down to around 30,000.

#marksurfaces is another important figure. The limit here is again 32k, but you can exceed this limit in many engines and not have any problems. 

The map I showed pics of the other day is about 51oo brushes at the moment. It was started by joining 5-6 speedmaps I had lying around, a bit like you would like to do.

But as Kinn mentions it's the number of #clipnodes and #marksurfaces that matters.
Kinn mentions that #marksurfaces is limited to 32k, but some engines still can run it.
So far I have 41048 #marksurfaces and the map still loads in all the engines I tried it on, including the orig. GLQuake.exe.
Don't know about software Q since I cant run that! 

for the fence... i'm not sure what the technical problems might be, but you could try this:

rebuild the fence inside the func_wall, (make sure the texture alignment is identical to rule out z fighting) except cut off the bottom of the fence brushes just before they hit the terrain to stop them from splitting up the brushes.

i remember a while back, there was an article in pcgamer where some dude who mapped for half life gave "tips" to help map and he mentioned that in the desert maps, he had raised the catii 1 unit above the ground to not split up the terrain yet keep the shadows.

i remember suggesting that here before but it was not greeted warmly, so there may be technical aspects to this method that are negative... someone want to add to that? 

Single room map, player_start, single rectangular brush touching the floor but not the walls or ceiling = 210 clipnodes and 48 marksurfaces.

Add one default light = 125 clipnodes and 48 marksurfaces.

What principle is at work here and is it a useable feature when considering excessive clipnodes? 

Ah thanks - I'd forgotten about that technique. I may just leave it as purely func_wall though, considering how the lighting in that particular area is fairly flat (also I'd imagine having a world model fence there would give vis a fair bit to chew on ;) ). 

I'll try to dig a bit deeper what the issue is about marksurfaces. At least I now think that the warning about them being >32k is probably not correct. 

The warning for marksurfaces <32k seems right after all, but there's another limit that should be checked too; #faces must also be <32k in normal engines. I've now added this warning to tools/engines.

I haven't been able to find out why some maps can exceed the 32k marksurfaces limit and still run OK in normal engines, it appears to be just "luck" ... 

that might be interesting: http://www.gamedesign.net/node/view/639 

Hmmm...I can't seem to call ambientsound() midway through the game - it only seems to work at level start - is it supposed to be like that? 

limitation of the engine. :P

there's a hacky way to get around it... frikaC explained it to me a while ago.

basically you can use my code:


float SVC_SPAWNSTATICSOUND = 29;
void(float soundnum, vector org, float ambvolume, float atten) spawnambient =
{
WriteByte(MSG_ALL, SVC_SPAWNSTATICSOUND);
WriteCoord(MSG_ALL, org_x);
WriteCoord(MSG_ALL, org_y);
WriteCoord(MSG_ALL, org_z);
WriteByte(MSG_ALL, soundnum);
WriteByte(MSG_ALL, ambvolume * 255); //translate this into a value between 0 and 255...
WriteByte(MSG_ALL, atten * 64);
};


soundnum, in this case, is actually the numerical value of a precached sound. the number is equivalent to when it was precached. so the first precached sound is 0, then 1,2,3, etc...

look through the qc files and you'll find the first sounds to be precached are the ones found in weapons.qc.

ambvolume * 255 is so you can use a 0 to 1 value and it will be converted into a number between 0 and 255.
same for atten, but in this case, it needs to be multiplied by 64.
don't ask why... i don't really know. something to do with bytes and whatever... 0 to 255 is 8bit or something, a short is 64... meh. :P