Originally posted by jwatte:
[b] [quote]
Isn’t 2-sided lighting pretty easy to emulate? Can’t you just render the object twice?
If Z testing and writing is on, and blending is off, then this is often possible. If these preconditions are not true, then it’s not equivalent.[/b][/QUOTE]Hmmmm why is that? It should be just
Set front material, cull backfaces, render
Set back material, invert normals, cull frontfaces, render
That’s assuming culling is originally off, if culling is on it’s even easier (you only need to render whatever material is not going to be culled).
Suppose you have four triangles, two facing you, and two facing away, all overlapping in screen space. If blending is on, the result of the drawing will very much result in the drawing order of those individual triangles. If you draw them all with no back culling, they will very likely hit the screen in a different order than if you first draw only the front-facing ones, and then draw only the back-facing ones.
Similarly, when Z write is on, you get the same order dependency.
If you’re prepared to constrain yourself to convex outwards-facing meshes only (possibly not closed) then the ordering will be correct if you first draw back-facing, and then front-facing. But that’s an awfully limiting restriction to put on your art.
Originally posted by Korval:
[b]Isn’t 2-sided lighting pretty easy to emulate? Can’t you just render the object twice?
And nothing says that their D3D layer made direct calls to D3D. They can take the time (depending on how much they care about a good GL implementation) to turn various GL commands into a sequence of D3D ones. And, if they’re going to make a functioning implementation at all, they still have to accept GL state that legacy D3D doesn’t support, and thus emulate it in some fashion.
Besides, since this is their GL layer, it doesn’t have to use legacy D3D. It can use D3D 9 or D3D Next (in Longhorn), since these calls, for hardware that doesn’t support it, will be converted into the proper D3D version by the D3D subsystem itself. So another system would be required to emulate things that D3D Next doesn’t support, but that’s already planned.
And some people care about performance more than a bitmap that “looks decent on any configuration”. I would love to have a, perhaps slower, nearly fully functional generic driver that I could fall back on if I’m using fairly low-end GL features. Though I really wish they’d try to adapt OpenGL versions greater than 1.2. At least provide the entrypoints for them, even if they don’t use them.[/b]
Sure, you can draw the surfaces twice to emulate 2-sided lighting and materials, but if D3DX does not handle this intrinsically (i.e., only send the data once), you can count on a significant performance hit. I’m sure that Microsoft is not worried about that aspect of their design. Longhorn has no restriction regarding legacy hardware (i.e., Longhorn will run on any graphics card). IMO, it would be a tremendous mistake if Longhorn OpenGL required a specific level of HW D3D support.
Implementing a state engine on top of D3D is fairly trivial and doesn’t require any significant changes to D3D proper since most OpenGL state settings are USER mode settings anyway. That fits in neatly with the move back to USER mode doesn’t it? Go figure.
Considering that MSFT chose OpenGL 1.2 as the baseline leads me to believe that OpenGL fragment/vertex shaders will get the short end of the stick (if any stick at all) since most of those extensions require 1.3 or 1.4. I could be mistaken, but probably not.
While interactive performance is always important, stability and reliability of the printed page (or generated image) for CAD applications is mandatory (try dragging a 10 year old workstation into a court room). If my hardcopy/archive output is dependent on a graphics driver from XYZ corporation, then my development and support effort just got that much more difficult. I can only hope that there will continue to exist a generic/software option.
Originally posted by V-man:
[b]So what does it matter that MS decided to update GL?
You should update your drivers, plus it would be better if MS supplied each vendors GL drivers on the Windows installation CD.
Besides, I have a feeling MS is bull****ting about updating openglXX.dll so dont get to excited.[/b]
Keeping drivers up to date is not the issue. For instance, if my application experiences serious graphics problems due to bugs in the driver, I can simply drop the acceleration slider in the troubleshooting tab all the way to the left and effectively disable the 3D portion of the graphics card. My application may run slow because OpenGL is running in the generic software pixelformat provided by Microsoft, but at least I can meet my deadline. However, if my BASELINE depends on 3D hardware support (and its associated driver), I will probably still have problems. Driver bugs tend to take weeks (not days) to resolve (if ever) and high-end applications get little or no support from graphics card vendors if the application is running on a consumer level card (e.g., GeForce vs Quadro).
I agree that MSFT is probably not overly concerned with making sure that Longhorn OpenGL is as reliable as it is on today’s OS’es. However OpenGL 1.2 is a much better API than 1.1 regardless of how this all falls out.
Originally posted by tranders:
[b]
My application may run slow because OpenGL is running in the generic software pixelformat provided by Micros …
I agree that MSFT is probably not overly concerned with making sure that Longhorn OpenGL is as reliable as it is on today’s OS’es. However OpenGL 1.2 is a much better API than 1.1 regardless of how this all falls out.
– tim[/QB]
So what you need is a reference rasterizer, which is something I need sometimes as well. Use Mesa, cause it’s not that bad (some bugs, but it supports 1.5 and plenty of none-core extensions).
My previous post was about not expecting much from MS. GL 1.2 was suppose to be delivered 4 years ago, with Win2000.
Then they said it was going to be released with SP1, then they said SP2, …
Instead, they released WinXP with GL beeing a D3D wrapper, and the OpenGL scrensavers (flower box, pipes, …) converted to D3D.
Why did they dedicate time for rewritting screensavers?
I think OS X is the most advanced system now, and is better than Longhorn for lot of feature, including graphics, both for realtime and deffered. It support native PostCript, really fast font rendering, and is entirelly based on an open GL window realtime compositing sub systém (all is shadowed, transparent)…
When working on OS X, all is extremlly fast and all time perfect (10 seconds to boot !).
But, Apple build the computers and is an ARB member…
If you want to be impressed by a really beautifull technology, try mac OS X on the last dual G5 processor mac (the mainbord have 2 front side bus at 1.2 Ghz !!! - 20 GBps bandwide).
So, I think that MS is trying to do something really difficult and might have lot of stability problems at the graphic level too…