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?
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).
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?
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;
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.
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.
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…