Slashdot Mirror
The State of OpenGL
CowboyRobot writes "No longer vapor, but a true 3D-embedded engine, OpenGL is on the move. Pixar and others would love to be able to render their movies in realtime, and that desire has prompted the intended release of OpenGL 2.0, due in a few months. Khronos is now in charge of further extending OpenGL to cellphones and handheld gaming devices."
For so long, DirectX had to struggle and claw to keep up with OpenGL - they did just that, while OpenGL sat mainly idle (well, John Carmack was a big help to it)... Now it seems the shoe is on the other foot, and OpenGL is going to have to move deftly to surpass DX9, and soon enough 10...
I sincerely hope it happens. I wish developers felt more inclinded to make their 3D engined GL based rather than DX based, so the day where I can play any game in linux may actually arrive. Of course, we have to give massive amounts of respect to those who do make OpenGL platforms for their games (ID, Epic), but what about those who feel DX is easier and more practical for what they do(Valve).
Maybe if we're lucky, the Carmack will drop in to this discussion and tell us exactly what he thinks needs to happen to really make GL a reality for most gamaes again.
no sh*t. imagine the battery drain from using a processor that can use openGL. who needs that crap. I'm all for openGL as a 3d standard, but cellphones don't need 3d. cellphones don't need games. Am i going to be ranting about cellphone batteries not lasting an hour, like i am with laptop batteries, in a year?
again, vote with your wallet.
OpenGL is used in the Torque engine alongside Direct3D (D3D on Windows, OpenGL on Mac and Linux). It would be great if OpenGL could eclipse Direct3D, and become the premiere 3D platform once again. Perhaps we will see this with the release of OpenGL 2.0, but for a few years Direct3D has been slowly but surely catching up and then surpassing the aging OpenGL standard.
A lot of our customers demand Linux in their solutions (networked gaming terminals) to avoid the cost of licensing Windows XP Embedded for each machine, and the option so far has been to go the Mesa/OpenGL/SDL route (WineX is still too slow for what we do), which, while it has worked, is technically slightly inferior to our Windows equivalents. Hopefully OpenGL 2.0 will change this.
When the article talks about rendering in real-time it isn't talking about the compressed/flattened video playing a full frame rate, it's talking about OpenGL being able to calculate/shade/render a model in realtime verses waiting X mins/hours for a frame to render. It's talking about the process of converting vector data to raster data.
The guitars sound good, now give me about 10db more on the cow bell.
My cousin's husband works for Sun and he said that the next version (1.5?) of Java will have Swing ported to OpenGL underpinnings... that way, even 2D apps will be MUCH faster.
He said they're realizing 4X speed increases on plain old 2D apps.
They're also working on making 3D game demos (some with 3rd parties) to demo that Java can actually now compete in the desktop game market...
---- It puts the lotion on its skin or else it gets the hose again. It does this whenever it's told.
Unless I'm missing something in your post.
Nope. He's just another tech wiseass who prizes seeming smart over being accurate.
Hey freaks: now you're ju
No longer vapor, but a true 3D-embedded engine...
Since when has OpenGL been vapor?
Which could be your target as a glowing orb, or a character in of a video game super-imposed on the actual landscape, or the trail your friend took through the same city two years ago, or just some construct representing an interesting thing about your environment, or ...
I think that would be a real killer app.
The article says that the programmable features will be based the direct-compile model in which the compiler will be included as part of the driver.
:-(
Given the current less than good state of open source drivers for graphics chips this may well mean that most of the useful (i.e. works with your hardware) compilers may only be available in the Linux world as part of tainted binary drivers. It seems pretty likely that vendors who believe that their current drivers contain deep secrets than open source would reveal to their competition will be even more convinced of deep secrets of their compiler technology.
Not good news
Give me examples of what you're missing in OpenGL 1.5 that you get in D3D or how D3D is optimized more than OpenGL.
Don't say something like programmable graphics? OpenGL introduced fragment programs to take advantage of PS2.0 hardware (Radeon 9500+, GeForceFX+) before MS released DirectX 9.
Just because OpenGL started with a great base and has evolved up to version 1.5 doesn't mean it is worse than another API which is at version 9...
Troll?
The complaint made about Java3D, and why Java-OpenGL bindings like JOGL or GL4Java even *exist*, is that Java3D is too *high* level. It's a scenegraph API, not a low-level graphics API. Is OpenGL ES a similar thing? I had presumed that if it's aimed for the embedded market, ES would be pretty low level. Thus how in the world can ES be considered "higher level" than Java3D?
Hey, that's no worse than many open source project that are GCC friendly.... But it's a fucking bitch to try and use any other compiler, because the dumb fucks have used GCC-specific code, and ignored the C and C++ standards. Linux is one such example.
The key here is: 'something that can be used real time.', it's not a PRman implimentation, it is merely a front end to give the artist some visual feedback as to the prman shader on the object. It renders and changes a UV baked raster image of the shader.
As for the Final Fantasy thing. I saw that at siggraph running on SMP PS2's. It's 'alright', but it didn't look a whole lot like the film, it looked like an OGL render of the film.
What you aren't understanding are the fundamental differences between scan line renderers, ray trace renderers, and real-time technology. Real-time can only 'fake' ray tracing, and it's not very accurate or good. Like I said, we are a long way off.
And don't jump up and down, some people have real-time SSS, radiosity, and raytrace demos, but they are very crude, and a long way off.
And sure, you can tweak a movie scene down to get it to look good and run on a next gen card when presented on a vid online or TV, but we're talking about film.
> I guess he based that on the fact that the transition from Half-Life to Unreal Tournament was a transition from OpenGL to D3D.
Yes, but did that transition occur because D3D was better, in terms of technology and economics?
Or was there, perhaps, an outside influence tipping the economic scale...
Microsoft eyeing Vivendi unit?
Has Microsoft bought Vivendi Games?
Microsoft / Vivendi rumours gather steam
I don't know if the purchase actually took place, but they were talking, and Vivendi was deeply in debt, and Microsoft had lots of monopoly-generated cash. I think it's safe to assume that some sort of payoff occurred.
It is also widely believed that when Microsoft joined the OpenGL committee, it was for the purpose of sabotaging, and slowing down the technology.
That last bit is easy to believe, because it's the normal way that Microsoft operates. For example, consider these tidbits from the DOJ case Findings of Fact:
Microsoft's Jim Allchin, in a note to Gates:
> "I am positive that we must do a direct attack on Sun (and probably Oracle).... Between ourselves and our partners, we can certainly hurt their (certainly Sun's) revenue base.... We need to get Intel to help us."
Microsoft's Eric Engstrom describes Microsoft's goal as:
> "Intel to stop helping Sun create Java Multimedia APIs, especially ones that run well (ie native implementations) on Windows."
And Engstrom's proposed agreement with Intel:
> Microsoft would incorporate into the Windows API set any multimedia interfaces that Intel agreed to NOT help Sun incorporate into the Java class libraries. [emphasis/caps added]
So there you have a clear example of Microsoft using threats to sabotage open multimedia support.
If we want the PC to remain open (let alone the Internet), then we have to support technologies that don't come from Microsoft. In this case, it means supporting OpenGL, which is not hard to do, because it's a great technology.
This is exactly what i was thinking while reading all of this.
I'm a 3d Character Animator, and TD myself and found it interesting that no one really had brought any insight to this. I'm glad you did. Its all PR bullshit. The truth is... Pixar, or any other film quality 3d rendered artwork requires a lot more processing than any current gen realtime shading language can supply.
Not only things like fur, which you had mentioned... General image quality issues, complex shaders, raytracing, etc.
Whats MORE true.. and quite a posibility is that realtime cards may aid in rendering things like ambient occlusion passes and so forth. Nvidia seems to be demo'ing a bit of this right now. Hell if i could generate an ambient occlusion render pass off a quadro based card, or even better an FX card... excellent.
But its simply not reasonable to expect film quality renders anytime soon. Renderers like Mental Ray can use your Open GL supported accelerator to generate shadow maps and such... but really the complex shaders, and extremely accurate quality that is required just cant be done realtime. But we may get to the point soon where somethings can be handed off to the accelerator card.
But it wont be real time. That you can bet your donkey on. The polycount and texture map data require far more ram than any hardware accelerator has.
The sheer size of scenes (ram required), shader complexity/diversity, image quality issues, and of course your general advancements in techniques and new ideas... simply make depending on a 3d accelerator not realistic.
But like i said.. It may be possible to render a nice Ambient occlusion pass on these 3d cards... and that in itself is very welcomed.
because the dumb fucks have used GCC-specific code, and ignored the C and C++ standards. Linux is one such example
Actually the linux source is pretty good about using gcc extensions only when necessary -- i.e., because the standard is lacking, not because they're "dumbfucks".
For instance, gcc's extended "asm" syntax (parameter passing, constraints) is extremely important for the sort of low-level code a kernel needs sometimes [and, no, moving all assembly code into separate files is not an adequate replacement -- it would result in both much worse performance (because the compiler couldn't optimize around it), and increased maintenance burden].
In cases where the standard has caught up with gcc, linux has moved to using the standard syntax (e.g., recent big changes like replacing gcc-specific structure field initialization syntax with the equivalent C99 syntax).
We live, as we dream -- alone....