PDA

View Full Version : PerPixelLighting using NV_vertex_program & NV_register_combiners

inept
11-16-2002, 07:17 AM
I'm stuck.
I've got diffuse working, but specular is giving me a real headache.

My main question is this:
Is the H vector (half angle) mentioned in various documents calculated in this way:-
H=normalise(vertextolightvec + vertextoviewpointvec)
???
If it is, then I will have some more questions, because it's not working for me.

Thanks.

Nutty
11-16-2002, 07:36 AM
IIRC

half angle = (L + E) / 2.

Where L is normalized surface to light, and E is normalized surface to eye.

You then dot this with the normal, and raise to the power of something. 16 for example. If you dont raise to the power, then you wont get very specular looking specular. i.e. it'll be rather non shiny.

Nutty

inept
11-16-2002, 08:14 AM
Thanks Nutty - just as I thought.
Anything wrong with this register combiner nvparse script? :::

!!RC1.0
const0 = (0.5, 0.5, 0.5, 0);

// INPUTS OF INTEREST:
// col0 = interpolated pixel-to-light vector (compressed into unsigned RGB)
// col1 = interpolated half angle vector (compressed into unsigned RGB)
// tex0 = decal texture
// tex1 = normal map texture (bump map) (compressed into unsigned RGB)

//////////////////////////////////////////////////////
// Normalise col0 and col1
{
rgb
{
spare0 = expand(col0) . expand(col0);
spare1 = expand(col1) . expand(col1);
}
}
{
rgb
{
spare0 = sum();
}
}
{
rgb
{
spare1 = sum();
}
}
////////////////////////////////////////////////////

// dot L and H with normal map
{
rgb
{
spare0 = spare0 . expand(tex1);
spare1 = spare1 . expand(tex1);
}
}

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

final_product = spare1 * spare1;
out.rgb = const0 * final_product + spare0;
out.a = unsigned_invert(zero);

inept
11-16-2002, 09:08 AM
Ah, no matter. I've just discovered a fundemental flaw in the way the modelview matrix was being constructed from the viewpoint object in the application itself - what I thought was the absolute position of the viewpoint, turned out to be some mad weird position. It was written by one of our junior programmers...little sh*t. http://www.opengl.org/discussion_boards/ubb/wink.gif He's gonna get some earache on monday, you can be damned sure!

Nutty
11-16-2002, 12:49 PM
Glad you seem to have found the problem.

Never used nvparse scripts, and I dont intend to either.

Nutty

inept
11-16-2002, 01:28 PM
Yes, they do seem a bit redundant, considering the vastly limited options you've got with register combiners. It's actually easier to use the function calls than it is to write the scripts, because so many combinations of ops are illegal that you might as well stick to the stage input/output function calls. The texture shader nvparse scripts are laughable...just a tiny selection of pedantically named, parameterless function calls.
But that contradicts my pixel shader script methodology - pixel shaders in my renderer are defined by scripts, there's no point me changing it just for the geforce1/2 path.

davepermen
11-17-2002, 06:16 AM
i don't see any problems in nvparse here, it's much more readable than the function calls, and the biggest faults that can happen in the function calls are wrong mappings and all that because of copypasting (come on, dudes, who actually writes out all the parameters by hand? http://www.opengl.org/discussion_boards/ubb/biggrin.gif) and with such a script such bugs are much less dangerous and much more easy to find.

the only problem with nvparse is.. uhm.. nvparse.. getting it to work, with the crappy fancy dlls and all that. dunno.. i got it one time working, and that was it.. http://www.opengl.org/discussion_boards/ubb/biggrin.gif

anyways, /me moves over to ARB_vertex_program and ARB_fragment_program, hehe http://www.opengl.org/discussion_boards/ubb/biggrin.gif

inept
11-17-2002, 06:43 AM
But arb_vertex_program and (especially) arb_fragment_program aren't widely supported, are they? (to put it mildly).

jwatte
11-17-2002, 01:24 PM
He's gonna get some earache on monday, you can be damned sure!

I'd give the ear-ache to the guy reviewing his check-in, instead. Or perhaps the guy writing the unit test, unless that's the same guy as wrote the code.

Or, if all three are yourselves, I suggest a pub round. The morning after will teach you :-)

davepermen
11-17-2002, 11:26 PM
Originally posted by inept:
But arb_vertex_program and (especially) arb_fragment_program aren't widely supported, are they? (to put it mildly).

arb_vertex_program runs in hw on gf3, gf4, radeon8500, radeon9700, radeon9500, radeon9000 (damn there are much numbers out yet http://www.opengl.org/discussion_boards/ubb/biggrin.gif), and of course on the nv30..

arb_fragment_program only runs for now on the radeon9700, yes.. and it will on the nv30.

no one needs to use nv_vertex_program anymore, it's just for backwards compatibility.. or does it have any feature arb_vertex_program doesn't have? i don't know of any. but arb_vertex_programs run on my pc as well.

if i ever would have gotten nvparse to run simple by including #include "nvparse.h", then i would have never moved back.. the scripting languages primitive? yes, and? it's still easier to edit http://www.opengl.org/discussion_boards/ubb/biggrin.gif and much more easy to read and error check espencially..

MichaelK
11-18-2002, 01:39 AM
Originally posted by davepermen:
arb_vertex_program runs in hw on gf3, gf4, radeon8500, radeon9700, radeon9500, radeon9000 (damn there are much numbers out yet http://www.opengl.org/discussion_boards/ubb/biggrin.gif), and of course on the nv30..

And are there any platforms, where ARB runs in software (like NV on gforce2)?

Edit: Excepth of course NV30.

[This message has been edited by MichaelK (edited 11-18-2002).]

inept
11-18-2002, 01:48 AM
Well, no it isn't much easier to read than the api calls, in my opinion. As I said, register combiners are just a way of mapping inputs to outputs through selecting which (out of a very narrow choice) maths operation you want it to perform on those inputs. The nvparse scripts seem to give users the idea that they can use something as simple as the + symbol to add two input registers together, when really they can't. So code like this (below) looks incredibly confusing:-

rgb{
spare = sum();
}

rgb{
spare0 = spare1 * spare0;
}

Does that look readable to you? Being able to use the * operator, but not the +?
Someone new will look at that code and think, mmm...why are sums expressed differently than products? And then, bam! - they are then hit by the limitations of register combiners, so why express their operations as a language?
(I only do it to keep it consistant with everything else).

BTW, I'm using nv_vertex_program and register_combiners because I haven't the time to read through the arb_vertex_program spec....it's just too damn huge, and there simply isn't the same volume of examples/tutorials on them as there are for NV ones. I also believe that the nv_vertex_program emulation on gf2< will be much faster than anything I can do in my own code, while keeping the interfaces in my own code cleaner.

knackered
11-18-2002, 04:43 AM
I agree that the functions are easier to understand than the nvparse programs. But the main advantage to the nvparse programs is that you can change/compile them again and again at runtime. I wrote myself a parser for the actual function calls themselves (glCombinerInputNV... etc. actually in a text file), so I could change them at runtime, and this has worked very well for my applications. It is also a pain in the arse that you need to use nvidia's own opengl sdk to link to nvparse - but that can actually be sorted out by commenting out all the nvidia init_extention calls in the nvparse source code - it will then link to your own entry points when you statically link it. Just be sure they've been correctly initialised at your end!

davepermen
11-18-2002, 06:27 AM
Originally posted by MichaelK:
And are there any platforms, where ARB runs in software (like NV on gforce2)?

sure, runs on all nvidia hw at least in software, as far as i know. not sure about the radeons older than 8500.. anyone with an old radeon can check if the new drivers expose ARB_vertex_program?..

but on all more or less new hw, gf1+,radeon8500+,pathelia,p10, you get it, eighter hw or software. the rest, i don't know..

but hey, every driver wich can do dx8 vertexshaders can do ARB_vertex_program as well..

does mesa yet have it? dunno..

but there is _NO_ need to use NV_vertex_program anymore. it was just there because no standard was there yet. now, drop it.

for pixelshading thats another topic.. if you want to be compliant for all hw of the current generation, use ARB_texture_env_XXX extensions only, like _dot3 and others..

if you want to support modern hw, nv30, >radeon9000 (9500 and 9700 for now), use ARB_fragment_program..

and, i hope soon, we get ARB_float_something, and ARB_fragment_program_multitarget or something like that.. we'll see..

davepermen
11-18-2002, 06:32 AM
Originally posted by inept:
Well, no it isn't much easier to read than the api calls, in my opinion. As I said, register combiners are just a way of mapping inputs to outputs through selecting which (out of a very narrow choice) maths operation you want it to perform on those inputs. The nvparse scripts seem to give users the idea that they can use something as simple as the + symbol to add two input registers together, when really they can't. So code like this (below) looks incredibly confusing:-

rgb{
spare = sum();
}

rgb{
spare0 = spare1 * spare0;
}

Does that look readable to you? Being able to use the * operator, but not the +?
Someone new will look at that code and think, mmm...why are sums expressed differently than products? And then, bam! - they are then hit by the limitations of register combiners, so why express their operations as a language?
(I only do it to keep it consistant with everything else).

BTW, I'm using nv_vertex_program and register_combiners because I haven't the time to read through the arb_vertex_program spec....it's just too damn huge, and there simply isn't the same volume of examples/tutorials on them as there are for NV ones. I also believe that the nv_vertex_program emulation on gf2< will be much faster than anything I can do in my own code, while keeping the interfaces in my own code cleaner.

you got me wrong. it's not a scriptlanguage, nothing against cg or something like that. but once you know registercombiners, you can set them up much faster and more easy with the nvparse language for them (and runtime change them even, hehe.. who ever needs that)..

and yes, it's more readable than 5 nearly fullscreen lines of GL_XX_NV capslockconstants..

but you have to know register combiners. they are never easy.. but typing all that functioncalls is just.. hm.. do you set them up that way? dunno, but once i wanted to do perpixellighting with smooth selfshadowing, specular with glossmap and exponentmap, all on the gf2 in one pass, hehe. and power16 for the specular as max.. so i had to do a lot of cheating, of course.. that was simplest on a paper with some math formulae. then i rewrote it so that it fit into the combiners. you really think it's more easy with the functions then? i had no nvparse then yet to use, so i had to use functions.. and it took quite some time..

btw, for all the dudes that think register combiner setup with functions is readable, i just want to let you one time read the nvidia demo wich does high precision shadow mapping (16bit) on <gf3 hw..

now tell me those screens over screens of different combiner settings are readable http://www.opengl.org/discussion_boards/ubb/biggrin.gif

and the rest is just training..

11-19-2002, 12:52 AM
There certainly is a good reason to use NV_vertex_program, at least in the world of real shipping software: plenty (likely millions!) of end users probably have drivers old enough that ARB_vertex_program isn't supported. A second reason might be that it is a very, very close match to DX8, and so converting DX8->NV_vp or NV_vp->DX8 is pretty darn easy.

Excluding that, though, I'd probably stick to ARB_vertex_program, though I'd stay away from some of its features.

Of course, NV_fragment_program and NV_vertex_program2 are another story entirely. Both are very substantial supersets of what the ARB extensions can do.

- Matt

knackered
11-19-2002, 12:56 AM
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?

Nutty
11-19-2002, 01:20 AM
Which features of ARB_vertex_program should we stay away from Matt, and why?

I dont suppose you can probably answer that tho.. IF not a little confidential email would be nice. Would be nice to know about any problems this spec has on certain hardware.

Thanks,
Nutty

davepermen
11-19-2002, 01:22 AM
There certainly is a good reason to use NV_vertex_program, at least in the world of real shipping software: plenty (likely millions!) of end users probably have drivers old enough that ARB_vertex_program isn't supported. A second reason might be that it is a very, very close match to DX8, and so converting DX8->NV_vp or NV_vp->DX8 is pretty darn easy.

Excluding that, though, I'd probably stick to ARB_vertex_program, though I'd stay away from some of its features.

Of course, NV_fragment_program and NV_vertex_program2 are another story entirely. Both are very substantial supersets of what the ARB extensions can do.

- Matt

how about simply providing proper minimum drivers with your software? most games i know ship for example dx with, why not drivers for the known supporting gpu's?

and in realworld, there is not only nvidia, matt. so please don't try to get people using your proprietary extensions in situations the arb provides a just as good tool for most situations. and mapping to arb_vertex_program from dx vertexshaders is just as easy.

the arb_vertex_program is superior in usage as well.

and nvidia should finally provide a fragment_program profile for cg. as they want cg to be a real standart, its their job to get it working on real platforms..

i know at least that my code runs on your platforms as well. can you tell this from your "realworld apps using nvidia proprietarity?"

Julien Cayzac
11-19-2002, 02:50 AM
Originally posted by davepermen:
sure, runs on all nvidia hw at least in software, as far as i know.

Don't forget do put a "on Windows" at the end of such statements: it will prevent me to rush on the Linux drivers page at nvidia.com :'( http://www.opengl.org/discussion_boards/ubb/biggrin.gif

Julien.

vincoof
11-19-2002, 04:11 AM
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.

davepermen
11-19-2002, 04:27 AM
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.

vincoof
11-19-2002, 05:51 AM
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 http://www.opengl.org/discussion_boards/ubb/smile.gif

davepermen
11-19-2002, 06:01 AM
>>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 http://www.opengl.org/discussion_boards/ubb/biggrin.gif
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.

vincoof
11-19-2002, 06:29 AM
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.

davepermen
11-19-2002, 08:00 AM
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.

vincoof
11-19-2002, 08:11 AM
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.

davepermen
11-19-2002, 08:38 AM
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..

vincoof
11-19-2002, 11:37 AM
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 http://www.opengl.org/discussion_boards/ubb/biggrin.gif

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 http://www.opengl.org/discussion_boards/ubb/wink.gif) 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.

inept
11-19-2002, 11:50 AM
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! http://www.opengl.org/discussion_boards/ubb/wink.gif Please let this drop off the end of the list and be forgotten - while I still have my pride.

Humus
11-19-2002, 12:51 PM
Pride? With a nick like that http://www.opengl.org/discussion_boards/ubb/eek.gif

vincoof
11-19-2002, 01:11 PM
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

inept
11-20-2002, 01:11 AM
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).

# R4 = normalize3(R3) = normalise the V vector
DP3 R4.w, R3, R3; # R4.w = R3.x*R3.x + R3.y*R3.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
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.

It's very verbose, because I'm hoping some of the juniors can learn from it (nothing like a fool teaching a fool) http://www.opengl.org/discussion_boards/ubb/smile.gif

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).]

Asgard
11-20-2002, 01:37 AM
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."

davepermen
11-20-2002, 02:31 AM
normalize R5 before sending over.. that should help.. dunno..

inept
11-20-2002, 03:56 AM
Originally posted by Asgard:
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."

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.

vincoof
11-20-2002, 04:46 AM
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.

inept
11-20-2002, 04:56 AM
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.

inept
11-20-2002, 05:32 AM
Ok, I've uploaded an image to somewhere called 'yahoo'.

Hope this helps clarify the problem.

davepermen
11-20-2002, 05:42 AM
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 http://www.opengl.org/discussion_boards/ubb/biggrin.gif)

inept
11-20-2002, 05:47 AM
You beautiful, beautiful person!
Thank you very, very, very much!!!!!!
Looks lovely now. Jesus, what an idiot I am.

inept
11-20-2002, 07:05 AM
Ok, thanks to david, I have some nice per-pixel lighting with bump mapping.
You can peruse some images, and look at the vertex_program & register_combiner code here, if you've got too much time on your hands:- http://www.geocities.com/pixelshaderman/

(yes, I know I have some texture mirroring problems with tangent space)

inept
11-21-2002, 12:46 PM
Hello again. I've got another problem.
I've uploaded another image, showing the problem - it's the top image in grey scale... http://www.geocities.com/pixelshaderman/

Can anyone suggest to me why the facets are so obvious?
This is how I calculate the tangents (same goes for binormals):-

for (every vertex)
set each vertex's tangent vector to zero

for (every triangle)
calculate surface tangent
add this surface tangent to each of the 3 vertices tangent vector

for (every vertex)
normalise tangent vector

This should give me a tangent vector for every vertex which is the average of all the triangles that share that vertex.

I generate all 3 tangent space axis this way (normal/tangent/binormal)

Am I doing something wrong?

vincoof
11-22-2002, 03:57 AM
I don't get right what you mean by :
for (every triangle)
calculate surface tangent
add this surface tangent to each of the 3 vertices tangent vector

my questions :
1- how do you "calculate surface tangent" ? There is a generic way for calculating normals (ie cross product) but what algorithm do you use for tangents ?
2- do you sahre your vertices in the whole 3D model ? or does each triangle have 3 vertices independently to its neighbourhood ?

inept
11-22-2002, 05:56 AM
Well, I use the standard way of calculating the tangent space vectors. I calculate the tangent vector from the 1st vertex in the triangle to the other 2 vertices, then add this 'surface' vector to the current vector contained in each vertices tangent.

Yes, all the vertices are shared.

vincoof
11-22-2002, 06:18 AM
1- but there is an infinite number of solutions. Which criteria do you use to get *the* tangent ?

2- if vertices are shared, then you should NOT see the facets, unless shading is flat. Did you call glShadeModel(GL_FLAT) or glShadeModel(GL_SMOOTH) ?

davepermen
11-22-2002, 08:24 AM
vincoof, the tangent in the same direction as the s-coordinate of the texture coords of the bumpmap..

vincoof
11-22-2002, 09:56 AM
ok, s for tangent and t (or -t) for the binormal. It will work fine with the square assumption which is almost perfect for the torus and not so good with the teapot. Anyway, I don't think that's where the problem is.

davepermen
11-22-2002, 10:00 AM
nope.. i think your tangentspace is okay.. how you calculate the to-light and to-eye vector?

inept
11-23-2002, 12:58 AM
The register_combiner and vertex_program code is on that web page I linked to (at the bottom). This shows how I calculate the vertex-to-light vector and halfangle vector.
Bizarre - I thought this would just click with someone who's had the same problem. Maybe I need to look further back into my engine for the problem.

11-23-2002, 09:11 PM
Among the things I don't like about ARB_vertex_program:
- XPD instruction.
- Attribute aliasing not required.
- Constant and attrib register file #-of-ports limitations not enforced.
- Somewhat excessive queriability of certain things.
- Insufficient precision/special case behavior guarantees.

Which is not to say that NV_vertex_program is perfect; there are also things that are better in ARB_vertex_program. (For example, on the last item, about precision/special case guarantees, I'd say ARB_v_p guarantees far too little, while NV_v_p guarantees far too much.)

You know, you guys crack me up. I actually thought about adding a comment that my arguments were equally valid for EXT_vertex_shader, that is, that since there are drivers that support EXT_vertex_shader but not ARB_vertex_program, you should actually have your app support all three of NV_v_p, ARB_v_p, and EXT_v_s. It's probably a lot easier and cheaper to support all three than to take tech support calls from people who don't understand what a "driver" is, much less what "ARB_vertex_program" is.

If I was writing an OpenGL game today, I'd probably make sure to support all three.

In fact, you could even take the argument further and say that for a game whose release date is not a long ways into the future, you'd be better off supporting NV_v_p and EXT_v_s and *not* ARB_v_p, just to reduce testing burden.

Geez... what I get for not having time to look at this board in a while.

- Matt

vincoof
11-24-2002, 09:38 PM
inept: I'm sorry if I'm repeating myself, but your problem really looks like you called glShadeModel(GL_FLAT) instead of glShadeModel(GL_SMOOTH). Did you call one of these ?

inept
11-24-2002, 10:55 PM