lights in q3bsp

[Nahuel]

It is possible to add switcheable lights in a q3bsp? I do not speak of Dlights, or rtlights, i speak of the lights of q3bsp :?
I is possible ???
Thanks in advance :)

[Spike]

q3bsp doesn't normally support lightstyles.
The only way you can do it is by using shaders with some time-based rgbgen/mod effect on them. no idea if q3map2 can generate such shaders automagically or not, though the light grid will be wrong.

[leileilol]

the raven variation of q3bsp should support it somehow I think. Since you're doing it for darkplaces i'd suggest some rtlight entities for the job

[qbism]

qfusion supports lightstyles in q3bsp. There's a q3map2 switch, maybe -qfusion or -warsow. Seek out the map "ravendelux". Could also try it on DP to see what happens.

[goldenboy]

qfusion or something like Warsow is looking like a better and better candidate to make my next game project in.

I like q3bsp, as a mapper, but the lack of lightstyles was a major letdown.

Hey, maybe I'll port RMQ's Episode 1 to q3bsp and some engine like qfusion (after Quake-based RMQ is done, of course), and edit its maps to make use of patches, q3 style shaders, volumetric fog etc. On top of that I could add radically new gameplay and from-scratch new enemies. Part of me fancies doing that. Like Shambler's Castle, only much more radical (not bogged down and pissed off by a "that's-not-Quake" worldview) and using expanded versions of these maps

http://spawnhost.wordpress.com/latest-e ... reenshots/

They'll be released under the GPL anyway...

Then again, if someone makes a nice crossplatform updated idtech 4 engine, I guess I'd love that, too. I'd love anything that has at least 2004-level graphics and proper lighting, brush-based maps with support for patches and loading .obj mapmodels (... and lighting them). Proper physics would also be nice.

Maybe someone would like to join me in making something like that... the largest part, which is mapping, would already be out of the way.

Oh well, daydreaming.

[gnounc]

darkplaces has support for q3bsp, physics, and loads obj's. I'm not sure what constitutes proper lighting.
It is pretty though.

Oh darkplaces was already mentioned, and lits suggested. So I take that to mean not proper.

[goldenboy]

Proper lighting would mean higher resolution lightmaps, or dynamic lighting (or a mixed lighting model). Also shadows for mapmodels.

DP runs these maps too slowly, unfortunately. But I haven't decided yet.

[Nahuel]

Proper lighting would mean higher resolution lightmaps, or dynamic lighting (or a mixed lighting model). Also shadows for mapmodels.

DP runs these maps too slowly, unfortunately. But I haven't decided yet.

Very Nice pictures Golden_boy.
Darkplaces is the only option I can use for a simple choice: qc. What do you think about the engine CRX? The warsow engine is nice, but I do not know how much documentation there is about qfusion. If someone does something like a compiler to support lightstyles in q3bsp and darkplaces It would be the best of everything. But I think it is enough, complicated. I use some tricks (Dresk_WorldLightPulsation.qc) of kleshik to simulate a storm in a q3bsp. Anyway, these tricks of qc affecting all the lights on maps.

[goldenboy]

If you can use QC, then you can use most script languages or C.

QFusion's latest release date seems to be February 2008 - wow, that's old. Doesn't look too good. Warsow is awesome, though.

CRX - my impression of Alien Arena is very good, but I haven't looked too closely at it. I intend to do a little survey for engines I could use sometime soon, though. It doesn't have to be QuakeC and it doesn't have to be Quake, it just has to do what I need, which is running large (pre-existing) brush based singleplayer maps fast and making them look good without too many complications. Basically I want to avoid having to screw with the engine at all.

It'll be some time until the release of the project I'm currently on, so I guess I'll wait and see what happens on the idtech4 front as well. An optimized community port of idtech4 would be awesome, but it might be overkill for such an indie game. I would probably prefer static lighting mostly, too. I have experience with lighting Doom 3 maps and it is a little complicated, not to mention expensive in terms of performance. Dynamic lights only where needed would be best, hence using both static and dynamic lighting.

[Nahuel]

It's very interesting what you say about id tech 4. I am also waiting for a job well done. Anyway, many modders will launch their versions with "more HD visuals" and more requirements. I believe that also I am not a "dependent quake" but I think if I am dependent of the *. bsp format. For example, if you're not too demanding you could use for example cube 2 engine. While this engine may seem too uncomfortable, for me it is.

[mh]

My understanding of idTech 4 is that it needs to do a separate pass for each light that affects a surface. That would have been necessitated by the target hardware of the time; nowadays you'd collapse a certain number of lights (something like up to 8, but you could go higher if required) into a single pass, and do your normalization using shader math rather than a cubemap lookup. It's more expensive in terms of shader ops, but lighter on the CPU and involves less fillrate/overdraw. If you were prepared to raise the minimum spec somewhat then you could do a very efficient implementation of the lighting model.

More CPU load comes from it's animation system, which it seems to do on the CPU. That should be moved to the GPU. This would also allow for getting rid of a lot of dynamic vertex buffer updates, which, under the old GL_ARB_vertex_buffer_object model it uses, absolutely sucks (you really need GL_ARB_map_buffer_range to use dynamic vertex buffers efficiently in OpenGL). Again, it needs a raising of the minimum spec.

idTech4 uses GL_UNSIGNED_INT indexes which - on most target hardware of the time - would have actually punted the T&L stages of the pipeline back to software emulated. Ouch! (And still more CPU load - id engines do tend to be more CPU-heavy than is strictly necessary. Some day I'll write a rant about that.)

This is where it starts becoming difficult to balance the wishes of the community with the requirement to implement something in an efficient and flexible manner. I believe that the engine could quite easily go multiple times faster, but raising the GPU requirements to something that supports the hardware capabilities needed to actually do this is a pre-requisite. The old way is most definitely not the fastest, and maintaining backwards compatibility with hardware that so few people have anymore will hold you back from doing genuinely useful things.

[Spike]

I believe that the engine could quite easily go multiple times faster

you've 3 weeks after its release to at least double its speed, or I'm never trusting you again!

[qbism]

There are several mature multiplayer projects with modern lighting/mapping/engine features. But not as many single player options. DP and BerserkerQ2, what else? KMQ2 is not as advanced w/ graphics but is a powerful singleplayer modding base w/ Lazarus. Single-player monsters etc. would have to be worked into some of these advanced graphics engines, maybe like that Entities Plus project for Q3.

[andrewj]

you've 3 weeks after its release to at least double its speed, or I'm never trusting you again!

Hah, the gauntlet has been thrown

[mh]

The gauntlet has been picked up.

http://forums.inside3d.com/viewtopic.ph ... 603#p40603