flexible attachments and hardware lighting in 1.9.1?

Um, I care about NOT having to mindlessly download a new ~20MB client every day!

So don't check back daily? It's the preview grid, lots of changes are expected. That's how development works, gradual changes and fixes. o.O;

shiny transparent

Well, conforming OpenGL implementations have to support at *least* 8 lights, not 'up to', and on any non-ancient card those will be in hardware. You may get more - it's up to the implementation - but not less.

But the old fixed-function OpenGL pipeline isn't something that gets a lot of love any more: things are seriously going shaderwise. If the developers wants to write their own vertex program to do the lighting, it's hellaciously easy to get a lot more than 8 lights processed all-in-hardware, even on an old GeForce2.

Right. It's usually bad form to rely on the fixed function pipeline (i.e. OpenGL without shaders) beyond the minimum. In fact, I can't think of a single card off hand that supports more than 8 hardware lights, but I'll admit I stopped checking once GeForce FX cards hit the market.

As for using shaders on older cards, it's usually better to use the fixed function instead of a shader on anything GeForce 4 or older because of temporary register and instruction count limits. GeForce 4 was probably the hay-day of the fixed function, and the shader processing on that generation was still quite new, so you're likely to see better framerates on those cards without using vertex shaders.

On newer cards, however, the emphasis is clearly on shaders. The problem now becomes one of getting the lighting parameters to the shader and keeping the operations done per vertex to a minimum. In many cases, flow control is not available, so if your shader supports up to 16 lights, you always have to process all 16 lights, even if 15 of them are turned off. With multiple passes, readbacks, etc. you can achieve any number of lights, but such techniques tend to kill your framerate. GeForce 4 has a hard time getting just the 8 lights implemented in a shader in a single pass with specular, ambient, and diffuse components used per light. I don't want to think about GeForce 2.

At the moment, 1.9.1 does not contain support for vertex shaders on GeForce 4 for three main reasons: 1) The card does not support GLSL pixel shaders and separate shaders would have to be written and integrated into the viewer, 2) Doing said work would take away from optimizing for FX class hardware and later, and 3) There are a lot more residents with FX class hardware than with GeForce 4 class hardware.

Don't feel bad if you're one of the residents who still has a GeForce 4. The fixed function implementation of hardware lighting is quite good, and if you had the option to turn on vertex shaders, you probably wouldn't use it due to the performance hit of using shaders on those cards.

In other words, like Las Vegas, what happens in preview stays in preview.

You're missing the point, Feynt (and I tire of having to reiterate it).

Was that a hint?

No?

How about a blatant revelation?

Right - I wasn't suggesting that a vertex program would be faster than the fixed-function pipeline, I was saying that it's a way to bust the 8 light barrier in hardware. The fixed-function pipelines in modern drivers frankly still rock as long as your requirements fall within their parameters.


One can switch between a few specialized vertex programs depending on the number of affecting lights (state-sorted). (This may be what you meant by multiple passes, rather than additive lighting passes.)


Ambient isn't a per-light attribute and SL doesn't care about specular (unless this is a new local lighting feature... yum?).


I agree with all you're saying, although I thought that SL already leveraged Cg and Cg would do an 'adequate' vertex program job on a GF4 card. After some early fiddling around I don't use Cg myself any more, so I'm out of touch with its portability.

*drools tea from his mouth*

IF I can have shiny windows, you will all be tiny gods.

?

<--- Obviously not clever enough to get the reference.

I will buy this hair immediately as long as he/she is alive . And a decent hardware upgrade with it, so that at least I see it...

Tron. Bit, saying "Yes"

glLightfv accepts GL_AMBIENT in the pname parameter, and the GL does indeed store ambient values per light, it's just that no one really does much with it. I like the effect of applying ambient in the opposite direction of the light vector, and yes, SL cares about specular for a few lights on shiny objects (including the transparent ones, and avatar eyeballs), and everything gets a little bit of a shine off of the sun. See previous statement about temporary register limits as for why not all lights contribute to specular.

As for Cg, it works very well for the most part, but it has a few bugs around the edges of the spec, particularly when dealing with accessing built-in uniform state. Since NVIDIA doesn't seem interested in fixing these bugs in any sort of timely fashion, but they are dedicated to supporting GLSL, Cg has been removed from SL. Also, there is no Cg for intel mac, and I'm not interested in trying to convince the linux community to adopt it. In any case, GeForce 4 supports GLSL vertex shaders, so we'll probably get around to doing legacy support eventually, but it's not a priority right now.

*ears perk* You just said that to get my attention didn't you? XD

Lets hope there is a release in the future that supports not only the forementioned prims, but toruses as well. that would just be dandy

Alas, llSetForce() doesn't have any effect on the floppiness of prims. You can change the strength of gravity but it's still vertical. Oh well.

OK, when I say "there should always be an alpha or beta grid up", that means every update should go through beta before release. Even if it's "1.9.0(23)", it should go onto the preview grid before it hits the server.... even if it's only there Monday and Tuesday before the Wednesday update... and then it should stay there until the next beta's ready so people can test there.