I’d like to know, why wide lines supoort has been deprecated.
See this post:
So wide lines will stay on nVidia as a core extension. But this also means, we can’t rely on them to be supported by ATI and others. In fact this seem to be the reason why they are deprecated now.
In my opinion, wide lines are a very important feature. Almost all CAD apps make use of them. What are the alternatives?
CatDog
I’m doing some wide lines with a fairly simple GS and IMO they beat the canned alternatives out of the box 9 ways to Sunday.
Can’t speak to the situation with professional grade cards, but dollars/deutsche marks for doughnuts my lines are just as phat 
Oh, Deutsche Mark is deprecated also. 
Do your wide lines handle AA correctly? And what does “fairly simple” mean?
edit
Wait, I remember something… you mean these?
CatDog
How efficient is the GS method as compared to NVIDIA’s line smoothing (with FSAA disabled)?
Why don’t you guys get off your duffs and give it a go yourselves?
Lacking DX10 hardware. 
CatDog
Because then I’d have to implement the method. But since you’ve already implemented it, it’d be simpler for you to test.
But really, this does kind of suck. Having to use the GS for this means it’ll be hard to mix the GS line smoothing with the GS emitting lines of its own; one would probably have to emit actual lines in a separate pass and store the results using transform feedback.
Actually I haven’t done any perf comparisons, just after maximum quality at this point. Not exactly a solution with overwhelmingly broad appeal at this point, just looking down the road a bit. By golly it does look good though… really ought to try it if you can. If I can put some code together that’s not too unpleasant to look at I’ll post it later (it’s a real stink bomb right now).
Don’t know if it’s OK to post a quake map publicly without permission. If not quickly I’ll tear it down.
Plenty of room for optimization and various doodads…
do you feel empowered as a developer?
having to implement your own line drawing code again after all these years, I mean.
Thanks modus, that looks really good! I’ll enjoy playing around with it as soon as I’ve upgraded my hardware.
But now the question to the ARB is: is this what you had in mind?! I mean, drawing a line is something like “Hello world” for newbies. Do you really need to write your own geometry shader to do this?
CatDog
Thanks, modus! I will check this out.
Much of the “Graphics Library” part of OpenGL is deprecated in 3.0.
Everybody gets to implement their own lines and matrix stacks now.
And points too… for the discerning minimalist in all of us.
For points, the point sprite extension is now core. Chapter E1: Point rasterization is always performed as though POINT SPRITE were enabled.
That’s a good solution. But if I got it right, there is no such thing for wide lines. You have to construct them by yourself. Chapter E1: LineWidth is not deprecated, but values greater than 1.0 will generate an INVALID VALUE error;
This looks a little bit half-baked.
CatDog
I always hated point-sprites, IMO they are useless, because of their various limitations. It should have simply been something that constructs billboards on the GPU, but instead it has this weird behaviour, that is mostly useless.
Yeah, keeping glLineWidth but forbidding values > 1 is a strange solution. It only shows once more, what we are supposed to expect from the ARB.
Jan.
(I’m with you on the point-sprites, Jan.)
Half-baked is the perfect way to describe this situation… skinny lines and fat points… the Laurel and Hardy of graphics primitive assemblages…
… However, since GL3 requires GL3 (formerly DX10) hardware, it does seem natural to abandon hardwired functionality like this in favor of more flexible and generic methods going forward (as has been the trend). No doubt we’ll see a (community driven) utility library emerge alongside GL, besides, something fairly standard I would hope… or if nothing else maybe some template-like, drop-in snippets in the interim, to bridge some of the FFP gaps introduced with new shader stages and outgoing functionality.
Point sprites are not sufficient to implement AA points (if you consider the subpixel alignment case.)
So everybody gets to roll their own points, too.
I’ll go out on a limb and wager that the point-sprite business will be deprecated in the next version, leaving us with basic line and point rendering (size=1), roll your own for everything else. That’d be at least a bootstrap out of the box to get things going…
You’re right. Dropping point sprites (which I found useful despite their limitations) would be much more consistent.
I wonder whether the ARB has thought of something standardized to fill those gaps.
CatDog