Slashdot Mirror

nVidia's extensions alone total more than 500 pages, compared to 230 pages for the entire OpenGL 1.3 spec. ATI has their own comprehensive list of extensions, as does SGI and many others. Since there's little natural overlap, each vendor implements similar features in a different way (e.g vertex shaders), and you have to code for each vendor's set of extensions separately. The OpenGL ARB can "ratify" extensions to promote standardization, but you still have to cope with them not being present at all.

This is exactly the problem developers have with DirectX - MS regularly revs the entire API to try and support features from every vendor, so there's an ever-increasing number of ways the underlying hardware differences are exposed, and the number of hardware caps that have to be checked before doing anything is growing rapidly. There are 4 different versions of pixel shaders that a vendor can support in DX 8.1, and the only reason it's not more of a mess is that there's only two chips which support any of them so far (and one of those isn't even available yet).

Regular simplification & unification of all these diverging directions is required. Vendors should of course be able to add innovative extensions, but a core of Really Useful standard features must be maintained & extended, so that hardware vendors have a baseline to target, developers can rely on the features being present, and the lowest common denominator gets steadily pushed higher for everyone.

There's a lot of discussion on how/when/why they want to move forward to OpenGL 2.0. Gives some interesting insights into how these things are done.

Also, there's some talk about nVidia's new position on opening up their vertex shading IP, GL_vertex_program_NV vs. ATI's GL_EXT_vertex_shader, and which approach would be better for OpenGL 2.0 (low-level vs. high-level).

I think you can't have 3D audio library without advanced sound device drivers. And AFAIR emu10k1 driver supports effects like delay/flanger/gain, but do not support 3D sound. Main problem is - nobody need advanced sound drivers.
Most of people just need to listen mp3 (it's similiar to word processors - most people need only .doc import/export). The only way to fix that is to create more 3D games for Linux.
So download SDL then get some info from OpenGL site and gamedev then start coding! :-)

AMD is member of the OpenGL ARB (Architectural Reviewer Board) www.openGL.org

Its true that XBox is giving DirectX a second platform, but OpenGL is doing well, and the preferred 3D API everywhere but WinWhatever (the Mac being a notable example).

There is intensive ongoing work on both APIs, and don't think for a minute that Direct3D would be what it is today without OpenGL driving it.

By the way, Direct3D is precisely nowhere in the higher end 3D marketplace...games are by no means the only 3D application. I doubt they're even the major money maker - I suspect CAD/CAM has that honor.

We'll see how things look going forward...I expect OpenGL to be around for a good, long time.

Just take a look at the Official OpenGL Website to get a feel for how lively the OpenGL world is...the laptop version of the NVIDIA Quadro2 professional GPU looks pretty sweet!

186,282 mi/s...not just a good idea, its the law.

I think you're thinking of OpenGL.

Say what? NVidia's cards have always rocked (except the ZX chipset admittedly), I agree. But NVidia provide a level of community support *far and away* better than ATI. NVidia host conferences for grad students and their professors. They have developer conferences in many different countries. Matt and Cass from NVidia hang out on opengl.org's discussion forums and help everyone out (newbies, old hands, the lot). The developer documentation is sublime - and everyone can get at it. Plus their drivers *just work* 9 times out of 10.

I could care less about driver specs. The 3dfx ones are around if I want to see how modern-ish graphics cards are set up. And their drivers are such good quality, I can see why they don't want mutations springing up all over the web. I certainly don't have a problem with such a pleasant company to work with wanting to hold on to a few secrets.

Henry

• The Nirvana Editor
  It may not be an MDI (multi document interface) like Visual C++, but then I like being able to pop up a xxgdb window and have three scrolling xterms of ouput from gcc's last runs rather than tabbing through a tiny window. Got better syntax highlighting too.
• Don't foget EMACS
  If you can't do it in EMACS, it probably can't be done (or is waiting for the Lisp to be written.)
• One acronym - CVS
  As professional who has worked on real program (i.e. real-time embeded OSes for cirtical system with more than a Megabyte of Z80 ASSEMBLER code in some files) I cannot begin to attest to the superiority of CVS (or even RCS) over Microsoft's $600 SourceSafe product for managing (or mangling) project documents.
• Bugzilla
  Decent bug tracking tools are hard to come by and this one has withstood the test of time (and the mozilla codebase). I don't know of anything equivalent shipped by Microsoft (or specifically for their OS).
• It's been mentioned already, but OpenGL works just as well on most Linux boxes as it does on MS Windows. I've written applets and games (for a University graphics class actually) that compile and run under both Windows and Linux.

Well, I don't know about the mice, but I used a very generic USB keyboard ($25) with a friend's PS2 to take the bundled BASIC for a spin. It was quite fun (always nice with a basic that let's you draw Gauraud-shaded triangles with a single command, although that's of course pretty simple in C/OpenGL too). It seemed to lack any high-precision, as in <1-second resolution, timers though, which kind of killed it for me. Anyway, the keyboard worked just fine.

have you considered SDL? I've used it for some development, and I've found that it is both powerful and flexible enough to support development on both Win32 and Linux environments.

It's equally interesting to note that it supports OpenGL - I happened across the old NeHe tutorials that I learned on at the OpenGL webpage, re-written to include information on SDL. Good stuff.

The technology is there; the trick is to convince developers that learning the new API is worth it, and that by doing so they will make their code more portable - and that this is a good thing.

You don't need graphics-card/linux-specific hacks. It was reported on OpenGL.org recently that nVidia added the functionality to OpenGL it's extensions system.

All we need now is the implementation of their extension in Mesa - if they're going to go to all the trouble of developing OpenGL extensions you'd expect nVidia to help there as well.

The graphics card area of interest has moved away somewhat from the super-high fill rate battles that were all the rage in the day of the Voodoo cards.

It's all about interesting and orthogonal features now. GeForce 3 brings vertex and pixel shaders in hardware to the mix, as well as hardware shadow map support. The disappointing thing is that 3D textures (despite word otherwise from John Carmack) don't appear to be accelerated in hardware, at least with latest drivers (see a recent thread in the advanced section of www.opengl.org on that unfolding story - NVidia are soon to make an announcement on what the deal really is).

Being able to program in a pseudo-assembler language for custom per-pixel effects is a hark back to the old days when you had complete freedom over everything you could do, but most of it was slow. Now we have a better mix where we are hardware accelerated, but pretty flexible down to a programmable level. *However* the current revision of pixel shaders (1.0? 1.1? can't remember) on DirectX (and very similarly and more relevantly on OpenGL) aren't as flexible as some may like (notably John Carmack), since to paraphrase him "You can't just do a bunch of maths and lookup a texture". Hopefully that will get better with time.

Yes these things are important to games mostly. And yes they are arguably the biggest step forward in consumer graphics tech since the original 3dfx card... certainly since hardware TnL. Wait for the price to come down (since initial pricing is aimed at developers and the *really* hardcore gamer), and in the meantime amuse yourself with some of the demos from Nvidia's developer site. Nvidia are by far the most developer friendly company I've ever encountered, so short of Open Sourcing their drivers (which we have no right to expect them to do), they are almost ideal from my (developer's) perspective.

Henry

No, trademark law was created to stop deliberate fraud. I can not, and should not be able to, sell a graphics library called OpenGL. That should be the limit of SGIs rights in this matter.

The "confusingly similar" nonsense is a recent addition to trademark law designed to legalize harassment and squash dissent. Go look at www.openil.org. Then look at www.opengl.org. Confused? You shouldn't be. Nor should 3 bits different in the name confuse you, any more than opening a pizza restaurant next door to a McDonalds is "confusingly similar" because the addresses are only one digit different.

Of course, this presupposes you are not an unelected, braindead, WIPO judge.

--

why link to SGI? Go directly to opengl.org

...to push game programmers not to use DirectX in the first place? Stick to open standards and you can port the games to just about anything.

• OpenGL
• OpenAL
• OpenPlay
• etc...

"[...]no support at all for 3D graphics[...]"
While I agree with many of your other observations about Linux' shortcomings as a gaming OS, that one just plain isn't true. Support for 3D graphics under Linux, through the magic of OpenGL, is actually pretty good--and getting better.

Sounds to me like OpenGL using the DRI stuff with XFRee86 4.0 should be pretty low-latency, since that makes your app talk directly to the hardware. Oh, and modern 3D hardware sure beats (S)VGA when it comes to doing stuff on screen. (And no, I'm not karma-whoring with those links) ;^)

Some efforts are underway to provide OpenGL objects and verticies via XML. Check out XGL or BGL. for example. Given the industry push to XML, wouldn't one of these standards (Well, once they get a little more fleshed out) be a more logical choice?

Glide was obviously based on the simplicity of OpenGL. It's designer was Brian Hook who worked at id Software on Quake2, and I think previously worked at SGI on the first optimized (read: non-Microsoft) OpenGL software implementation for Windows.

It lacks the high-level features of OpenGL such as doing matrix transforms, display lists, primitives, texture coordinate generation, etc. Glide was designed for game developers, who generally would prefer to implement these functions themselves, anyway. Since Glide was chipset specific and offered a lot of low-level control, you could come up cool effects with a bit of hacking. What 3DFX now hypes as T-Buffering was easily possible on the Voodoo1 chipset with Glide 1.1. With a couple of lines of code you could get fairly effective full-scene anti-aliasing and motion blur.

Most companies were developing their own APIs in the mid 90's so it was natural that 3DFX would do it as well. Rendition (RIP), 3DFX's early main competitor, had their own called Redline and NVIDIA's first attempt, the Edge3D, had an API that was kept away from anyone but licensed developers. Sidenote: NVIDIA used to imply that the Edge3D could render quadratic surfaces in hardware - I wonder what ever happened to that feature. d:^)

Paul

The humor comes from noting that opengl.org, the official OpenGL website, refers to the Mesa 3D library as "Mesa OpenGL". Which, according to their own rules, they're not supposed to do...

It depends. If you want to program still and animated 3D graphics, then you have quite a few choices. Here are a (tiny) subset of the ones I know:

• Here is a series of accessible tutorials on the mathematics and implementation of 3d graphics
• OpenGL is the API of choice for most platforms. Simple, clear and easy to understand. It does assume that you know what the basics are though.
• Mesa is a free workalike implementation of OpenGL for most platforms. Reading the source to the included demos is a good way to start learning.
• Python is a very good language with OpenGL bindings with which to start messing around. If C and C++ seem too tedious just for experimenting then try PyOpenGL. Python itself can be learned in a weekend after which the GL module is there to play around with.

If you're not interested in programming - just modelling and creating then check out:

• Povray - a flexible raytracer
• Blender - a modelling, animation and sequence editing suite
• Some examples of what is possible

All of these tools and references are free and work on Windows and Linux alike.

Also, how prohibitive is the hardware for this kind of thing?

All you need is a resonable midrange PC and a decent accelerator. A hardware-accelerated graphics card on your platform is a must to view complex 3D graphics at any kind of framerate. Vendors with good Linux support include include Ati, nVidia, Matrox and 3Dfx.

They could redirect the work into porting Inventor too as many platforms as possible just like Mesa does with the OpenGL API. With the *nix base in Open Inventor plus Coin's BeOS, and Windows versions, most people should be covered if they merged.
Then if TGS open sourced their Windows and MacOS versions of Open inventor that would be even nicer.

I taught a bit of introductory OpenGL to grad students at UNC-CH, and now I'm recycling the lessons for a 14-year-old who I'm tutoring. He is a beginning programmer.

Most introductory programming books use console I/O because it's universally available. OpenGL is pretty nearly universally available, and lets kids jump straight into graphics (2D or 3D) and animation with a minimum of fuss.

Hopefully you could buy copies of the OpenGL Programming Guide to supplement whatever textbook you are using. It's an excellent tutorial for OpenGL specifically and 3D graphics generally.

Setting up OpenGL

opengl.org

First its usually pretty interesting to kids playing video games.
Second, with GLUT much of the hardwork is done for you(creating a window, double buffering.. etc)
Third its actually not hard to do some simple stuff(boxes ,spheres, etc) and make simple camera movemens and settings. you could even go into texturing and lighting but that might be more agressive.
I would have LOVED to learn a little OpenGL in high school.
go here for examples and tutorials: Opengl.org

This is such disinformation...Software OpenGL under windows does not go through D3D. It is just not highly optimized. They are using the same Software OpenGL layer that they have always used and it existed before Direct3D was a glimmer in MS's eye...

Yes, its a crappy implementation, but its not THAT crappy. If you must have software OpenGL, then use Silicon Graphic's replacement or use Mesa.

Best bet is to get the "Red Book" - the OpenGL programming guide. This is a great book, especially if you're new to graphics concepts. (Although, if you want a good graphics book, Computer Graphics Principles and Practice by Floey, Van Dam et al. is still the best text IMHO).

The Red Book is available online here

Some good tutorials are here .

For general information, plus a lot of good links, www.opengl.org is the place to look.

Gingko

Uh, what are you talking about?
From http://www.opengl.org/Documentation/G LUT.html

The GLUT library has both C, C++ (same as C), FORTRAN, and Ada programming bindings. The GLUT source code distribution is portable to nearly all OpenGL implementations for the X Window System and Windows 9x/NT. GLUT also works well with Brian Paul's Mesa, a freely available implementation of the OpenGL API.

The current version of the GLUT API is 3. The current source code distribution is GLUT 3.7.

So, um...it's not opensource? Why can I download the source from here then?


One Microsoft Way

FYI, I found the link on Opengl.org - shouldn't be too difficult to port it over to a *nix box if you can get the source.

...but then, I'm using Java (at home: OpenGL)...or I might use CodeWarrior on my iMac.

Some people may not be this lucky.

I recall long-ago, Brian Hook saying that Quake3 does 6 bump-map passes, so I wonder if they use this technique. There's a followup article on the OpenGL site using a 12(!) pass lighting method.

Uh, OpenGL has supported hardware T&L since 1992. You'd have to check with Intense3D to be sure, but I believe Intergraph was shipping hardware T&L OpenGL systems running Windows NT by 1994. D3D is years behind on this one.

One of the reasons it's taken so long to get hardware T&L in the consumer market is that D3D didn't support it until very recently, and Microsoft shut off OpenGL support in the Win9X line as quickly and completely as it could afford. You can say similar things about stencilling, full-scene antialiasing, curve/surface support, and probably a dozen other cases in which it's taken a while for D3D to catch up to OpenGL. Even multitexturing shipped as an OpenGL extension (from 3Dfx) before it shipped in D3D.

Also, check the OpenGL Architecture Review Board meeting minutes. The number of OpenGL extensions that are being cranked out per quarter has gone up, not down, in the past year.

How about real standards like CORBA, OpenGL and PHP or PERL. What comes to sound OpenAL is very promising.
_________________________

...It will be necessary to interface BGL low-level primitives to existing video and 2D APIs, high-level widget libraries and GUI builders. A feature reference that provides an example of the kinds of requirements for vector graphics is SVG (Scalable Vector Graphics), currently under specification at the W3C (see http://www.w3.org/TR/WD-SVGReq )...

I was just reading about some opengl and coding and spotted this article. Looks like this idea is being looked at.

links:
http://www.opengl.org/News/Special/Features.html
http://www.opengl.org/News/Special/BGL.html

...It will be necessary to interface BGL low-level primitives to existing video and 2D APIs, high-level widget libraries and GUI builders. A feature reference that provides an example of the kinds of requirements for vector graphics is SVG (Scalable Vector Graphics), currently under specification at the W3C (see http://www.w3.org/TR/WD-SVGReq )...

I was just reading about some opengl and coding and spotted this article. Looks like this idea is being looked at.

links:
http://www.opengl.org/News/Special/Features.html
http://www.opengl.org/News/Special/BGL.html

The beautiful thing about OpenGL is that it is mostly platform independent. So you could start by adapting existing code, reuse the OS interfacing parts, and put in your own OpenGL code. Such code and lots of tutorials can be found at www.opengl.org and in the example directories of a Mesa distribution. (We owe Brian!)

Side note:
Interestingly enough the Win32 world seems to stay closed as it always have been, while there are many OpenGL demos for Win32 out there, few of those authors disclose their source.

Ultimately get the new Woo book for OpenGL 1.2 and the Kilgard book for the interaction with the X environment.

If you are interested in 3d graphics for FreeBSD watch the announcement for the upcoming 3d section on www.freebsd.org

In a couple weeks at SIGGRAPH, SGI will be demoing hardware acceleration and IRIS Performer under linux.

I don't know the details of the TNT2 release. My best guess is that they have SGI OpenGL as a base. That means they'll be releasing binary only.

That's not particularly bad. There is room to have more than one OpenGL implementation. In fact, there are already three (Mesa, XiG, MetroLink).

The biggest problem is that OpenGL provides and API and not an ABI. That means programs can be recompiled against different OpenGL libraries and work, but compiling against one library doesn't insure compatability with another. No one wants that to be a problem, because we don't want different versions of applications to be required. I've been talking with vendors and suggesting that Mesa be made a reference platform. The advantage of that is that everyone gets it for free and we all agree on interface difference. Mostly this hasn't been a major issue in my testing so far, but it has come up. It also helps that we have some common benchmarking programs that we can all use to test.

That takes care of the commercial side of the discussion, now lets look at the free software side of the problem.

Mesa is the OpenGL layer. It currently has a hardware layer known as DD for lack of a better term. The current 3dfx support for Mesa goes through that interface. SUSE has worked on extending that to something they call ACL. See http://www.suse.de/~sim for more information. People are also adding multithread support and optimizations to the core of Mesa

GLX provides and interface layer between an X server and OpenGL. It also allows remote OpenGL applications to communicate with a local server. SGI made GLX open source.

Precision Insight took GLX and Mesa and rolled that into the XFree 4.0 tree. So, minimally all XFree 4.0 servers will have the capability of doing software OpenGL. This will become a new "assumption" about a Linux workstation which is great.

There is parallel work going on between SUSE and PI at the moment. Simon from SUSE, is working on a hardware interface layer (generic PCI) and an integration layer (MLX).

Finally Precision Insight is working on the DRI, direct rendering infrastructure. This allows applications outside the X server to talk straight to the hardware. Here's Q&A you can read.

My work on Glide for Rush (and now Banshee/V3) needs something like the DRI. My first solution was a bit of hack (called the Rush extension) and was an X server extension. Switching to the DRI should standardize things further.

I hope this clears things up. I'm extremely pleased to see all the progress. Having nVidia release an OpenGL is fine as long as it interacts well with applications compiled against Mesa. I'm fairly sure it will since they want Q3 to work!

- |Daryll

And yes, I am too lazy to cut-n-paste! So it is appreciated (if done right ;-)

OpenGL is a registered trademark of Silcon Graphics Incorporated.
To get more information about OpenGL, visit thier website at www.OpenGL.org

Excerpt from the source of the web page:


OpenGL is a registered trademark of Silcon Graphics Incorporated.
To get more information about OpenGL, visit thier website at www.OpenGL.org




Thier website is not on yer server :)

I hope this is just a misspelled error :)

On the other hand it's not very nice to create a page, and immediately advertise it on slashdot.. Maybe you should wait someone else to recognize your creation and request that it's published here :)

Flame ON ;)