The QSG died a long time ago. 

If I want details casting shadows but the game still to be fast (you need that in dm) using func walls, I had better to make the whole map in q3 bsp? There aren't necessarily that many unique models in dm maps so the shadow-casting func_wall would work and would need just a light.exe mod, but I can see the models running out in sp maps a lot, so the compiler coders don't think it's worth the trouble.

Would it be that hard to try an example q1 .map -> q3 .bsp with q1 ents?

There are tons of q1 .map files that can be edited in gtkradiant and converted to q3 maps and bsp:s. (metl's ant or czg's terra for example)

Then people (mappers) can load them up in fte or darkplaces and start listing the things that look right / don't look right and we see where we can move from there. And what the fps really is there... You really need solid 77 for dm. And physics must be similar to current q1 bsp.

If the whole thing works, someone like the ezquake people can port it to their engine and you can play qw in bigger better maps too. Now it's mostly just boxroom-L-corridor-boxroom.

I've never mapped for q3 so I don't know how to do all that but someone most certainly can. Hell, I don't even have internet at home. 

That is a bloody good idea. I've actually loaded up a lot of existing Q3DM maps in DarkPlaces and run them with Aard's DMSP mod - the monsters run around no problem, although at the time, patches didn't block tracelines (so monsters "see" straight through patches), so there still needs to be some tweaking done(unless that's been fixed already) 

for SP only. Forget dm-online. DP is not QW (thats 1 of the many reasons) 

How things are is no indication of how they should be.

And fteqw is qw. Go check #fte. 

point is, there is not much need for q3 tech in qw
but there is in SP 

need for q3 tech in qw as much as there is in sp.

Look - it's like this:

1) sp maps generate fps etc problems since they are so huge and detailed. q3 tech to the rescue.

2) dm maps must have very stable and high fps, so even moderate maps generate fps problems. q3 tech to the rescue. 

I rarely play Quake 3, mostly because Q1 is a lot more fun, but I can't recall seeing ...

1) Any lifts, trains or moving parts in Quake 3 maps. It's always jump pads.

2) Any holes in the walls like on DM1 or DM2

3) Very many objects. The maps are all flat surfaces, no braziers or torches or anything.

4) Can't recall seeing any buttons.

My stereotype of a Quake 3 map is one that looks good in a screenshot but is devoid of the little things that keep them from feeling sterile.

It is my perception that, if Quake 3 gets good FPS in multiplayer, they did it largely by making the maps flat-like and featureless.

Bases, garages, tunnels ... not complicated stuff like the rocky terrains in Lunaran, for example.

Again, I'm no Quake 3 map expert but I was never impressed by the terrain in any of them. 

Better play Quake 3 and it's custom maps... At least as long as until you find those things ;) 

with all due respect...

can I have a toke of whatever it is you're smoking? :} 

I don't really see what the maps from Quake 3 have at all to do with q3bsp support for Quake. *WOOSH* was apparently the sound of point, flying at sonic speeds high above your head. Besides, the even the stock Quake 3 maps have the things you are listing, you aren't looking hard enough. 

q3bsp format in quake just means better tools, for the most part. the game would play almost exactly the same. 

;) 

re-read this thread a bit plz 

I have consistently seen significantly more performance in q1 .map files recompiled as q3bsp using q3map2, despite both using the same renderer in darkplaces, it is simply a matter of the compiler being more effective.

I recommend -meta when compiling maps with q3map2, and you can also mark materials as terrain, which causes them to be merged together and smoothed (this can be really great for detailed walls and things, not just terrain, keep your mind open to new ideas :).

I recommend using the terrain grouping in q3map2 very heavily for performance, it can get the surfaces (wpolys in q1 terminology) in r_speeds down to double digits while having thousands of actual polygons visible, effectively this is telling the engine to render things as models, just a lot of polygons to throw to the graphics card without much thought about it.

I'm sure everyone here knows that wpolys are the biggest fps killer in a q1bsp map, and q3bsp offers a way to reduce wpolys without sacrificing detail.

Make no mistake about it, q3bsp is more difficult to map for, it's much more technical with all the detail/structural flags and CAULK texturing of all hidden surfaces, this I consider to be the worst thing about q3bsp.

However when you are already packing so much detail into a map that it runs poorly in q1bsp, the extra work is not that annoying when it makes your creation actually play well as you envisioned it, rather than cutting back on detail.

Now some facts about q3bsp compared to q1bsp:
Physics - no differences, except that modders can add things like crouching (which never works right in q1bsp because it only understands bullets, players, and shamblers).

Lighting - q3map2 has much nicer lighting features than any of the lighting utilities for q1bsp, it even has optional radiosity.

Vis - detail brushes are a better alternative to func_wall for keeping down vis times, you can easily have vis times under 1 second if you build most of a map out of detail brushes, the structural brushes only need to define the room shapes for vis. You can also do hint brushes to tweak vis behavior a bit (rather than using various visible brushes sticking out into a hallway to cause an intentional bsp split, you can use invisible hint brushes for the purpose).

BSpline Patches - curves can be more convenient than making a lot of brushes, they should be used in moderation however (when overused they become merely a gimmick, serving no useful purpose), they can be useful for terrain because they are easy to edit.

Models - the ability to embed models and have them be properly lit and shadowed by the light utility is quite cool, they can even be made solid with a spawnflag in the misc_model entity, allowing you to model large pieces of architecture that would be more difficult to build/texture as brushes and stick them in a map, they render really fast too.

Model lighting - as mentioned any models you embed in the map are properly lit, but that is not all - dynamic models are lit by a q3bsp technology known as the lightgrid which applies directional shading (a big visual improvement) and works properly for airborn entities, curing the 'very bright player while jumping over a lava pit' problems in q1bsp.

Q3 shaders - FTEQW supports Q3 shaders fully, DarkPlaces supports some very basic features of q3 shaders such as:
blendfunc - you can make 'light cones' by simply making a brush with a gradient texture and blendfunc one one, also known as blendfunc add.
deformvertexes autosprite - makes a brush face look at the viewer at all times, a sprite.
deformvertexes autosprite2 - similar but stays upright, like doom sprites, useful for torch flames.
Several others are also supported, but those are the most useful Q3 shader features supported by DarkPlaces.

I hope this clarifies the thread subject (Q3BSP for Q1 SP).

Kinn: curve collisions were added to darkplaces back in mid-2004.

Baker: ever checked the r_speeds in those q3 maps? the triangle count is quite a bit higher than most q1bsp maps, and they DO have a lot of light fixtures (including wall sconchs, glowing skulls, burning barrels, among other things) and other detail on the walls. I don't contest the fact they are overall rather boxy though. How about taking a look at Nexuiz nexdm02, which has curving hallways and other varied architecture, and comprises over 300,000 triangles (which would simply not be even remotely possible in q1bsp). 

do the compilers / darkplaces / fte / support q1 ents in q3 maps? If yes, what are you waiting for?

We need examples:

1) a q1sp .map -> q3 bsp.
http://www.celephais.net/files/ant_src.zip

2) a q3 .map with some added q1 sp ents. Either from scratch or a q3 dm map. -> q3 bsp.
(someone who plays/maps q3 paste .map url here)

Upload the bsp's to a site. Paste url here.
Let people play with dp/fte to test. 

just load any q3dm map with DMSP mod 

it's not the same, entities in the bsp, triggers etc! 

Uh, who cares? There's little chance of that not working correctly, it's the visuals people are interested in here at the moment anyways. 

and u didnt even try 

The entities and triggers etc are completely detatched from the engine and compilers.
If you make a Q3 bsp with Q1 entities, you get a Q3 bsp with Q1 entities.
Nothing in the compilers or engine gives a crap about that. 

"what are YOU waiting for?" bambuz 

Some of my older maps were built in Q3Radiant, and I released both the q3 source .map plus a q1 .map. The only thing you need to do there is recompile the Q3 .map with q3map2 (no need to convert it) and convert the textures to .jpg or .tga (easy to do with TexMex). Try RPGSP1. 

what czg said.

Play DMSP and all the entities in the q3 map that share the same name as the corresponding q1 entities work as you would expect them too. 

You can take the .ent file from a Q3 .bsp and rename the map items to fit with Q1. I've done this with a couple of Q3 maps so far (q3tourney2, ospdm2, & cpm23. FTEquake will load the .ent and (netquake).progs so DM vs. bots is playable. Omicron bots don't work with FTE but Zeusbots work somewhat.