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."
SUCK IT DOWN!
d00t!~d00t!~d00t!~d00t!~d00t!~d00t!~ FP!~
Pixar and others would love to be able to render their movies in realtime,
Ummmm......Pixlet.
Visit Jonesblog and say hello.
Once again, Microsoft rules. They really are the most innovative and resilient software companies in the world.
Get Your Graphics On: OpenGL Advances with the Times
.NET Framework. In contrast, the OpenGL Architectural Review Board won't be a one-stop shop in charge of building support for OpenGL ES into any of the popular IDEs (integrated development environments). Rather, such support will come in multiple plug-ins from third parties, such as the vendors offe
ACM Queue vol. 2, no. 1 - March 2004
by Alexander Wolfe, Science Writer
Because so much compute power is required, render farms usually run offline.
The Old Graphics API
OpenGL, the decade-old mother of all graphics application programming interfaces (APIs), is getting two significant updates to bring it into the 21st century.
Accurately billed by its supporters as the premier environment for developing portable, interactive 2D and 3D graphics applications, OpenGL comes equipped with a broad set of rendering, texture mapping, special effects, and visualization functions.1 Faced with increased competition on the desktop from Microsoft's DirectX and D3D offerings, however, OpenGL is getting a bit long in the tooth.
Accordingly, the OpenGL Architecture Review Board (the independent consortium chartered in 1992 to guide the future of the API, which was originally developed and is still owned by Silicon Graphics2) has pushed ahead on the desktop and workstation front to provide a programmable implementation dubbed the OpenGL Shading Language.
Meanwhile, a spin-off organization called Khronos3 has been formed to extend the OpenGL brand into the emerging world of downsized devices such as cellphones and handheld gaming devices. There, it's taking the form of a new API called OpenGL ES, for "embedded systems."
HANDHELD ACTIVITY SPURS NEW SPEC
The recent Consumer Electronics Show (CES), held this past January in Las Vegas, constituted the public coming-out party for Khronos. The OpenGL ES 1.0 spec itself was actually disclosed in July 2003 at Siggraph in San Diego.4 But CES saw the release of the first products to execute apps taking advantage of the spec, thus moving it from vapor status to a real, 3D-embedded engine.
Initially, ES support is coming in the form of software engines. Texas Instruments5 and Symbian6 have developed the 3D Graphics Library plug-in based on OpenGL ES 1.0 for Symbian OS-based mobile phones equipped with TI's OMAP digital signal processors. In addition, Fathammer has integrated OpenGL ES into its X-Forge game software development kit (SDK),7 which is used to develop apps for Nokia's N-Gage handheld wireless game unit.8
In keeping with its embedded design goal, these ES engineers are keeping a tight footprint--on the order of 100 kilobytes resident on the target platform.
Such software will be followed later this year by faster, dedicated integrated circuits and cores (the latter being intellectual property ready to be transformed into working silicon) now under development at ATI, NeoMagic, Takumi, and 3Dlabs itself.
OpenGL ES's proponents see it moving rapidly into a vacuum in the embedded space. To date, Java-compliant 3D graphics have come in the form of the Java 3D API. Many developers, however, believe Java 3D is at too low a level. An initial indication that ES may see service in the Java arena comes via the news that Sun Microsystems and Silicon Graphics plan to cooperate in developing bindings from the mobile J2ME runtime environment9 into OpenGL ES.
For its part, Microsoft is developing a competitive offering in the form of D3D Mobile. That API is an embedded version of DirectX; however, it's expected that D3D Mobile will be very closely tied to Microsoft's embedded operating system offerings such as Windows CE and Smartphone. As such, it could be a good while before it migrates to Java-based devices of Symbian cellphones.
If this seems like a swipe at Microsoft, consider at the same time that Redmond may be in a better position when it comes to tools support. Microsoft can easily fold D3D support into Visual Studio and the
Yay, I get to play around with 2x2 pixel rendered characters on the cell now.
... it can do its own shadows! Innovation!
When will they figure it out OpenGL is not necessarily desirable in a cellular phone?
I want business class reliability, not a the ability to rent subpar games on my cell phone for $5/month.
When I'm on the phone all day because of my work I want it to be there for important calls, not fizzle out after an hour because it's got a 640x480 pixel screen with 24-bit color.
Although right now OpenGL is all that's out there for low-cost portable embedded 3D software, no one is going to develop with it until hardware support emerges. Who wants a handheld 3D mapping device that takes 10 seconds to redraw a frame using an ARM9 software renderer?
microsoft must love him (uh-huh) for making all his games (quake-s, doom-s) and the subsequent engines based on OpenGL; they must really love him because those engines are the mona-lisas of computer science, best.engines.ever.;
:)
ps, OpenGL [2] >= DirectX [9]; embarrasing, every f*cking year a new version, then you have to buy a new video card, a f*cking joke.
GO OGL!
What about the ability to stick to-do notes on the BACK of your cellphone? Wouldn't that make mobile 3D worthwhile?!
Don't call me a cowboy, and don't tell me to slow down!
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.
"Touch one hair on her head and I'll render you limb from limb!"
SWEET!! Just think of the possiblities!
Programmability Comes into Vogue While 2004 marks the infancy of good 3D graphics on compute-constrained handhelds, it will also see the move to programmability on desktops, which as a category finally has enough graphics-engine heft to merit such a transition. "In the last 18 months there's been a lot of activity on the desktop side toward making the [graphics] hardware programmable,"10 explains Neil Trevett, who has expertise in desktop graphics as a senior vice president at chip maker 3Dlabs, and also is a key contributor on the embedded side as chairman of the OpenGL ES working group. "A graphics chip is increasingly becoming like a CPU: It's multithreaded, it has virtual memory, it has intertask security, and it's programmable in a C-like language. The only difference is that graphics ICs are very parallel (as opposed to the main microprocessor), which is required so they can execute graphics more efficiently." Enter the OpenGL Shading Language, also known as OpenGL 2.0 (see figure 1).11 Due to hit the streets in a few months, the release will bring high-level shading programmability to OpenGL. It will expose a very C-like API and provide software developers with access to a wealth of graphics operations. Standard OpenGL offers a fixed set of functionality. This limitation has been forced by the fact that lots of compute power is required just to get polygons up on the screen. Now that graphics boards and ICs are powerful enough to off-load 3D processing from the main microprocessor (aka Pentium), however, OpenGL 2.0 is able to let programmers do things more flexibly without fear of bogging down the computer. Accordingly, 2.0 will provide programmable alternatives to some of the fixed functions currently available. For example, programmers will have the ability to explicitly get into the nuts and bolts of things like vertex processing and fragment processing. This will allow them to revamp things according to their own needs or to tune performance for specific hardware configurations. OpenGL 2.0 implements what's called a direct-compile model--that is, 2.0-compliant drivers will ship with built-in compilers. This means that a given graphics hardware/driver combination will take its OpenGL source code and compile it directly into machine code that runs on the graphics hardware. (The compilers themselves will be supplied by the individual graphics chip vendors.) "Over the next year or two, I think you're going to see a whole range of applications that use your graphics board as a supercomputer,"12 Trevett says enthusiastically. Realtime Rendering on the Horizon The turn toward programmability comes at a time when professional graphics developers are poised to make major advances. Consider that, currently, animated films are produced using large render farms--huge collections of workstations that crunch polygons to create a movie's individual frames. Because so much compute power is required, render farms usually run offline, taking a day's work and turning it into frames overnight so it's ready when the animators return in the morning. Recently, says Trevett, there's been interest from the photorealistic community in using newfound graphics programmability for doing movies such as "Toy Story" (2001) in realtime. "That's the dream everyone is going for,"13 he says. The goal is to take industrial-strength software--like the Renderman package that "Toy Story" producer Pixar uses--and accelerate it on graphics chips via programmability. The result would be that far fewer workstations would be needed to render a movie, and the cost-per-frame of rendering would come down significantly. Longer term, Trevett doesn't think that graphics software will stand still. "We haven't reached a stable state yet, either in the algorithms or the hardware," he says. "I think in 20 years we'll look back and be amazed at how primitive things were. The software community is still doing tremendously innovative work. This speaks to the fundamental market driver behind 3D graphics."14 Most immediately, software developers can access
Hopefully, this will prompt more developers to join efforts to create a feature rich gaming framework for *nix. SDL is a great start, but lags behind DirectX in a number of ways. I look forward to seeing this 2.0 release breathe new life/blood into this area of development.
Thank you for your time,
BBH
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.
benef17s of being
I'm going to learn opengl in a few months during the holidays before I start my PhD. I work with simulations of the Sun and use IDL to visualise the results. but I think it would be cool to have more "realistic" pictures, plus having the hardware acceleration has benefits when dealing with a lot of data (IDL gets real slow for 2D simulations at resolutions above a few hundred squared)
these simulations are done on beowulf clusters (imagine that!) so I think opengl is the best (the only other API I know of being directx)
OpenGL 2.0 is not as exciting as the new major version number might indicate. Probably the most important new feature of OpenGL 2.0 was going to be the GLSL high level shader language. However, in order to speed up its support by hardware companies, this was instead put into OpenGL 1.5 spec when it was announced last year; GLSL already has implementations by 3DLabs, ATi and nVidia. OpenGL 2.0 will still add some useful new features, but it won't be the world-shattering event that 3DLabs promised in their original proposals.
Jan 16th 2002: SGI transfers 3D graphics patents to MS
Jul 09th 2002: Microsoft Claims IP Rights on Portions of OpenGL
Jul 11th 2002: 3D graphics world shaken by patent claims
Jul 13th 2002: Microsoft patent claims may affect OpenGL
Mar 3rd 2003: Microsoft quits OpenGL board
The current handheld devices are not suitable for 2D/3D graphics, because their memory bandwidth is so poor that texturemapping will make the software crawl. I'd get excited when the mobile devices get real 3D hardware acceleration. Even a 400MHz XScale doesn't cut the mustard if it spends its time waiting for the memory. Have been using OpenGL ES for over six months now...
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.
in the story. Next time read it before you post an article. Doh!
First post!
Most frames in Pixar movies are rendered using some form of ray-tracing. While it is possible to use vertex and fragment shaders in uncoventional ways to do ray tracing, this is *not* what the OpenGL pipeline is designed for. Great for games, but ray-tracing will still be done using render farms (and not in real time).
OpenGL has been languishing for years. It's about freaking time they gave the spec a nice big update. I'm a mac guy, but I have to admit that DirectX has a much better level of optimization than OpenGL does. Hopefully this new spec will make it's way into Mac OS 10.4 and give Macs a much needed boost in the graphics arena.
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.
For one, direct3d is integrated into the direct api which handles a multitude of things, multimedia and game input devices among others, that game developers are almost naturally drawn to by the appeal that so much work has already been done for them
OpenGL can't and really shouldn't have to address all these requirements, but it's just part of why there's been this ongoing struggle. SDL is a reasonable answer to portability while still accomplishing the integration that MS has achieved, but SDL isn't really as mainstream as OpenGL is.
I've seen soap opera plots that were less convoluted than this mess.
File under 'M' for 'Manic ranting'
I admit that the idea of playing crippled games on a cell phone isn't attractive.
On the other hand, the user interface on small embedded devices could be improved. I suspect that decent graphics could be part of the solution.
The current user interface is sort of comparable to where computers were in 1980. For instance, my wife's cell phone has quite powerful features and she uses them skillfully. I, on the other hand, have only managed to answer incoming calls.
I also agree that a skillful operator doesn't need a fancy user interface. I spend most of my working time on the command line unless I'm doing graphics. I do things (find a five year old file in a tarball, for instance) on a regular basis that my wife and daughter might want to do once a month or once a year. If I get stuck, I dredge through man pages. When they get stuck, they get rescued by context sensitive help. My point is that, for most users, an unfriendly interface stops them cold and a friendlier interface lets them muddle through.
I don't know exactly what form the interface will take. I like the idea of a palm top device that totally takes the place of a secretary. Totally voice activated and able to deal with ambiguity.
"Computer"
"Yes sir"
"Dial my mother-in-law"
"She's not speaking to you. I suggest that you let me order her some roses."
etc.
I really love it when shills post things like this. Can we please see some documented facts to back any of this up?
Innovative? They didn't do jack with 3D until OpenGL came along and showed them how. They had to buy it from SGI. This has been documented.
Resilient? Dictionary.com defines this as "Marked by the ability to recover readily, as from misfortune." This is actually true, as they were behind, and had to play catch-up. 10 years later, they have caught up with (and arguably surpassed) a technology that has changed very little. Until now.
If this is what defines one who "rules," I'd rather that MSFT "rules" while other companies and organizations just make better stuff.
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
The original article post seems to confuse different forms of OpenGL. OpenGL|ES is the embeded stripped down OpenGL for mobile & embeded systems. OpenGL 2.0 is just a proposal from 3DLabs and may never get off the drawing board. Most of the significant changes that OpenGL 2.0 introduced have been implemented and released either as extensions or as part of OpenGL 1.5, so it's just not clear if or when OpenGL 2.0 will actually arrive, there's a lot of resistance because 2.0 intended to throw some stuff out and many developing, selling & using OpenGL implementations think that it's a REALLY bad idea to do that. With OpenGL|ES there is already a version 1.0 and you can actually get this in several forms from implementations that run on phones to wrappers around OpenGL that you can use on the desktop to emulate OpenGL|ES. OpenGL|ES is in the process of developing version 1.1 right now.
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
In markets where Microsoft is truly inferior, they dominate. What chance has OpenGL in the games market where DirectX is actually superior?
How come the kronos.org site doesn't have any links to the opengl embedded source. The have all this market speak about how it's 'free and cross-platform' and 'here is the api' blah blah, blah; but when it comes down to it THERE ISN'T a single link to any source.
I know you can apt-get opengl libraries, but do these guys have a closed source fork? Doesn't anyone know the relationship between kronos and opengl?
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?
2004 will see the first handheld devices using the same 3D technology that powered the Dreamcast gaming console.
Of course nVidia and ATI and others are also going to release 3d for mobile phones.
In the last video game generation people were shocked at the unbeliveable power the consoles had. The n64 featured an advanced 64bit 100MHz MIPS RS4?00 chip with SGI level 3d graphics designed by SGI for $200. Only a few years before that a slower 32bit 33Mhz MIPS 3000 chip with worse graphics would've cost many thousands of dollars. Just wait a couple years and we'll have $20 watches with gigs of memory to replace our iPods and more power than the xbox ;)
As TD who works in the computer graphics field, let me state that the technology required to render a Pixar film in 'Real Time' is far off and ridiculous. Just because OpenGL looks better does not mean that it can support the shader functions that Renderman utilizes, not to mention the Fur and cloth APIs. Also, the majority of shots in movies aren't even single comp shots they involve many rendered elements, which you still have to comp together. I'd be all for the guy talking about how OpenGL 2.0 will benefit the artists by allowing them to get more feedback about the quality of the shot they're working on without preview renders, but thinking that OGL could replace final renders any time soon is wrong. Perhaps we are geting to a place where we could render the original Toy Story realtime and a general viewing audience might not know the difference. Perhaps. But I remember some really great PRman shaders from the film that wouldn't be posible in the real time version.
In a just a couple generations Pixar will use render farms of GPUs on the PCI Express bus and the CPU won't matter. In a couple years high end video games will look just as good to the eyes of many people as movies like Shrek.
OpenGL was dying.
I guess he based that on the fact that the transition from Half-Life to Unreal Tournament was a transition from OpenGL to D3D. Whatever. DirectX can bite me. OpenGL has fucking PIXAR working on it.
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.
wow, is myopic the new buzzword for slashdot posts? I've been spotting it frequently.
Slashdot: news for opticians. stuff that matters.
"Over the next year or two, I think you're going to see a whole range of applications that use your graphics board as a supercomputer," Trevett says enthusiastically.
was the most interesting part of the article?
SETI@home, Finite Element Analysis, video recoding are all areas which could benefit from vector processing , matrix calculation and/or huge register sizes provided by GPUs.
Boy was that post short-sighted and self-focused.
> 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.
If/when linux makes more significant inroads into the desktop market, then games will follow. These games will require OpenGL ...
Linux gamers do not need native Linux games or OpenGL based games. The majority of Linux gamers play Win32 games via dual booting or emulation. It is far more likely that emulation via WineX will continue to improve and become a very robust and reliable way to run Win32 games. Native Linux games will not be needed from a developers perspective. Keep in mind that getting a Linux gamer to buy a Linux version rather than a Win32 version does nothing for the developer. The only money to be made is from Linux gamers who refuse to dual boot or emulate and that is not enough to financially justify a full native and supported Linux version.
The good thing is that it is Nvidia, who do the best OpenGL implementations around.
that people forgot about 3Dfx Glide? :)
I use to be indecisive, but now I'm not so sure.
Errrr... oh, I get it! You'd be searching for stuff? (-:
Got time? Spend some of it coding or testing
...the hey-you-forgot-the-batteries jokes.
Got time? Spend some of it coding or testing
Java isn't the only way to abstract either your graphics interface or endianness. There are much more efficient ways of doing both. If I was using an abstract language for my cellphone, I'd prefer something like Ruby.
Amongst other benefits, including much faster coding/debugging and better reusability, Sun's newfound cameraderie with Microsoft would then pose no risk to the future of my mobile 'phone code. Sun want to both have their cake and eat it, which is not a sustainable model of reality. Microsoft's view is much simpler: they want your piece of the cake, now, or they'll bury you in lobbyists and lawyers. It suits them to leave Scott's delusions intact.
Ruby, I might add, integrates with Java and you can even compile Ruby to Java bytecode if you like. This gives you a choice of JRE or native target. Ooh, let me think, which language would I rather use?
Got time? Spend some of it coding or testing
...it'll just be ordering it for you. And because it uses DRM, there will be no plausible deniability for you.
Got time? Spend some of it coding or testing