I would be interested to hear what people think of this statement. I think that beyond operations such as draw pixel, draw line, draw triangle etc.. which actually tell your hardware to do something the APIs are not very useful for the following reasons: (1) API commands which do not actually do anything with hardware but aid the implementation of 3D techniques (like the imaginary procedures SetClipSpace and ClipToFrustrum) are really just there so that programmers don't have to write a whole lot of new code to do something that somebody has already figured out, right? That is all very well, but using these API commands is sort of like joining a project part of the way through and having to learn how the previous programmer(s) code. I think that in order to program in 3D you need to know a lot of 3D theory first (it is very difficult to make use of pre-written functions without knowing the theory behind them and exactly what they do). This means that by the time you understand the functions by studying the 3D theory behind them you know enough to write your own function anyway. (2) The issue of optimisation. Let's say you are already a 3D guru - you know how to fully 3D-clip an object against the six(?) clipping planes, you know the theory behind radiosity, BSPs, beziers etc.. Should you really place your trust in the person who wrote the API code? How do you know their functions are as efficient as the ones you could write yourself? Where I am coming from is that I have predominantly been using Glide (3dfx) which mainly deals with talking to a specific piece of hardware and making it do something. The most obvious benefit of this is that it saves you dealing directly with memory addresses etc.. and makes programming more accessible. The more I have been looking at code on the forums the more I have been seeing that DirectX and OpenGL have all these 3D functions (ones that don't actually address hardware, but implement different 3D concepts). Although that might be of benefit to someone whose mind works the same way as the API writer(s) and who can easily incorporate the existing functions into their own program, to me doing things that way looks really restrictive eg. you have to write your program around those functions and implement the 3D theory behind them in a certain pre-determined way. Perhaps some of you think the absence of these 3D-functions from Glide makes it less attractive to use? If you reply to this post please don't turn this into an API war because I hope to hear what other people think of the first comment I made. It is not my intention to discuss the pros and cons of each API because that has already been done numerous times on other threads, I want this to be a general discussion of the API and its inclusion of 3D-functions, rather than talking about specific implementations. The only reason I mention Glide is that it makes it easy to highlight the difference between an API which predominantly deals with talking to a device, opposed to one that does that as well as a whole lot of other 3D things. I hope you understand what I am getting at. Paulcoz. Edited by - paulcoz on 4/6/00 4:28:37 AM

Well, speaking about OpenGL, I''d have to say that it''s feature set is about right for the application level they were targeting. OpenGL, I don''t believe was targeted at game programming, but more at modelling. As such, there was no need to include only the hardware level commands. On the other hand, if you already had the vertex list for a model, all you have to do is read it in and set your viewing mode appropriately. If the implementation happens to accelerate it, fine, but the main idea is to get a image on the screen.

I guess what I''m saying is that you''ve got to take the purpose of the API in context. Glide''s purpose is to provide excellent low level support for hardware, and it does what it''s designed for (near) perfectly.

I think one of the reasons that they try to have the API do more and the programmer do less is that it reduces the amount of data that needs to be sent to the card. Is not the bus bandwidth an issue on these cards when you render complex scenes? While 3d card makers can improve on the internals of the graphics cards they are often limited by the standardized bus speed, meaning that the APIs strive to send less data to do more. That is the motivation I have heard for ''higher level'' APIs and why many predict that even more things will be handled by the cards in the future.

Eventually you might have cards that allow you to send over an entire scene graph in the beginning of the program and then just send changes to the card while the program is running.

Henry

Note, I am not 100% sure about this and I am really no 3d guru myself.

I don''t know much about Direct3D and virtually nothing about Glide, but I know OpenGL pretty well, so I''ll address these issues from that perspective.

In response to 1: Most of the calls in OpenGL are supported in hardware (we''re talking base gl here, not GLU or anything else), at least they are on the platforms OGL was intended for: high-end graphics workstations. However, many features once only available on high-end machines are becoming available on consumer level hardware, T&L being one good example. And since you mention clipping, ATI''s next gen will support that in hardware. So, there''s one reason to use API calls instead of your own.

In response to 2: Chances are, the people who wrote the API code and drivers are pretty damned good, so chances are you''re not going to get much of a performance boost by writing it yourself. The only time you might get a significant win is when replacing something generic with something specific.

There are some really good points here.

I think what I wrote might have been a bit misleading. I didn''t mean I want to write a whole API or do everything myself. I just wanted to comment that beyond using an API to access hardware a lot of the pre-written 3D functions were maybe less than useful seeing as you have to understand the underlying 3D theory to use them. And, if you understand that you can probably write your own.

I agree with SiCrane that you have the take the purpose of the API in context. OpenGL was obviously designed for applications like CAD and other graphics progs to begin with.

"The only time you might get a significant win is when replacing something generic with something specific."

That is primarily what I meant in my second point, though again I was not talking about the API itself or driver (which I don''t want to touch!! ) but the prorgam code. I can tailor a custom clipping routine to my engine, without having to do things that I don''t want to, or include things
that I don''t need.

Thanks for keeping this thread sensible. We all have our API preferences and it is a waste of time arguing over them.

Paulcoz.