Quake3World

Ingnore the outdoor lighting directions for the moment as you can obviously see, they are WIP, and so colour and brightness/direction will change some what. Just to let know of our progress:

Nice... needs better skybox.

So basically it's DOOM 3 with a good netcode?

Next up: Remodel everything.

rep wrote:So basically it's DOOM 3 with a good netcode?

Next up: Remodel everything.

What, like this?



Or model these guys?

looks nice, but turn AA on

o'dium wrote:

rep wrote:So basically it's DOOM 3 with a good netcode?

Next up: Remodel everything.

What, like this?

Ruh roh... Show us the per pixel normals on this one.

So they've done it to Q1 and Q2, and D3 has it, so why dont they start updating Q3 to have per-pixel lighting?

source hasn't been released yet

I just have one concern.
How does the engine handle a much higher number of polygons like we'd expect to go with a game with such nice lighting? Has the engine been tweaked for this? Even the engine (in Q3A) will choke on a map that would run fine in COD or something, if I remember correctly.

It wont matter much how nice the lighting and models are if the engine shits itself running with that many polygons. :icon8:

Doom 3 has far higher polycounts than Q2

Of course it does... What's that got to do with anything, though?

Wasn't your question about the combination of high polycounts and that method to calculate lighting? Since Doom3 has much higher polycounts than Q2 I don't see why there should be any problem for Q2E to implement PPL into Quake 2.

If you're talking about o'dium's high poly models though, I'm not too sure about that either.

No, I wasn't addressing the lighting at all.

Just the engine's ability to deal with a high number of polygons.

Q3 code is to be released soon (As soon as those who have licensed it are done with their work according to id), then it probably will be there also in a while Will be very sweet for gaming vids

Psyche911 wrote:Even the engine (in Q3A) will choke on a map that would run fine in COD or something, if I remember correctly.

Q3A does rendering (and esp. texture mapping) the expensive way, i.e. no LOD[1], no falloff, no mipmapping[2], etc.
EDIT: I was going to make a point with all this but it's too hot to think...

[1] Except for some models.
[2] Of faraway geometry, not r_picmip.

^misantropia^ wrote:

Psyche911 wrote:Even the engine (in Q3A) will choke on a map that would run fine in COD or something, if I remember correctly.

Q3A does rendering (and esp. texture mapping) the expensive way, i.e. no LOD[1], no falloff, no mipmapping[2], etc.
EDIT: I was going to make a point with all this but it's too hot to think...

[1] Except for some models.
[2] Of faraway geometry, not r_picmip.

uh, Q3A does LOD for in-game models (perhaps not mapmodels although I'm not sure of that), it does LOD on curved surfaces, it doesn't LOD ordinary brushes though.

I think Q3A also does mipmapping, although the miplevels aren't pre-stored in the texture file like is done for Q2. I reckon Q3 calculates mipmaps at load time.

Psyche911 wrote:No, I wasn't addressing the lighting at all.

Just the engine's ability to deal with a high number of polygons.

Dude...if they can recode the engine to use per-pixel lighting why the hell couldn't they modify the polycount on the models?

Sure it can be done... but it depends if their coder has good enough skills to do so.

Eraser wrote:

^misantropia^ wrote:

Psyche911 wrote:Even the engine (in Q3A) will choke on a map that would run fine in COD or something, if I remember correctly.

Q3A does rendering (and esp. texture mapping) the expensive way, i.e. no LOD[1], no falloff, no mipmapping[2], etc.
EDIT: I was going to make a point with all this but it's too hot to think...

[1] Except for some models.
[2] Of faraway geometry, not r_picmip.

uh, Q3A does LOD for in-game models (perhaps not mapmodels although I'm not sure of that), it does LOD on curved surfaces, it doesn't LOD ordinary brushes though.

I think Q3A also does mipmapping, although the miplevels aren't pre-stored in the texture file like is done for Q2. I reckon Q3 calculates mipmaps at load time.

Yeah, r_linear_nearest etc., can't remember which precisely. Plus you can see the mipmapping in action :icon26:

bitWISE wrote:

Psyche911 wrote:No, I wasn't addressing the lighting at all.

Just the engine's ability to deal with a high number of polygons.

Dude...if they can recode the engine to use per-pixel lighting why the hell couldn't they modify the polycount on the models?

Jesus christ you people are dense. No offense, but fucking work on your reading comprehension. Of course they can use higher polygon models. That's not the problem. Let me clarify:

1. They are raising the polycount.
2. The vanilla Quake 3 engine shits itself when the polycount reaches levels seen in RtCW or COD.
3. I'm sure the Quake 2 engine is at least as susceptible to this if not more so, being that it's older.
4. Therefore, the Quake 2 engine will shit itself with high poly models & architecture unless they've tweaked the engine to work better with more polygons.

Again, no offense, but this is the third post where I've said the exact same thing. Some people understand, and some just aren't getting it.

Edit: Maybe wait for the anaesthesia to wear off before posting again!

A SHIT LOAD of additions and modifications have been added to the engine to allow support of all this "new stuff". Dont worry, we are not about to just add X models and X textures and forget it. We are not tenebrae.

lol
That's good to hear. All I ever see is PPL, so I wasn't sure.

Psyche911 wrote:

bitWISE wrote:

Psyche911 wrote:No, I wasn't addressing the lighting at all.

Just the engine's ability to deal with a high number of polygons.

Dude...if they can recode the engine to use per-pixel lighting why the hell couldn't they modify the polycount on the models?

Jesus christ you people are dense. No offense, but fucking work on your reading comprehension. Of course they can use higher polygon models. That's not the problem. Let me clarify:

1. They are raising the polycount.
2. The vanilla Quake 3 engine shits itself when the polycount reaches levels seen in RtCW or COD.
3. I'm sure the Quake 2 engine is at least as susceptible to this if not more so, being that it's older.
4. Therefore, the Quake 2 engine will shit itself with high poly models & architecture unless they've tweaked the engine to work better with more polygons.

Again, no offense, but this is the third post where I've said the exact same thing. Some people understand, and some just aren't getting it.

Edit: Maybe wait for the anaesthesia to wear off before posting again!

Jesus christ, work on your understand of the entire conversation. Adding support for per-pixel lighting on the scale they have isn't like clicking a filter button in photoshop. An engine isn't some mystical beast that you through code at and hope it works. If they have the skill to make is this far the clearly they are able to uncap modeling restrictions.

I fully understand what I said. I've got the source to both Q1 and Q2 and have recently been working on Q3 clones using C# and DX9.

Geebs wrote:Yeah, r_linear_nearest etc., can't remember which precisely.

That's texture filtering, which isn't the same thing.
@Eraser: true, I forgot about curve LODs.

i think the bumpmapping needs some work...