Software weighting as fast as Hardware

Originally posted by ToolTech:
[b]… so you matt say that all extensions that can be replaced by vertex programs and fragment programs shall be obsolete or ?

If you take the EXT weight version out you should also take away all other extensions that can be replaced by Fragment programs and vertex programs to keep OpenGL clean… and then you only have some data transfer extensions + fragment + vertex progs left…

[/b]

wich will be the future, yes… if you take a look at the extensionlists of the nvidia cards, you find tons of extensions wich are simply obsolente, stupid, useless, or bether combined into one extension…

but on the other hand, backward compatibility has to stay there, so the old extensions should stay supported…

but how about moving your project to GL_ARB_vertex_program? first just write a wrapper for the original vertex weighting… then think of optimizing even… it help’s to drop the old stuff… i know… why changing as its working…? dunno

Originally posted by davepermen:
but how about moving your project to GL_ARB_vertex_program? first just write a wrapper for the original vertex weighting… then think of optimizing even… it help’s to drop the old stuff… i know… why changing as its working…? dunno

But ARB_vertex_program ain’t supported on all platforms, even for “recent” cards. It’s sad the GeForce4 Ti I got 4 months ago is now obsolete because of the lack of up to date drivers.

BTW, why is there such a gap between NVidia’s Windows drivers and Linux ones when changes are not platform dependant ? (and when can we expect NV30 emulation to be part of the linux driver ?)

Julien

Originally posted by ToolTech:
[b]Measure the EXT extension versus software.

In a typical situation I get 1000 FPS using the EXT version on a GForce 4 and 750 using SW version.
[…]
[/b]

1000 FPS isn’t a real-life situation.
if you want to measure the real difference, you have to test it with some background geometry, or draw your skinned character more than once in a frame…

and what about multipass rendering ???
what if you have do draw your character more
than once in a frame (ie. once per lightsource…sounds familiar ? )

another scenario:
if you have a scene with very much characters, you can save processing time when you compute the skinning of distant characters not in every frame (ie. every 5.th frame). with HW you MUST skin your character every time it’s rendered (even with VP’s)

in both cases it turns out, to be much more practical to do the skinning in SW than in HW…

The reason for potentially dropping support for EXT_vertex_weighting is that there is a “not insignificant” burden in driver complexity associated with maintaining functionality that we see as 1) usually not a performance win, 2) almost completely unused, and 3) essentially an extension to the dead-end fixed-function world.

Had this extension gained widespread adoption, the story would be different.

If we were still living in a fixed-function world, the story might be different.

Thanks -
Cass

What about the support for the ARB vertex weighting and matrix palette skinning extensions?

I don’t see them in my extensions string on my GF4.

-Mezz

Originally posted by Mezz:
What about the support for the ARB vertex weighting and matrix palette skinning extensions?

NVIDIA has never supported these in any driver, if I’m not mistaken.

Right - we never supported those extensions.

Yeah I figured they weren’t supported, I just wondered why. I suppose you can do everything in the vertex programs can’t you?

-Mezz

Originally posted by Mezz:
I suppose you can do everything in the vertex programs can’t you?

Yes, you can. Therefore these extensions are obsolete IMHO (just like many other fixed-function extensions). I’m all for cleaning up the extension mess.

I’m all for cleaning up the extension mess, but then there is the issue (as has been previously mentioned) that you need to keep legacy extensions used by applications.
But yeah, true - there isn’t much life in the FF pipeline any more.

-Mezz

Originally posted by Mezz:
[b]I’m all for cleaning up the extension mess, but then there is the issue (as has been previously mentioned) that you need to keep legacy extensions used by applications.
But yeah, true - there isn’t much life in the FF pipeline any more.

-Mezz[/b]

I haven’t look deeply into that, but it will probably very easy to implement most(all?) OGL1.X extensions using ogl2.0. So I don’t think backward compatibility is a problem.

How about the multitexture extension? I suppose it will be moved into the SDK…

I wouldn’t mind seeing extensions go. It seems sort of messy anyway. vp are definatly the way to go.

Originally posted by WhatEver:
How about the multitexture extension? I suppose it will be moved into the SDK…

Which extension do you mean? ARB_multitexture has been part of core OpenGL since 1.2.1.

I wasn’t aware of that .

Looks like they’re all one step ahead of me .

Ok. Some questions for you VP guys…

  1. I need to use clip planes with my mirrors. How do I use vertex weights in VP combined with clip planes…

  2. I want to use positional lights, fog, texgen etc. all those stuff in the FF pipeline + weights. What kind of VP do I need to generate the equal effects.

  3. is there a way to just replace the vertex.position but still use the FF color, fog etc…

It sounds like you should do sw skinning (in object space) and use the fixed function for T&L.

Cass. Based on you comment I can only draw the conclusion that the removal of EXT weight extension is not mature. You can not solve the above requirement with VP (yet).

At least I know 1. doesn’t work. Perhaps someone has solved 2. but explain this VP to a beginner and then explain why you should remove the EXT weight extension ???

1: I didn’t think clip planes were a per-vertex thing. I thought that was something that happened at the pixel level.

2: Then write them in a vertex program. It turns off all per-vertex fixed-functions, so you will have to write it yourself.

3: No.

but explain this VP to a beginner and then explain why you should remove the EXT weight extension ???

Because EXT_vertex_weight is almost utterly useless, perhaps? It can’t be used for any real skinning because you can only apply 2 matrices to each triangle, not vertex. Because it lacks the palette of the vertex_blend one, it requires lots of matrix state changes, thus, as Cass pointed out, slowing things down more than a software solution.

You’re probably going to have to learn vertex programs sooner or later, so you may as well start now.

You can quite easily emulate user clip planes with a sheared projection matrix. You need to shear it so that the near clip plane become your clip plane. Of course this works fine with vertex programs.

Kuba

Originally posted by cass:

The reason for potentially dropping support for EXT_vertex_weighting is that there is a “not insignificant” burden in driver
<…>
Cass

Isn’t it a better to stay backward compatible, even if it’s rarely used. If you start removing extensions here and there, a whole lot of people will get upset.

At least until 2.0 drivers come up.

PS: we are approaching 2003. Any idea when 2.0 drivers will be released. Been a hell of a long time since it’s anouncement you know.

V-man