PerPixelLighting using NV_vertex_program & NV_register_combiners

Originally posted by knackered:
arb_vertex_program is only supported in the beta drivers, as far as I know…or is there a new release version that I don’t know about?

NVIDIA drivers v40.72 are not beta anymore because they’ve been labeled WHQL last week.

btw, this forum is not the best place to start a war. thanks in advance.

its a discussion board, so we can discuss in here. matt stated arb_vp is not as good as nv_vp, so he now has to bring in valid points on why. the drivers issue is not a point, as people have to update drivers anyways, to solve bugs, to have new features, to have more speed. this was never different.
the aliasing is different, but once you know it, it’s not a problem actually. stick to the names or generic indexed attributes, don’t mix (stupid anyways).
then it’s possible that it does not fit into the hardware constraints of a gf3/gf4 or any other gpu because of lack of instructions/constants/what ever. you can check that actually, and query that all if you need to be sure its processed fully in hw.
what else, matt? i still don’t see a point.
one big point for arb_vp: it runs on your gpu’s, on my vpu as well, no modern gpu will not support it. it’s the standard. while not needed in gl1.4, it will be needed for gl1.5 by a big chance.
explain why arb_vp is worse than nv_vp. except for trying to get people on the nvidia-only line, wich a lot of nvidia marketings try. here we are in a real forum, marketing and hyping does not count. bring in facts.

Originally posted by davepermen:
matt stated arb_vp is not as good as nv_vp

I’m sorry but that’s not what I understood from his post.
He seems to prefer ARB_vertex_program but assumes that he dislikes one or two features whitin. Note that he never mentioned those “bad” features came from ATI ot whatever.

Originally posted by davepermen:
one big point for arb_vp: it runs on your gpu’s, on my vpu as well, no modern gpu will not support it.

Right for modern gpu’s, but thinking of older gpu’s you have much chance that drivers support NV_vertex_program on NVIDIA cards, because (like Matt said) not everybody updates their driver. For the sake of backward compatibility, it’s always a good thing to support old extensions when you’re not sure new extensions are available. Moreover, I’ve never heard that NVIDIA would support ARB_vertex_program for all their cards. Does anyone know if it will be the case ?

As a last comment, please note that MESA actually supports NV_vertex_program but not ARB_vertex_program (yet). That is, today ANYONE can use NV_vertex_program assuming they’re using MESA software renderer

>>There certainly is a good reason to use NV_vertex_program, at least in the world of real shipping software<<

that is just stupid. sorry.

updating drivers is easy, buying an nvidia gpu just to have a possibility to play a game isn’t. (while matt would love it that way for sure…)

backward compatibility is not a big problem. as i stated yet, most people need to update drivers to play an actual game anyways quite often, and else, they need it then. it’s quite normal, i had to do it on the gf2 as well all the time… so what?

multiple vendors compatibility IS a big problem. NV_vp runs on gf1,2,3,4,5, and pathelia (and mesa). ARB_vp runs on gf1,2,3,4,5 with newest drivers, will be in soon on pathelia (or is yet, dunno), and is in the next release of mesa. it is as well on the radeon8500, and bigger, 9000,9500,9700. it will be by a big chance on older radeons as well.
it is newer => not yet that supported. but it’s standart. and, now the major point. it WILL be supported for ever. well, as long as ever can be
do you think any future radeon will support NV_vp? do you think any future matrox will? any future 3dlabs? anything else? no. if you then relie on your game on nv_vp, you will be as lost as you are today trying to get glide working… NV_vp is proprietary, while currently quite a bit around spread, it should not be used anymore for any future projects. and even matt knows that. and its annoying to see he does not state that, mostly “refering to real world situation”. real world is not nvidia only. it’s nearly perverse to say NV_vp is bether then.

matt, i fully disagree on your position.

and what do you dislike in arb_vp? the aliasing? or that you can have named variables? makes cg less sweet, doesn’t it? arb_vp code is actually quite readable thanks to the variables and direct access to stuff like light[0].data etc…

still, i would use cg, if nvidia could release some standard compliant ARB_fp profile finally.

I’m not sure we’re talking about the same purpose.
I don’t want to use NV_vp exclusively. I prefer ARB_vp by far, but if your application can use both ARB_vp and NV_vp, then try to use them both ! For ppl that have a NVIDIA card with old drivers, NV_vp will be used ; for ppl that have an ATI card, ARB_vp will be used ; and for ppl that updated their NVIDIA driver, choose yourself which extension to use (I recommend ARB_vp obviously).

I really would like to get rid of NV_vp, but as long as a customer’s configuration have a noticeable chance to support it we should not depreceate it so soon.

IMHO, updating the driver should not be done without asking the user. And this way, we’re never sure that the user installed the drivers correctly.

as long as you support it people will not likely try to update their drivers => you will have to use it again and again. it’s no big deal to update the drivers for nearly anyone, so please drop them and provide information for them on how to get the drivers. that makes it much easier for all.

For a best-seller game like it’s not a problem to ask this to the customers. But for a “little” game, it can be a constraint that players won’t necessarily agree. Just imagine how many players don’t have an Internet connection for instance ! Unless you provide the drivers on the game CDROM, it’s really a hard constraint to ask customers to get newest drivers from the web.

well, most small games start sharing over the web… and there, uhm, driver updates are no big problem…

btw, when i take my old gf2mx, and use the drivers wich where in with the packet, i can nearly not run any modern game anyways, be it big or small. it’s eighter buggy, too slow or some extension is missing. think about that again. most people who want to play your game have yet played other games, never games as well. most of them need driver updates to get those games running.

i KNOW there are people without descent drivers and without internet connection. but as i would use internet to advert your game mainly (it’s by far the cheapest way), you will not find them anyways. once you get big enough for moving into magazines and such, beeing on a magacine-cd or so, it’s not a problem, they provide the drivers. bether try that way so users can always play your game…

and while you do backward compatiblity for old nvidia cards, do you code GL_ATI_vertex_shader fallback as well? i don’t think you do…

bether do a full software version (software vertex processing) and an ARB_ version if you want to provide it for all people, it’ll be faster anyways, and even older radeons or rages or matroxes or whatevercards can play it.

your so sweet ment support is very onesided, only lazy nvidia card users get a fallback, what about the others?
oh, and NV_vertex_program is not in the standard drivers of a gf2,gf1… dunno about the gf3…

Originally posted by davepermen:
well, most small games start sharing over the web… and there, uhm, driver updates are no big problem…

I have to agree with the point that if you or I is going to advertise the game it will be over the Web before all. And for that (kind of special) case, yes it’s easy to ask consumers to get drivers.

Originally posted by davepermen:
and while you do backward compatiblity for old nvidia cards, do you code GL_ATI_vertex_shader fallback as well? i don’t think you do…

LOL if you knew what graphics card I have you would laugh for sure

Originally posted by davepermen:
your so sweet ment support is very onesided, only lazy nvidia card users get a fallback, what about the others?

I never meant NVIDIA only afaik. The point is, we started the topic with NV_vertex_program so we discussed with NVIDIA extensions (please read the topic title again ) but obviously what goes for NVIDIA goes for ATI too.

Originally posted by davepermen:
oh, and NV_vertex_program is not in the standard drivers of a gf2,gf1… dunno about the gf3…

not standard in the 1st gf1 and gf2 drivers, but spread a year before (or so) than ARB_vertex_program, and thus spread wider. And again, I still don’t know if gf1 or gf2 do/will ever support it.

This is quite embarassing - this thread was me unable to get simple perpixel specular working, and it’s now turned into some debate about whether or not you can expect users to update their drivers.
People are going to keep reading the first few posts and think that I am an idiot! Please let this drop off the end of the list and be forgotten - while I still have my pride.

Pride? With a nick like that

sorry about that.
And to answer clearly to the NV_vp / ARB_vp debate :
1- develop for ARB_vertex_program before all
2- if you have some free time, it’s good to develop for vendor-specific extensions too

One more thing…my specular is still bothering me.
In the register combiners, col1 is the compressed halfangle vector.
I expand, normalise, and dot col1 with the normal map.
Now, surely I should just have to keep squaring this dot product up and up to get a smaller and smaller highlight? (if it was 1, then it would stay at 1, but if it were 0.9 it would gradually get smaller each time I square it?)
My problem is that it doesn’t get smaller, it still retains the same kind of coverage as the diffuse (but just in a different direction, obviously).
It’s as if the vertex program is sending col1 in clamped at 1 for huge numbers of vertices. Why would this happen?

Here’s the section of the vertex program that calculates & transforms the half angle:

R1 = the object-space vertex-to-light vector (calculated & normalised in diffuse section)

c[10] = the object-space view position

c[9].x = 0.5

Get vertex to view vector (V).

ADD R3, c[10], -v[OPOS];

R4 = normalize3(R3) = normalise the V vector

DP3 R4.w, R3, R3; # R4.w = R3.xR3.x + R3.yR3.y + R3.z*R3.z
RSQ R4.w, R4.w; # R4.w = 1.0f/sqrt(R4.w)
MUL R4.xyz, R3, R4.w; # R4.xyz = R3.xyz * R4.w

create half angle vector H = (V+L)/2

ADD R4, R4, R1;
MUL R4, c[9].x, R4;

Transform H vector by Normal(NRML)/Tangent(TEX1)/Binormal(TEX2) orthagonal matrix to convert

it into “tangent space” (aka “texture space” aka “triangle space”)

DP3 R5.x, v[TEX2], R4;
DP3 R5.y, v[TEX1], R4;
DP3 R5.z, v[NRML], R4;

compress signed transformed & normalised tangent space half angle vector H into

unsigned output colour1 for interpolation across the triangle in the secondary

colour channel.

MAD o[COL1], R5, c[9].x, c[9].x;

It’s very verbose, because I’m hoping some of the juniors can learn from it (nothing like a fool teaching a fool)

If you could shed some light on my HUGE specular highlights, it would be much appreciated…

[This message has been edited by inept (edited 11-20-2002).]

It’s as if the vertex program is sending col1 in clamped at 1 for huge numbers of vertices. Why would this happen?

I guess that’s exactly what’s happening. Quote from the NV_v_p spec:

“The selected primary and secondary colors for each primitive are clamped to the range [0,1] and then interpolated across the assembled primitive during rasterization with at least 8-bit accuracy for each
color component.”

normalize R5 before sending over… that should help… dunno…

Originally posted by Asgard:
[b] I guess that’s exactly what’s happening. Quote from the NV_v_p spec:

“The selected primary and secondary colors for each primitive are clamped to the range [0,1] and then interpolated across the assembled primitive during rasterization with at least 8-bit accuracy for each
color component.”[/b]

Well, the colours should already be in the 0-1 range by the time they exit the vertex program - they’re normalised, then compressed into unsigned 0-1 range.
davepermen, I’ve tried normalising after transforming…doesn’t make any difference.
But other than that, nobody can see anything obviously wrong? All I need to know is whether I’m on the right track or not…you see, I haven’t seen any examples of bumpmapping where the 2 colour outputs are used for the L and H vectors…I don’t want to use a normalisation cube map…apparently it’s slower than regcombiner normalisation on a gf3.

If the vertex program works fine, your problem may belong to the fragment level. How is treated your fragment ? texture combiners ? fragment programs ?
If you could post a screenshot of your specular problem, that would be much appreciated too.

Ah, I’m using register combiners - the nvparse script I’m using is at the top of this thread. I’ve added a few more stages to the regcombiner script to raise the dot product to an even higher power, which just makes the fall-off from white to black more abrubt, but doesn’t shrink the highlight much.
The specular highlight is positioned correctly (I keep enabling/disabling the fixed pipeline, and it matches with different view/light positions, except for the size of the damn thing!).
I can’t post a screenshot as I don’t have any web space - I will try to get some tonight, so you can all look in delight (as nelson mandella would say).
It’s just a massive torus with a teapot in the middle (tea and doughnuts…lovely).
Thanks for at least trying to solve my problem.

Ok, I’ve uploaded an image to somewhere called ‘yahoo’.
Here’s the url:- http://www.geocities.com/pixelshaderman/

Hope this helps clarify the problem.

rgb{
spare0 = tex0 * spare0;
spare1 = unsigned(spare1) . unsigned(spare1);
}

spare1 = dot(spare1,spare1)? should be a *, not a ., not? else you get 3 times as big values… (more or less )