One last time, does Ut2 utilize vertex shaders in any way?

Through these forums I read that epic optimized the game for PS 1.4 (no extra effects, only performance) and wanted to know if similar optimizations made with vertex shaders for the game?

Aren't there some physics/particle effects which would benefit from this acceleration?

Thankyou
 
Re: One last time, does Ut2 utilize vertex shaders in any wa

Luminescent said:
Through these forums I read that epic optimized the game for PS 1.4 (no extra effects, only performance) and wanted to know if similar optimizations made with vertex shaders for the game?

Aren't there some physics/particle effects which would benefit from this acceleration?

Thankyou

The UT2K3 D3d settings .ini has an entry for VS, so at least it would appear that they are currently being used in some fashion by the engine. Indeed, as the goal of this engine at this point is longevity, I would be very surprised if it did not (as VS use in hardware is an established route forward these days.) Coincidentally, I think that longevity is one of the reasons why UT2K3 has one of the most cpu-limited engines I've ever seen.

I also think that as VS and PS become more common and find support within APIs, the need for TMUs in hardware is going to diminish looking ahead with their incorporation in hardware mainly a matter of backwards compatible performance. Just my lily-livered and putrid two cents... :LOL:
 
Re: One last time, does Ut2 utilize vertex shaders in any wa

WaltC said:
I also think that as VS and PS become more common and find support within APIs, the need for TMUs in hardware is going to diminish looking ahead with their incorporation in hardware mainly a matter of backwards compatible performance. Just my lily-livered and putrid two cents... :LOL:

Heh. Care to put a time scale on that statement? :)

Entropy
 
Re: One last time, does Ut2 utilize vertex shaders in any wa

Entropy said:
WaltC said:
I also think that as VS and PS become more common and find support within APIs, the need for TMUs in hardware is going to diminish looking ahead with their incorporation in hardware mainly a matter of backwards compatible performance. Just my lily-livered and putrid two cents... :LOL:

Heh. Care to put a time scale on that statement? :)

Entropy

Gradually, over the next 12-24 months?.... :D
 
UT2K3 uses 'minimal' vertex and pixel shaders (from mark rein in an online chat a while back)

this is straight from Vogel

"Where present, pixel shaders (1.1/1.4) are only used for a slight
optimization for terrain rendering. No difference in visual quality between
DX7 and DX8 HW."


I don't know about the vertex shader specifically...
 
I think I remember reading somewhere that the engine fully supports VS and PS but that they are only used in a minimal fashion in UT'03. I woud guess the .ini values are left overs from testing?
 
We don't use vertex shaders in UT2003 though we do use multiple vertex streams in conjunction with the fixed function pipeline which is the reason why we have to revert to software vertex processing on SiS cards like the 315 or Xabre as they only expose one vertex stream.

-- Daniel, Epic Games Inc.
 
Vogel (or anyone who understands, for that matter), what do you mean by processing "multiple vertex streams"? I have never heard of those terms used in conjuntion before.

BTW, thanks for the responses.
 
A vertex has multiple attributes (position, normal, texture coords, etc.). You can combine all of them into a single stream (this is the "traditional" way), or split them into different streams (one stream for position, another for normal, etc.).
 
Re: One last time, does Ut2 utilize vertex shaders in any wa

WaltC said:
I also think that as VS and PS become more common and find support within APIs, the need for TMUs in hardware is going to diminish looking ahead with their incorporation in hardware mainly a matter of backwards compatible performance. Just my lily-livered and putrid two cents... :LOL:

I'd actually be surprised if even NV2x/R200 hardware had fixed-function TMU's. It just seems natural that the fixed-function pipelines would be emulated by the vertex and pixel shaders.

Going into the future, I doubt we'll see a major departure from the processing that is found in the most basic of texture mapping scenarios. That is, I'm pretty certain most 3D will still use that type of processing very commonly (i.e. A*x + B*y where A,B are constants and x,y are filtered texture color values), though we may see additional forms of processing gain more hardware-level optimization, such as sin, cos, exponentials, logarithms, and the like (Yes, you will be able to do all of these with NV3x hardware, and other hardware...not sure which, but the question is still up in the air about how long each will take to compute).

And as for fixed-function programming in general, it will always have its uses, primarily for the simple reason that it's easier to program using the fixed-function interfaces.
 
Considering how recent an engine UT2 is, why isn't it using vertex shaders if present?

Again, Epic is holding software development back by NOT supporting tech that is quickly becoming mainstream. Not Unreal, but definitely Uncool. :-?


*G*
 
Grall,

I asked this Question at the UT Mod summit. Tim Sweeny said basicly that the install base of DX8 (PS/VS) is not big enough to warent support for DX8 ATM. Now that will soon change. But look at the bigger picture here. Epic not only helped DE to make UT2k3 but they have had their new engine availble to be used in other games for some time now (games like AA, Splinter Cell. ect) So they have their customers to also consider. Do they make them wait until they get PS/VS support in and working to its fullest potential? Or do they raise the bar like they did with graphic and ship that engine out while they work on the next one? If you read any of the gaming forums you already see people bitching that UT2k3 is too much for their systems. You add on VS/PS on that then you make it that much harder on systems and you have even more people bitching or worse people that don't buy your game. All companies want to maximize their chance for sales. Making your game require hardware that its above the install base (which is still at dx7 thanks in part to GF4 mx) cut into that sales potintial and thats just not smart. I want DX8 games as badly as the next guy does, but until DX8 cards become main stream, then we will have to wait....
 
jb, he didn't say "require" but "using...if present". This is directed at the part of your post after "You add on VS/PS on that then..."
 
jb,

Epics customers, that's EXACTLY what I'm talking about when I say they're holding back software development.

Since Sweeney won't do the job others are already doing, we're going to see a string of licensed games, all of which lack hardware acceleration of these features. No wonder the host CPU gets strained so hard, considering the polygon densities in UT2!

I don't understand why you think systems would be even more bogged-down by off-loading work onto the GPU. That's just plain backwards thinking!


*G*
 
Re: One last time, does Ut2 utilize vertex shaders in any wa

Chalnoth said:
I'd actually be surprised if even NV2x/R200 hardware had fixed-function TMU's. It just seems natural that the fixed-function pipelines would be emulated by the vertex and pixel shaders.

I think "TMU's" should read something like "fragment pipelines". If that's what you mean I suppose you're correct, otherwise I can't see really how a TMU can be anything else than fixed function.
 
Grall said:
Since Sweeney won't do the job others are already doing, we're going to see a string of licensed games, all of which lack hardware acceleration of these features.
I think you're confused or worded your sentence incorrectly. Perhaps you meant to say "... all of which lack these features that can benefit from hardware acceleration". There's a difference :)

No wonder the host CPU gets strained so hard, considering the polygon densities in UT2!
?? This is a CPU's job and not a vid card's job? We're talking poly load here, not vertex shading.
 
As far as I concerned a TMU is the logic that is used to sample from a texture. Nothing more than that really. TMU of course stands for Texture Mapping Unit.The following diagram is how 3dfx defined a 'TMU'
tmu.png

The 'Texture Combine Unit' part isn't exactly relevant anymore with the Flexible pipelines, but that is not the only function of a TMU.

Actually here is a second image (also from 3dfx) that has the 'Texture Combine Unit' removed from the TMUs
tmu2.png

In that second image, it would appear that 3dfx didn't really seem to consider a TMU to be anything more than something that accessed texture memory.

-Colourless
 
The TMU is just a black box that given a set if texture coords returns a filtered texel. Not really a register, and it doesn't have any mathematical abilities beyond filtering. In fragment shaders you'll need to sample from the TMU into a register, no register is defined from the beginning of the shader execution.
 
Back
Top