Quake3World

Random brainfart:

I was thinking of combining Q3MAP2's lightstyles + normalmapping + external lightmap features and try doing a tiny Doom3 like environment inside of vanilla Q3.
I'm sure I'm not the first one to think of this, so I'm wondering if it's possible or if I shouldn't bother?
Likely the lightmaps would need to be very dense to not look like ass, but for a tiny map it might work since Doom3's textures aren't terribly high res?
The Hell theme would probably work best with the chunky brick walls etc. Might fit into Q3's theming.
I know I could leverage the deluxemapping features in ioQ3, but the challenge is doing it with a 1999 level featureset

Spiney wrote: Random brainfart:

I was thinking of combining Q3MAP2's lightstyles + normalmapping + external lightmap features and try doing a tiny Doom3 like environment inside of vanilla Q3.
I'm sure I'm not the first one to think of this, so I'm wondering if it's possible or if I shouldn't bother?
Likely the lightmaps would need to be very dense to not look like ass, but for a tiny map it might work since Doom3's textures aren't terribly high res?
The Hell theme would probably work best with the chunky brick walls etc. Might fit into Q3's theming.
I know I could leverage the deluxemapping features in ioQ3, but the challenge is doing it with a 1999 level featureset

There was a really long time back when Ydnar was working on the Q3map compile tools and he set it up so you can have 1 to 1 ratio light map density. He then made it so light map calculations would take normal maps into account. These days our computers can very easily handle a heck of a lot of light map pages. In fact I have been told the common texture resolution for nearly everything is 4096 on next generation games. In quake 3 the unmodified light map page is likely in the 128 - 256 range.

In other words if you have the processing power to keep compile times in range I say you should look into setting up normal mapped shaders as well as double density lightmaps for a regular sized level.

Ah right, it was Ydnar. Thought it had maybe been Sock.

IIRC, all the effort put into trying to make bump mapping show up in Q3A using q3map2 was sorta disappointing... result-wise at the time.

AEon wrote:Ah right, it was Ydnar. Thought it had maybe been Sock.

IIRC, all the effort put into trying to make bump mapping show up in Q3A using q3map2 was sorta disappointing... result-wise at the time.

Yeah, i suspect the results will be lackluster unless maybe you can rock 4 to 1 texel density on your light maps. Otherwise you just wont see the detail. Due to the fact you will have exponential real estate costs its likely going to be a difficult challenge to find a balance.

Doing your lighting this way has been explored before and there is good reason it was never adopted as something included in a shipping game. However these days the average PC is practically bleeding ram so it may work perfectly fine. *shrugs*

• Q3 maxes out texture/lightmap page sizes at 1024x1024 (1024x2048 textures work, but 2048x2048 crashes the game. Lightmap pages must be square).
• Q3's default texture resolution is 2x2 texels/game unit.
• At a 1:1 texel to luxel density, that means that the maximum surface size allowed is 512x512.
• External lightmaps have an issue with mipmapping, causing what looks a bit like light bleeding on edges when viewed from a distance.
• Besides, a large part of what makes Doom3 and newer engines look significantly different is the use of specular maps, which Q3 can't fake in the same way.

Sure it's all possible (I've tried it), but there are all sorts of limitations and the effect in most cases is hard to notice compared to say, just a well lit map with soft shadows, blurring, and maybe some faked light effects. You can build a little test map as an academic experiment as I did, but for an actual playable map, it's just not particularly practical.

I'd say that the most interesting thing about the whole effect is the generated lightmaps, which makes for some pretty cool looking abstract art...

[lvlshot]https://farm9.staticflickr.com/8240/8510544241_e16000eae6_b.jpg[/lvlshot]
[lvlshot]https://farm9.staticflickr.com/8248/8511656848_ac89904d4b_o.png[/lvlshot]

Doesn't id Tech 5 do a significant amount of precalculated lighting? IIRC, it's baked into the megatextures.

obsidian wrote: Doesn't id Tech 5 do a significant amount of precalculated lighting? IIRC, it's baked into the megatextures.

This was what I observed when I was asked to make a test multiplayer level for Rage. Everything was baked into the megatexture even specular. In fact the only way to apply any kind of true shiny effect was to flag certain surfaces to display a env map.

So with all of this said I have a question for you Obsidian.

I plan to make a level for Entity plus in future. Given all of the advancements with q3map2 and GTKR what would now be the de facto compile settings and development pipeline that takes advantage of what is now available?

obsidian wrote:Doesn't id Tech 5 do a significant amount of precalculated lighting? IIRC, it's baked into the megatextures.

Correct.

Castle wrote: I plan to make a level for Entity plus in future. Given all of the advancements with q3map2 and GTKR what would now be the de facto compile settings and development pipeline that takes advantage of what is now available?

Quite a few of the more 'current' improvements/developments actually don't depend on any particular compile settings.
Texture ratio resolution can be set by gtkr settings or in the shaders.
Normalmap is set up in shaders, as is external lightmap size
Higher resolution lightmaps can be applied globally through worldspawn, or set individually by adding the key/value to grouped geometry or models.

I updated GtkRadiant 1.6.4 with some newer compile settings. Those should be pretty good for most general compiles. If tweaks required, see http://en.wikibooks.org/wiki/Q3Map2

Everything else is more or less the same. A lot of new textures are created using a higher texture ratio (0.25 instead of 0.5). Q3Map2 has some better handling of surface/sky shaders and applying a bit of blur to shadows to limit jagged shadow edges. See the shader manual linked in my signature.



Oh yeah, and you can do sparse voxel octrees in Q3 now.

obsidian wrote: Oh yeah, and you can do sparse voxel octrees in Q3 now.

I am assuming this is being used for occlusion culling. Is it a hack of the BSP system or is it a new system that works along side of what is there?
I do not believe I have worked with Sparse Voxel Octrees yet however I understand basically how they work. What are the top 3 things to keep in mind when working with SVOs as a designer?

Ill take a look into the documentation before I get my hands dirty with the new tech. It wont be for awhile as my portfolio is sucking up all of my time atm.

I was joking. If Q3 supported SVO's, companies would be licensing it again.

SVO's toss polygon rendering to the wind and might be eventually what next next generation game engines will use, but are very limited right now because they rely a lot on raytracing for rendering and currently don't support deformations.

obsidian wrote:I was joking. If Q3 supported SVO's, companies would be licensing it again.

SVO's toss polygon rendering to the wind and might be eventually what next next generation game engines will use, but are very limited right now because they rely a lot on raytracing for rendering and currently don't support deformations.

Ah man for some reason I confused SVO with using octrees for occlusion culling or storage of 3d environments. I missed that clearly funny joke by so many miles I dont even think I landed on earth HAHAHA

"Oh btw its a completely insane next next gen rendering pipeline but not much else has changed."