OpenGL should provide direct font support

in my opinion a next OpenGL release should support direct font support !

What do other´s think ?

Who could push such a development ?

My opinion is that opengl should stay narrowly specialized in it’s field, that is, interface to 3D graphics hardware. It is big and complex enough as it is. If we must have some kind of standard font api, then lets make a separate one like OpenAL, OpenCL etc.
Imagine font support was added (i don’t know what exactly it would be). But most opengl users really need just the 3d graphics. Still all opengl vendors will need to implement support for fonts, only to stay unused most of the time - unneeded burden for them.
Keeping the things as separate as possible is the best way. Otherwise it gets bloated and messier out of control.

nVidia have arleady made moves towards a font system with their NV_path_rendering. I would like to see this promoted. I disagree with I_belev that opengl uses just do 3d. Every 3D app I have written has required 3D text to some extend whether it was a game or commerical software.

I agree with I_believ. I do like NV_path_rendering, but font support is a terribly hairy affair. First off: fonts come in lots and lots of formats, loading and using all those formats is non-trivial. Then we get to rendering: many SVG fonts (such as TTF, etc) have a hinting system which is a dedicated virtual machine. The need for hinting is because letters are usually drawn pretty low-resolution compared to the complexity of the path defining them. Going further, for formatting text kerning is only the beginning there is also shaping. Next comes font selection, i.e. selecting a font from a generic-ish description. Different OS’s have different ways of selecting fonts… and then comes font merging, there are situations where the glyphs of a font are broken into multiple files.

AFAIK, NV_path_rendering, likely uses freetype to load fonts and the uses a very specific OS mechanism for selecting a font (for example under Linux it likely uses fontconfig, which is, in my opinion, garbage). Moreover, AFAIK, NV_path_rendering does not support shaping either…

What would be nice: an official utility library backed by Khronos where these bits can be implemented. GLU was the last one official utility library but it is OOOOLLD, out dated etc…[]( REGAL) is coming along but it’s main purpose is NOT a utility library, but it does have GLU within it.

Every 3D app also for example loads textures form files. Does this mean file input/output functions should be added to opengl too?

I’ve been programming Opengl as a hobby for over 10 years and the hardest thing to get right is decent font rendering. Either libraries are old and unmaintained, not cross platform, or have horrible documentation/complete tutorials. While I agree with I_belev that fonts probably don’t belong in the spec itself, there needs to be something a little more official.

There will never be anything official. Even GLU is no longer maintained and that has been like 13 years.
Your best bet is to write your own code. You have been doing it for years, so invest some time into your own font system. The easiest is to create a “font map”.

Thank´s for the posts.

My opinion:
If OpenGL is not able to support native Font-Support it will still remain as a poor system.
It seems that the core developers of OpenGL have reached their intellectual limits.

best regards

I was gonna write something harsh, but in between I reached my intellectual limit.

here two other intellectual limits are reached by OpenGL:

The near clipping plane, and the far clipping plane.
How can I tell those guys that these limits are not necessary ?

Therefore here are my suggestions for the next release of OpenGL :

  • native font support
  • no near clipping plane
  • no far clipping plane
  • better polygonal functions

best regards

Life is too short to fret around with inadequate systems.

Have you ever done graphics programming? Do you know the mathematical implications of the clipping planes? Any idea?

This has got to be a joke, right? The near and far clipping plane are only concepts and not even a part of the OpenGL core profile specifications. I strongly urge you to read the specification and learn what are normalized device coordinates. Once you kind of understand what those are, then read what a projection matrix is, and then about various standard projection matrices.

Going further, the “native font support”, did you even read what people wrote? OpenGL is a specification meant to exist on many platforms: MS-Windows, Mac OS-X, Unix … and even to a lesser extent mobile platforms in some cases [at the very least OpenGL ES, but some mobile do OpenGL as well]. A specification needs to specify what to do with the files, what is rendered, etc in a way possible on all these platforms. On the subject of font rendering, hardware font rendering is a highly non-trivial action. Indeed, once hinting gets into play, then without truly extraordinary and heroic efforts one must use the CPU to render a glyph… in truth, I think even with such efforts, once hinting is required, then one must still use a CPU.

As for “better polygonal functions”, do you mean triangulation or arbitrary polygons? If you want that, then use GLU to freaking do it for you… or rip it out of Regal and call it a day.

or you could just ignore him and ask moderator to lock the topic leaving only explanation why initial idea is stupid. that guy obviously have little or nothing to do with graphics programming and keep’s posting that crap out of boredom, cause he gets a lot of attention for his extreme ignorance. he obviously didn’t read your messages.

i suggest to make a sticky thread for this forum, containing Frequent Suggestions in FAQ format, containing some popular suggestions with short explanations why they are not or shouldn’t be implemented.

gluPerspective — set up a perspective projection matrix C Specification
void gluPerspective( GLdouble fovy,
GLdouble aspect,
GLdouble zNear,
GLdouble zFar);

fovy Specifies the field of view angle, in degrees, in the y direction.

aspect Specifies the aspect ratio that determines the field of view in the x direction. The aspect ratio is the ratio of x (width) to y (height).

zNear Specifies the distance from the viewer to the near clipping plane (always positive).

zFar Specifies the distance from the viewer to the far clipping plane (always positive).

if you have a look at the Parameters zNear and zFar, these are unnecessary restrictions !

I know, what I´m talking about I´ve been building such a system
and a global player is holding two patents on my name.

the topic is: suggestions for the next release of OpenGL
an this is my opinion

best regards
> When I move the viewpoint close to an object, it starts to disappear. How can I disable OpenGL’s zNear clipping plane?
> You can’t. If you think about it, it makes sense: What if the viewpoint is in the middle of a scene? Certainly some geometry is behind the viewer and needs to
> be clipped. Rendering it will produce undesirable results.

> For correct perspective and depth buffer calculations to occur, setting the zNear clipping plane to 0.0 is also not an option.
> The zNear clipping plane must be set at a positive (nonzero) distance in front of the eye.

> To avoid the clipping artifacts that can otherwise occur, an application must track the viewpoint location within the scene,
> and ensure it doesn’t get too close to any geometry. You can usually do this with a simple form of collision detection.
> This FAQ contains more information on collision detection with OpenGL. …

what a nonsensical restriction

best regards

“setting the zNear clipping plane to 0.0 is also not an option. The zNear clipping plane must be set at a positive (nonzero) distance in front of the eye.”

what a nonsensical restriction.

[QUOTE=LuisAK;1248500]- no near clipping plane

  • no far clipping plane[/QUOTE]
    You don’t understand 3D graphics math if you don’t know why those are necessary. Btw, you can still make geometry in front of the near clipping plane or behind the far clipping plane by using depth clamping, which is part of OpenGL. Check twice before you ask for something.

What does that mean? I don’t think the term “polygonal function” even exists.

It’s not at all nonsensical. In a perspective projection, the X and Y coordinates are divided by the distance from the camera, Z. If Z is zero, you’ll get divisions by zero. Or, in practical terms, an object zero units from the camera will appear infinitely large. To avoid this, the near clipping plane is nudged slightly out from zero.

It would be nice, in some cases, to have more precision available so that the far:near ratio can be made more than 1,000,000:1 without significant z-fighting. This is a hardware restriction, however, and not something imposed by OpenGL (or DirectX, for that matter). When a 64b z-buffer makes its debut, I suppose you could set the far plane to some huge value and have a nearly-infinite frustum. Until then, you pretty much have to work with the hardware available, and the best it can currently do is a 32b FP z-buffer in the range [0…1].

Actually OpenGL can deal with a literally infinite distant far plane already, it’s just not possible to set up this projection via GLU (but then GLU isn’t part of OpenGL), it doesn’t even have a big impact on Z-buffer precision. Most of the Z-buffer range is used for the distances close to the near plane.

Moving the near clipping plane onto the camera (which happens when zNear = 0.0) will cause the near plane to be shifted to infinity in clip space along with the camera, which will cause a lot of precision issues (24, 32 or even 64 bit integers are a bit too small to store infinity), but for all practical purposes you can get the same effects as zNear = 0.0 by just disabling depth clamp.

by just disabling depth clamp.

You mean enabling depth clamp. Enabling depth clamp disables near clipping.