The State of OpenGL

Small Cell Screen by Anonymous Coward · 2004-04-09 03:30 · Score: 2, Funny

Yay, I get to play around with 2x2 pixel rendered characters on the cell now.

Re:Small Cell Screen by Salsaman · 2004-04-09 05:55 · Score: 4, Funny

No, you just need to buy two phones, one for the left eye, and one for the right eye, and a special new 'hands free' kit that holds the phones in front of your face.

Re:Pixlet by PurdueGraphicsMan · 2004-04-09 03:31 · Score: 4, Informative

Pixlet is for playback (a codec), not for rendering films. Unless I'm missing something in your post.

--

The guitars sound good, now give me about 10db more on the cow bell.

Re:OpenGL is Dead by b0r0din · 2004-04-09 03:36 · Score: 5, Funny

I thought we told you not to come back here after that Monkey Boy Dance incident, Steve.

Damn them by Anonymous Coward · 2004-04-09 03:36 · Score: 5, Insightful

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.

Re:Damn them by happyfrogcow · 2004-04-09 03:44 · Score: 2, Interesting

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.
Re:Damn them by HeghmoH · 2004-04-09 04:12 · Score: 2, Insightful

So buy a phone with a black-and-white screen and long battery life. Nothing's stopping you.

--
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
Re:Damn them by Azghoul · 2004-04-09 04:15 · Score: 4, Insightful

Hmm, funny, I don't remember you being declared the only person to own a cell phone.

How about realizing that there are other users out there? How about realizing that teenagers ( a gigantic market, by any measure ) might WANT their phones to play games?

Be a little more myopic next time, AC...
Re:Damn them by sbaker · 2004-04-09 04:17 · Score: 5, Insightful

If there *is* going to be 3D on cellphones and PDA's then I'd much prefer that they ran a standard API than a non-standard one. Given that there really are only two 3D standards, I'd much rather it was OpenGL than Direct3D.

So - *IF* we want 3D then we want OpenGL.

But do we want 3D in cellphones?

The supposed 'killer app' for 3D on cellphones is the idea of using the positioning detecting capability of the phone - along with network access - to provide an annotated 3D map of your present location. Think of the navigation systems in cars - but in 3D - so you can find the elevator you need to get to a particular office in a big unfamiliar building - or find where you left your car in an multistory parking lot.

Games will obviously use the technology too.

I don't know whether this is important to people or not - but if 3D is happening, it should CERTAINLY be in OpenGL - initially a small subset - gradually improving to a full-blown implementation in every phone as the technology catches up.

Personally, I'd be much happier with a last-generation basic phone that had 10x battery life and didn't lose service quite so easily.

--
www.sjbaker.org
Re:Damn them by stienman · 2004-04-09 04:32 · Score: 4, Insightful

1) You are not their target audience.

2) Eventually cell phones, pdas, computers, entertainment devices (tivo,etc) will converge into one or two devices, one of which will be portable. This is one item on the continuum leading towards the ubiquitous always on computing device.

3) OpenGL on the cell phone is simply a way of saying, "OpenGL on any platform requiring 3d graphics." It's marketting. It may not be used heavily on cell phones, but perhaps new a new HDTV format will allow for an opengl data stream to place products in pretaped shows for different areas (ie, midwest viewers see a CVS pharmacy, while southeast see an Eckard). Having a pared down implementation meant for little processors and low resolution screens is an asset. Don't abuse the implementation if the idea can be generalized.

-Adam
Re:Damn them by Puff+Daddy · 2004-04-09 05:15 · Score: 2, Insightful

Parents who want their kids to have a useful device instead of a glorified leash might want to get them a "glorified gameboy phone."

Next time my car breaks down and I have to call for help I'll remember how stupid my parents were for getting me a phone instead of a pager.
Re:Damn them by Decaff · 2004-04-10 06:20 · Score: 2, Insightful

Ah! Usual /. anti-Java dogma.

As virtually all new phones come with Java built-in, its kind of moronic not to use it.

Of course, if you prefer wasting your time hard-coding OpenGL calls and re-compiling for each make of phone, that is up to you, but as a business model its suicide.

OpenGL ES with hardware support? by Stiletto · 2004-04-09 03:37 · Score: 4, Insightful

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?

Re:OpenGL ES with hardware support? by LousyPhreak · 2004-04-09 03:45 · Score: 2, Informative

exactly thats the point of opengl es.

as it is only a subset of the opengl standard trimmed for low power/low speed devices it is (or will be) also fast in software. afaik there are also hardware renderers for opengl es in the works.

and remember:
we hat 3d games long before the gigahertz pcs with 3d accelerators were out and they were a tiny bit faster than 1 frame/second.

--
-- Karma: beyond good and evil - mostly affected by posting political
Re:OpenGL ES with hardware support? by arbitrary+nickname · 2004-04-09 04:01 · Score: 4, Insightful

It's *not* really designed for software implementations. This is a common misconception. Relies on depth buffers for sorting - which can be wasteful on memory bandwidth for software implementations (there are better alternatives in many cases (BSP trees, portals, bucket sorting)

After having a look at the spec, OpenGL ES seems -1, Redundant. Why not just aim for full OpenGL, starting with a 'MiniGL/QuakeGL' style implementation, of the sort which really got the ball rolling on the PC.

However, I believe it does include fixed-point maths support - very useful for all the ARM-based devices out there with no FPU.
Re:OpenGL ES with hardware support? by Mithrandir · 2004-04-09 05:50 · Score: 2, Informative

The simplistic reason for this is that the full OGL spec, or even the "miniGL" drivers are still waaay to complex for what is needed on these devices. Things like multitexturing, and anything that requires readback from the state is especially costly. The point was that on these devices they dont want full OGL support. If they did, they wouldn't have even bothered starting this spec. It is to provide a spec that has a greatly reduced footprint (memory, API coverage, etc) that allowed first class 3D graphics on smaller devices. If you want full OGL support, you do full OGL, not a partial implementation. There is no point "working upwards to full OGL" because they are never going to get there with this spec. Once a device wants to head towards desktop OGL support, then they bite the bullet and implement the complete API.

It was also determined that most of that sort of functionality was not needed. Other things like 1D and 3D textures, attribute stacks, display list etc are just non existant. On the other end, there are things that never existed in OpenGL, such as the fixed point maths support, along with defined accuracy measures etc.

In the beginning, OGL-ES had two primary targets - small footprint mobile devices, and safety critical markets (ie avionics displays etc). In the former, they needed basic functionality, but enough to do things like overlays and texturing. In the latter, they needed a very small API footprint that can be verified IAW with various authorising bodies (eg FAA for avionics, NIH for medical devices etc). In both cases, a miniGL driver was just not good enough because miniGL still assumes the full OpenGL spec and only for one particular application. Both groups required a formalised spec that they can point to and claim "this is what we support", complete with some logo branding. miniGL still assumed a desktop based system, neither of the target groups for OGL-ES could make a lot of those assumptions (for example floating point abilities at all)

FWIW, I was a member of the ES spec development group until about 3 months ago and still am on the spec mailing lists.

--
Life is complete only for brief intervals in between toys or projects -- John Dalton

Re:OpenGL is Dead by Xeo+024 · 2004-04-09 03:39 · Score: 5, Informative

DirectX has won the war, with better features, performance, and availability.

I don't know about availability, OpenGL is cross-platform (works on OS X, Linux, Windows, etc.) while DirectX is Windows only. OpenGL is also included with many if not all graphic cards. So it's just as widely available, if not more, than DirectX.

Sun by Brando_Calrisean · 2004-04-09 03:41 · Score: 5, Funny

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!

Re:Sun by thumperward · 2004-04-09 10:02 · Score: 2, Funny

I for one welcome our underrated Sun-trolling comedy overlords.

- Chris

I hope so by re-Verse · 2004-04-09 03:43 · Score: 4, Interesting

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.

Re:I hope so by westlake · 2004-04-09 04:05 · Score: 2, Interesting

Carmack can still build an engine. But his game designs are frozen in the 'nineties. Which is likely to prove the stronger seller and have more impact on developers, Half-Life 2 or Doom 3?
Re:I hope so by ScrewMaster · 2004-04-09 05:26 · Score: 2, Insightful

They've all missed the point. Duke 3D was impressive because you could BREAK THINGS. The environment wasn't just there for show, you could interact with it in pleasantly destructive ways. Quake I disliked because, while it was beautiful to look at, you really couldn't do much but open doors and use elevators. I LIKED the way I could be in the middle of a network gunfight in Duke, run up to the second floor of a building, KICK out the window with my foot (with glass shards falling around me) and blaze away. After an intense battle on a dance floor, we would have shot out the mirror behind the bar, blasted all the liquor bottles into particles, and shattered vases, flowerpots and ashtrays all over the place with appropriate sound effects. That was very cool, and really enhanced the overall immersivity of the game. When it was over we would just look around at all the destruction and cheer.

Duke's overall game percentaging was very well-thought-out. The impact of various munitions was adjusted such that you didn't die too quickly, but still the relative damage levels incurred appeared realistic. And again, when a pipe bomb or a laser trip bomb went off, it would destroy any nearby breakable objects or windows, as you would expect it to do. In games like Half Life or Quake, everything around you is pretty much explosion and/or bulletproof, and that isn't particularly realistic.

Playability is the key to a game with staying power, and playability is, unfortunately, not something that has achieved much focus in recent games. It also is not intrinsically bound up with the graphic quality of the visual environment. The majority of development effort has been expended in creating gorgeous 3-D environments, not good games. A game is supposed to be entertaining, and once the "oooh!" and "ahhhh!" wears off, if the product isn't truly playable you'll find yourself not playing it no matter how pretty the pictures are. At that point you've just wasted your money.

--
The higher the technology, the sharper that two-edged sword.
Re:I hope so by KozmoStevnNaut · 2004-04-09 06:05 · Score: 2, Interesting

Yes, the Build-based games were some of the best and most fun FPS games ever.

I still think the Quake games (especially Quakeworld and Quake 3) were and still are the best deathmatch games, simply because of the almost perfect physics. Jumps just feel right, and not awkward as in Half-Life.

But as you said, the breakable scenery in Duke3D made for some pretty cool matches. I think Doom 3 and Half-Life 2 are going to be the beginning of a wave of games with plentiful breakable object, just like in Duke3D. Max Payne had good physics, and a great movie feel to it. Too bad it wasn't a multiplayer game.

That said, UT2004 makes somewhat good use of physics. It's the only game where I've been able to shoot down a plane with a car launched by a grenade :)

--
Eat the rich.
Re:I hope so by Brewdles · 2004-04-09 19:04 · Score: 2, Interesting

Often the best games running on an id engine were not made by id. It doesn't matter if Doom 3 isn't a good game itself, someone will license it because the fact is that id have experience in building and licensing engines. Isn't this really Valve's first engine, being that Half-Life was built on a modified Quake engine?

Famous misquote from the old Batman show by Pike · 2004-04-09 03:43 · Score: 4, Funny

"Touch one hair on her head and I'll render you limb from limb!"

OGL alone is not enough for gaming by BigBuckHunter · 2004-04-09 03:47 · Score: 4, Insightful

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

Re:OGL alone is not enough for gaming by System.out.println() · 2004-04-09 04:00 · Score: 2, Informative

My friend is working on a multipurpose game engine, with the ability to "plug in" different graphics managers - so you can have the beauty of DirectX 9 on your Windows version, and seamlessly switch to OpenGL when you port it to Mac OS.

Or should I say, when I port it to Mac OS, since that's my job. I wish I had the slightest idea how his engine worked... He has all sorts of complicated code that compiles fine on his x86, but is gcc-unfriendly. :-(

--
I've got more mod points and GMail invi
Re:OGL alone is not enough for gaming by fforw · 2004-04-09 04:21 · Score: 4, Funny

Your friend's project sure sounds exciting. Now there will be nine hundred and ONE incomplete, poorly-written, multipurpose game engines on Freshmeat! Praise the Lord!

.. still bitter about yours ?

--
while (!asleep()) sheep++
Re:OGL alone is not enough for gaming by Shinobi · 2004-04-09 06:00 · Score: 2, Interesting

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.
Re:OGL alone is not enough for gaming by System.out.println() · 2004-04-09 06:46 · Score: 2, Informative

Well it's designed to run any sort of game, and a number of different "plugins" (a C++ class inheriting from an abstract plugin class) allow specialization as the given genre demands. So far using this engine a lot of 2D games have been developed - a working DDR clone (albeit only with keyboard support and crummy graphics), a decent version of Asteroids (vector graphics, scrolling, camera zoom, camera rotation, minimap/radar, running at 60fps or better - Asteroids is the testbed for most of the engine's new toys), a Commander Keen-like platformer (bitmap-based graphics with camera rotation and hundreds of enemies on screen with virtually no slowdown), an ASCII shoot-em-up and a few others I can't think of off the top of my head. There's also a primitive vector-3D game (6-player Pong with 5 computers :)....) using the engine.

The core engine itself mainly contains only a few pieces that are common to most genres: graphics management (which is then passed off to a renderer of your choice), UI element handling, collision detection, and the like.

The engine also has built-in scripting and a console mode (where the game pauses and you can enter commands as if part of a script, which is very cool, and very useful for debugging - stuff like SET_X PLAYER 120... and yes the console can be disabled)

--
I've got more mod points and GMail invi
Re:OGL alone is not enough for gaming by macshit · 2004-04-09 15:18 · Score: 2, Interesting

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....

OpenGL 1.5 by PlatinumInitiate · 2004-04-09 03:47 · Score: 5, Interesting

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.

Re: OpenGL 1.5 by TypoNAM · 2004-04-09 04:19 · Score: 2, Informative

I am a licensed indie Torque owner and I have to say it is a very impressive game engine when it comes to cross platform game development. Not only does it run pretty smooth just like games such as Wolfenstein: ET and Tribes 2 (T2 was actually not really good on Linux compared to it on Windows) its source code is actually gcc friendly.

About Tribes 2, its Linux port wasn't very good and it choked from time to time for no real reason and Torque engine doesn't have this problem. The real history of Torque is that it came about right after Tribes 2 was released and GarageGames company was formed which are several former Dynamix Employees (even the founder is the founder of the company) working at GG. Torque Game Engine I have to say is far better than the old Tribes 2 engine (if you worked with Tribes 2 and then Torque you would know exactly what I mean by it).

Anyway the engine is pretty good in my opinion and as a note to those Quake lovers Torque doesn't do BSP structures for the whole map. It has a true terrain system that goes on forever and no it doesn't loop all the way around (but I've seen mods pull this off :). It uses BSP structures for what is called Interiors which are basically buildings and the GG community has been making great advances in the game engine for several years so it isn't something that will sit there and idle for months, it's always being worked on by several groups of people. So the whole game engine development is mainly driven by community resource submissions.

I guess I've talked my head off long enough and put several readers to sleep, sorry. Check out the site for yourself and maybe consider getting a license (please read the license agreement before forking over cash for it since I've seen many people ask questions about the license AFTER they bought it!)

--
This space is not for rent.

my interest fwiw by rokzy · 2004-04-09 03:51 · Score: 3, Informative

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)

Re:my interest fwiw by wass · 2004-04-09 06:18 · Score: 2, Informative

I've used IDL before, and I'd avoid doing any very intensive calculation on it (unless it was 'linkimage'd to an external C routine). Some of the specific IDL calculation routines are optimized (FFT for one), and i've FFT'd 64k arrays of floats, but that's about the limit.
Anyway, since you use IDL on a Beowulf I'm assuming they finally added multithreading. That's good, when I used it before my PhD (I'm doing condensed matter physics now, but used IDL at my research job prior to this) there was no multithreading in IDL, which was kind of annoying at the time.
IDL is good at visualization, and the interactive mode is really nice, but I would avoid using it directly for actual intensive calculations. But if you have alot of code written already, check out the external development guide, it's not that hard to link to external C programs. I did that to call low-level hardware IO routines, and run the high-level data-acquisition code from IDL w/ GUI and the niceness of IDL's display routines.

--
make world, not war
Re:my interest fwiw by Anonymous Coward · 2004-04-09 11:28 · Score: 2, Informative

Using OpenGL to visualise scientific results is, in some ways, "wrong". For visualising scientific results and such, I would recommend VTK (Visualisation Toolkit). OpenGL is just a graphics library, and visualising any results with it would usually mean transforming everything into geometric primitives before rendering - a lot of work, in other words. VTK uses OpenGL for rendering, but also contains many functions for extracting, transforming and doing calculations on the data.

The functionality of VTK is closer to IDL, and uses OpenGL as the rendering subsystem. Very interesting, and widely used...

Re:article text by Funk_dat69 · 2004-04-09 03:59 · Score: 4, Insightful

Many developers, however, believe Java 3D is at too low a level.

Say what?
You don't get much higher-level than a scenegraph API like Java3D.

I think the author may have been confused, although he did get the overall point right. OpenGL ES on J2ME will probably be the way this goes.

--
FUNK!

OpenGL 2 by woodhouse · 2004-04-09 03:59 · Score: 5, Informative

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.

Re:OpenGL 2 by woodhouse · 2004-04-09 04:55 · Score: 2, Informative

You're splitting hairs. The entire of OpenGL 1.5 is ARB extensions. There are no new "core" features in OpenGL 1.5, however cards can only be said to support OpenGL 1.5 if they support the ARB extensions.

BTW, have you actually programmed for ATi's GLSL implementation lately? It's improved a lot over the last few months, and it's very usable at this point. I can't give details due to an NDA, but expect ATi's implementation to be at 1.0 very soon.
Re:OpenGL 2 by jra101 · 2004-04-09 06:45 · Score: 2, Informative

The OpenGL Shading Language extensions (ARB_shader_objects, ARB_vertex_shader, ARB_fragment_shader, ARB_shading_language_100) are NOT part of OpenGL 1.5. An implementation can advertise OpenGL 1.5 support without any of these extensions.

They will be added to OpenGL 2.0.

--
I write code.

Re:Pixlet by PurdueGraphicsMan · 2004-04-09 04:00 · Score: 3, Interesting

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.

Re:OpenGL is Dead by Damek · 2004-04-09 04:05 · Score: 3, Funny

...Microsoft rules. They really are the most innovative and resilient software companies in the world.

So you acknowledge that they should be broken up into multiple companies? Groovy!

Re:Pixlet by Anonymous Coward · 2004-04-09 04:06 · Score: 2, Informative

-1 Factually incorrect.
You may want to look up the definition of "rendering" ("The process of creating an image (on the screen or some other medium) of a model".
Pixlet has nothing to do with rendering except as a working format for the already rendered images. The article is talking about OpenGL, a 3D API, which is suitable for rendering, not about what happens with the rendered pictures (which could be compression with pixlet).

On a related note.. by rkaa · 2004-04-09 04:17 · Score: 5, Informative

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

Wait for the OpenGL hardware by metalmario · 2004-04-09 04:21 · Score: 2, Insightful

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...

Java on top of OpenGL is happening... by tommck · 2004-04-09 04:23 · Score: 4, Interesting

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.

Re:Java on top of OpenGL is happening... by dasmegabyte · 2004-04-09 05:59 · Score: 2, Interesting

Well, C# has many things I like a lot: delegates, properties, the ability to ignore exceptions (hey, i'm lazy, and i often want exceptions thrown all the way back to the original caller without having to declare each intermediate method's throw signature) and an assembly based approach to file layouts (as opposed to one class per file, which is nice for bookkeeping but sometimes an inefficient way to code when you need a three line helper class or something). Some of those -- okay, just delegates -- are a limitation of the JVM.

Delegates, BTW, are awesome. They're about as close to functional programming as we desktop programmers are going to get!

--
Hey freaks: now you're ju
Re:Java on top of OpenGL is happening... by Mithrandir · 2004-04-09 06:01 · Score: 2, Informative

You may want to have a look at JSR-231 then, which is the official bindings of OGL in Java. If you need something more immediate, the JOGL project, which is the baseline for the JSR, should be checked out. It can be found on the java.net site.

--
Life is complete only for brief intervals in between toys or projects -- John Dalton

Re:OpenGL is Dead by Anonymous Coward · 2004-04-09 04:32 · Score: 2, Funny

you must be new around here.

It's not "OpenGL is Dead"

Teh corretc way:

"Netcraft confirms: OpenGL is Dying"

then you put something like "suXXors!!!111" on the end of it.

sheesh.

gl pipeline not for raytracing by nuttyprofessor · 2004-04-09 04:36 · Score: 2, Informative

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).

Re:gl pipeline not for raytracing by One+Louder · 2004-04-09 05:08 · Score: 4, Informative

Uh, no. Pixar movies typically use the REYES micropolygon algorithm, with some assists from raytracing for certain effects as necessary, implemented within their Photorealistic Renderman (PRMan) product.
The notion that Pixar would use OpenGL for final rendering if only it were fast enough comes up every time a new video card or GL enhancement comes along just indicates how little people understand how Pixar actually makes their films. Oddly, Pixar really doesn't make this information much of a secret, and they'll even sell you the same software they use.
Re:gl pipeline not for raytracing by kmo · 2004-04-09 05:33 · Score: 3, Informative

Most frames in Pixar movies are rendered using some form of ray-tracing.

Technically, no. Renderman (the Pixar renderer) does not perform ray tracing. It uses a scanline renderer that is much faster than any ray tracer I've ever seen. They've been at this for literally decades, and are very good at it. Still, the most complex images in their movies can take many hours -- sometimes more than a day -- to render. The time-to-render doesn't seem to improve much from picture to picture because as computers get faster, they just add complexity to the scene.
Re:gl pipeline not for raytracing by Viking+Coder · 2004-04-09 08:13 · Score: 4, Informative

Peercy and Olano (Click on "PDF" in the upper right)

Presentation

ASHLI

GPGPU

More than Moore's Law

Moore's law : still for wimps

Using programmable graphics hardware (possibly through OpenGL) for final rendering is not that far off. (Definitely not in real-time, but as a more cost-effective way to do it, anyway.) Especially with the massive parallelism of rendering, and the fact that GPUs are far outpacing CPUs in terms of their speed and transistor counts.

OpenGL is much more similar to micropolygon rendering (REYES) than it is to raytracing in the first place. The shaders are where you spend all of your time, anyway.

Heck, do you think nVIDIA bought ExLuna (Larry Gritz, author of BMRT, and former Pixar employee) just for the fun of it?

Software for translating from RenderMan Shading Language to Cg?

And what about RenderMonkey supporting RenderMan?

Do you even remember PixelFlow from Pixar? Do you see the name Marc Olano on that paper? The same Marc Olano who talks about rendering on consumer-level graphics hardware? These things have far more in common than you seem to realize.

--
Education is the silver bullet.
Re:gl pipeline not for raytracing by cr0sh · 2004-04-09 08:41 · Score: 2, Insightful

Interesting - is this REYES micropolygon algorithm in any way related to the old (late 80's?) computer graphic entitled "Road to Point Reyes" (I think that is right)?
I remember seeing an image of that in an old computer graphics "coffee table"-type book back in high school - and you mentioning that popped it in my head...

--
Reason is the Path to God - Anon
Re:gl pipeline not for raytracing by One+Louder · 2004-04-09 09:34 · Score: 2, Informative

Yes - that image was used as an example in the original paper describing the REYES algorithm.

Re:Pixlet by dasmegabyte · 2004-04-09 04:37 · Score: 2, Interesting

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

Ahem... by dustman · 2004-04-09 04:38 · Score: 4, Interesting

No longer vapor, but a true 3D-embedded engine...

Since when has OpenGL been vapor?

Can we get X-ray vision too? by cookie_cutter · 2004-04-09 04:43 · Score: 3, Interesting

Seriously, your suggestion just gave me an idea: if your 3d image enabled cell phone has centimeter resolution positioning information (not easy, I know), then you could use the screen as a "magic window" to see things that aren't physically there.

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.

To my understanding... by mark-t · 2004-04-09 04:44 · Score: 4, Insightful

Direct3d has a few advantages over OpenGL that can't really be addressed by OpenGL.

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'

Re:To my understanding... by omicronish · 2004-04-09 05:10 · Score: 4, Informative

From coding experience the integration is pretty much non-existent or not very strong. APIs such as Direct3D and DirectSound have consistent API styles, but they don't share much API. It is possible to write an OpenGL application that uses DirectSound and DirectInput, like GLQuake.
Re:To my understanding... by WilyCoder · 2004-04-09 05:56 · Score: 2, Insightful

Who says you can't write the graphics engine in OpenGL, and all the other modules(music,netcode,etc) with DirectX ???
Re:To my understanding... by hawkstone · 2004-04-09 08:16 · Score: 2, Informative

> 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.

SDL and OpenGL are not mutually exclusive. I have very successfully used SDL to handle joystick input, window creation, and sound output, with OpenGL for 3D. SDL in fact is designed to work this way, since SDL will create OpenGL rendering contexts for you when you create windows, and it handles the fullscreen video modes far easier than any other method of creating OpenGL contexts that I have used.

And just for comparison: I ported a DirectX/3D game from windows to SDL/OpenGL on Linux, and cut out about 1000 lines of code in the process because the DirectX API is so ugly. (I realize that might imply DirectX is more powerful, and I also realize my abhorrence of the MS DX API may be simply personal preference, and to boot, this was a DX5 program, so the API may be simpler now. I'm just relating the facts as I found them.)

Oh, and wasn't SDL used by Loki quite often for porting games to Linux?
Re:To my understanding... by Tough+Love · 2004-04-09 16:43 · Score: 2, Informative

if i recall correctly, SDL was originally developed by a guy who worked at Loki.

Actually, Loki hired the guy who developed SDL.

--
When all you have is a hammer, every problem starts to look like a thumb.

Thank you so much! by MachineShedFred · 2004-04-09 04:53 · Score: 2, Insightful

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.

OpenGL | ES is not OpenGL by Performer+Guy · 2004-04-09 04:53 · Score: 4, Informative

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.

Direct-compile model looks dangerous by DLPierson · 2004-04-09 05:25 · Score: 2, Interesting

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 :-(

Re:Direct-compile model looks dangerous by Screaming+Lunatic · 2004-04-09 08:58 · Score: 2, Informative

FUD. Offtopic. Flamebait. Why does every discussion remotely related to graphics have to deteriorate into closed versus open source drivers zeolotry.
Drivers are closed source now. Drivers will continue to be closed source in the future in spite of where the compiler lies. Having the compiler in the driver is the right decision.
Don't like it. 3DLabs released the front end to their compiler. There is work being done in Mesa to support GLSL.
From now on, all bitching about open versus closed drivers will be modded as offtopic. Everyone knows the pros/cons and reasons for either decision. No need to drive it into the ground.

Re:ABOUT DAMN TIME! by Saville · 2004-04-09 05:29 · Score: 2, Interesting

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?

Real time films? Not any time soon. by Anubis333 · 2004-04-09 05:50 · Score: 3, Insightful

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.

Re:Real time films? Not any time soon. by Jackie_Chan_Fan · 2004-04-09 14:41 · Score: 2, Interesting

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.

Re:ABOUT DAMN TIME! by be-fan · 2004-04-09 06:27 · Score: 3, Insightful

1) Its Apple's implementation of GL that's less than perfectly optimized. On Windows and Linux, OpenGL is as fast as D3D.

2) OpenGL has numerous releases in the last few years. 1.3, 1.4, and 1.5 were all released in quick succession. What rock have you been hiding under?

--
A deep unwavering belief is a sure sign you're missing something...

Re:Real time films? Sooner than you realize! by Anubis333 · 2004-04-09 06:40 · Score: 2, Interesting

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.

There's more than graphics... by Handpaper · 2004-04-09 06:43 · Score: 3, Insightful

Am I the only person who thought that:
"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.

Microsoft versus OpenGL by Anonymous Coward · 2004-04-09 07:42 · Score: 2, Interesting

> 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.

74 of 273 comments (clear)