PDA

View Full Version : OpenGL should provide direct font support



LuisAK
12-30-2012, 10:46 AM
in my opinion a next OpenGL release should support direct font support !

What do other´s think ?

Who could push such a development ?

l_belev
12-30-2012, 03:25 PM
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.

tonyo_au
12-30-2012, 05:46 PM
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.

kRogue
01-01-2013, 07:42 AM
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... https://github.com/p3/regal (https://github.com/p3/regal REGAL) is coming along but it's main purpose is NOT a utility library, but it does have GLU within it.

l_belev
01-02-2013, 06:14 AM
Every 3D app I have written has required 3D text to some extend whether it was a game or commerical software.

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

abdd0e77
01-26-2013, 12:15 PM
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.

V-man
01-28-2013, 06:28 AM
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".

LuisAK
02-24-2013, 01:36 AM
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
luis

thokra
02-24-2013, 04:11 AM
I was gonna write something harsh, but in between I reached my intellectual limit.

LuisAK
02-24-2013, 11:01 AM
here two other intellectual limits are reached by OpenGL:
http://www.naturewizard.com/Tutorials/Tutorial01/images/image005.jpg
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
Luis

Life is too short to fret around with inadequate systems.

thokra
02-24-2013, 11:13 AM
Have you ever done graphics programming? Do you know the mathematical implications of the clipping planes? Any idea?

kRogue
02-24-2013, 12:38 PM
here two other intellectual limits are reached by OpenGL:
http://www.naturewizard.com/Tutorial...s/image005.jpg (http://www.naturewizard.com/Tutorials/Tutorial01/images/image005.jpg)
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




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.

Nowhere-01
02-24-2013, 12:54 PM
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.

LuisAK
02-24-2013, 02:28 PM
http://www.opengl.org/sdk/docs/man2/xhtml/gluPerspective.xml

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

Parameters
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
987
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
Luis

LuisAK
02-24-2013, 02:39 PM
http://www.opengl.org/archives/resources/faq/technical/clipping.htm#0050
> 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
Luis

LuisAK
02-24-2013, 02:58 PM
http://www.opengl.org/archives/resources/faq/technical/clipping.htm#0050

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

malexander
02-24-2013, 06:47 PM
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].

mbentrup
02-25-2013, 03:04 AM
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.

Alfonse Reinheart
02-25-2013, 03:41 AM
by just disabling depth clamp.

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

mbentrup
02-25-2013, 08:25 AM
Alfonse is of course right, I meant enabling depth clamp.

LuisAK
02-26-2013, 03:01 AM
http://www.opengl.org/sdk/docs/man2/xhtml/gluPerspective.xml
void gluPerspective( GLdouble fovy,
GLdouble aspect,
GLdouble zNear,
GLdouble zFar);
-----------------------------------
and least sense makes zFar
-----------------------------------

best regards
Luis

thokra
02-26-2013, 03:11 AM
Why does it make the least sense? Did you read and understand the matrix on the page you posted?

Nowhere-01
02-26-2013, 03:16 AM
why do you keep responding to a person who either trolling or has development delay? either way he completely ignores your explanations and keeps posting idiotic, naked statements. it's already 20+ posts where bunch of people is trying to educate someone who clearly doesn't want to be educated.

LuisAK
02-26-2013, 06:27 AM
Thanks for the statements.

Now back to the topic:
When does "direct font support" come finally by OpenGL ?
Please don´t say "never".

best regards
Luis

thokra
02-26-2013, 06:33 AM
This is just plainly depressing. :doh: Even if it's a troll it somehow funny though.

LuisAK
02-26-2013, 08:07 AM
Yes, thokra
such a standard like OpenGL and no native font-support - just plainly depressing !

Have fun with the next release of OpenGL.

best regards
luis

Alfonse Reinheart
02-26-2013, 03:50 PM
Just to add an interesting fact to this "discussion", Direct3D doesn't support fonts either. D3DX has a font subsystem, but D3DX is not part of Direct3D; it's a library layered on top of D3D. Also, D3DX is deprecated and won't be getting updated for future D3D versions.

Thanks for the encouragement though. We will be having fun with the next OpenGL release.

LuisAK
08-18-2013, 10:50 PM
So, some months are around again.
What is the current status of direct3d and openGL now ?
Do they support directly fonts meanwhile ?

What´s the sense of this thread ?
Do the developers sometimes have a look in here ?

:doh:

Nowhere-01
08-18-2013, 10:55 PM
So, some months are around again.
What is the current status of direct3d and openGL now ?
Do they support directly fonts meanwhile ?
No. And it's very unlikely to happen.



What´s the sense of this thread ?
Absolutely none.


Do the developers sometimes have a look in here ?
In this particular topic? Not likely. See previous answer for a reason.

Alfonse Reinheart
08-19-2013, 12:36 AM
Oh, and before this thread gets closed as it richly deserves:


Have fun with the next release of OpenGL.

I am. Thank you very much.

;)

thokra
08-19-2013, 03:51 AM
What´s the sense of this thread ?

... say what? O_o

LuisAK
08-19-2013, 09:53 AM
What a poor system - and again you need some other tools
What date are we writing ? 2013
http://www.freetype.org/
http://www.freetype.org/freetype2/docs/tutorial/step1.html
nerdy technics like 1993
----------------------

aqnuep
08-19-2013, 12:49 PM
I think a moderator or admin should close this topic.

LuisAK
08-19-2013, 10:53 PM
This side could maybe help, maybe
1111
1112

LuisAK
08-19-2013, 10:54 PM
The History of writing:
http://www.historian.net/hxwrite.htm
This side could help - maybe

Nowhere-01
08-20-2013, 01:22 PM
I think a moderator or admin should close this topic.

i've reported 1st post and one of the last OP's posts from this thread. for lame trolling attempts\misleading nature of messages\attention whoring on Suggestions Forum. but V-Man was not online for significant amount of time and Khronos_Webmaster generally processes only obvious spam\inappropriate content.

i suggest adding OP to Ignore List (http://www.opengl.org/discussion_boards/profile.php?do=ignorelist) and\or unsubscribing this thread. that's what i do in case if someone on the forum goes full retard.

LuisAK
08-20-2013, 01:42 PM
Rediculous, the topic "OpenGL should provide direct font support"
should be closed by a moderator, because someone has an other another oppinion
than others.

Therefore I recommend
http://www.opendemocracy.net/
for OpenGL

kRogue
08-20-2013, 04:55 PM
This is just getting.. weird. Lets try to return, in a polite way, about font support in OpenGL. I'll try.

There is an extension NOW on NVIDIA hardware providing font support: GL_NV_path_rendering at

http://www.opengl.org/registry/specs/NV/path_rendering.txt

in that extension, glyphs from a font are realized as paths that the extension defines. In that extension, paths are drawn in essentially two passes: first a stencil pass to "compute" what portions of the screen are inside and outside the path and then a second path covering that area using the stencil test to actually draw to the framebuffer (and usually reset the stencil buffer).

Now, there are a large number of gotcha's in that extension with respect to font rendering:

For low-ish pixel density, hinting is a critical part of drawing glyphs. Hinting in true type fonts is via a "program" embedded in each glyph for a virtual machine. This hinting system is not a part of GL_NV_path_rendering and likely such a hinting system will never be reasonably do-able on GPU's.
You will need to render with anti-aliasing enabled to get reasonable output for typical letter sizes

There are more issues; font rendering is a very, very complicated beast. Indeed, drawing the glyphs is just one step. Then there is formatting (which includes kerning) and shaping (for script fonts). The complications do not stop there; character mapping and font merging is an issue and naturally requesting a font from the system is actually very platform specific and non-trivial. The NVIDIA extension has some of this built into it, but there are gaps and will drive those into font rendering up the wall.

There are also many, many font file formats with each file format offering different features and information of the font faces that it contains. It looks like the NVIDIA extension uses freetype2 much of the time and DirectWrite on newer MS-Window platforms (likely Vista or 7 and up).

I strongly suspect that the NVIDIA extension borders on heroic; it is a big extensions that does quite a bit of stuff and I strongly doubt it coming to core GL because GL is supposed to be platform independent and font query is very platform dependent... what about platforms that do not have fonts, eh?

thokra
08-21-2013, 04:53 AM
kRogue: IMHO it's cool you want to contribute in a sensible constructive way, but the OP has shown time and again that he doesn't understand anything about this topic.

LuisAK
08-21-2013, 05:53 AM
#39 shows that the poster of #39 doesn`t understand the sense of OpenGL font support.

thokra
08-21-2013, 06:19 AM
We could create a sub-forum where we put the most hilarious threads so we can get a good laugh when we feel like it ... please Khronos_Webmaster ... have mercy and close this thread.

Alfonse Reinheart
08-21-2013, 06:30 AM
Rediculous, the topic "OpenGL should provide direct font support"
should be closed by a moderator, because someone has an other another oppinion
than others.

The reason it should be closed is because you're negatively contributing to a thread you started.

You asked for font support. Other people explained why that's just not a realistic or reasonable expectation. You have continued to ask for font support, completely ignoring what everyone else said about it not being realistic or reasonable. Your "argument" is little more than "I think it should exist."

Then you started an absurd digression into near/far clip planes, which displayed profound ignorance on the subject of how a perspective projection works. When people attempted to correct you and help you understand how perspective projection works, you ignored them. Instead, you "responded" by linking to a few forum topics, quoting several passages about the limitations of near/far, and then declaring the restriction to be "nonsensical".

That's not an argument. Especially considering your obvious lack of understanding of how this stuff works.

And then, after almost 6 months (but not quite 6 months, so that the 6 month auto-locking hadn't kicked in yet), you decided to bump the thread. Your bump added no content. If you wanted to see where OpenGL and D3D were 6 months later, you could have simply read the APIs.

And after that, you posted messages that quite frankly make absolutely no sense. You post random images of stuff. At this point, I'm not even sure you're capable of communication in the English language.

In short, you have treated this thread as a dumping ground, where you completely ignore any reasoned, substantive argument in favor of repeating the same thing over and over. If you aren't going to respond in a meaningful way to anyone's posts, then why reply at all? Just make your suggestion and leave.

It should be locked because continued commentary in this thread serves no useful purpose.


#39 shows that the poster of #39 doesn`t understand the sense of OpenGL font support.

Just because someone disagrees with you does not mean that they don't understand you. It could just be that they think you're wrong, or haven't presented a case, or are babbling incoherently.


We could create a sub-forum where we put the most hilarious threads so we can get a good laugh when we feel like it

We already have that. It's called "Suggestions for the next release of OpenGL".

thokra
08-21-2013, 06:47 AM
We already have that. It's called "Suggestions for the next release of OpenGL".

Damn it, you're right. O_o This thread is right up there with the guy who wanted to create an application that turns text fragments into a AAA game or movie. :D

LuisAK
08-26-2013, 11:12 PM
What´s the problem of others regarding OpenGL-Text ?
http://stackoverflow.com/questions/2071621/opengl-live-text-rendering

OpenGL live text-rendering
I'm implementing a GUI built on top of OpenGL. I came to the problem that each GUI will have -- text rendering. I know of several methods of rendering text in OpenGL, however, I'm wonderin which of them would be best suited for a GUI.

Generally in a GUI we have two types of text -- static and live. Static is easy enough -- we can render a TTF to a texture and forget about it. It's the "live" text that is more bothering me -- imagine console, or a live chat in a multi-player game.

I thought of several options:

•no special cases -- render and load a texture each time the text changes, keeping in mind only to rerender it when actually new text appears, and trying to split the larger text into small parts (like per chat line). However this would still leave us hanging in cases like a score line that changes all the time, or a intro text that renders "per character" (typewriter style seen in some sci-fi games)
•quad-per character -- this also seems a popular solution, you prepare a texture with the ASCII table and render a textured quad character. However, I have serious doubts about the efficiency of such a solution. Tips how to make that faster would also be welcome.
•hybrid solutions -- however I have no idea how to implement that cleanly
The question hence is -- how to render text in OpenGL efficiently?

(if this helps, I'm coding in STL/Boost-heavy C++ and aiming at GForce 6 and later graphics cards)

Any suggestions welcome.

rombust
09-25-2013, 04:01 AM
The ClanLib SDK http://clanlib.org/index.html can render an entire screen of text using subpixel rendering using a single OpenGL call, by simply batching calls and caching the glyphs in a single texture. (ClanLib has a zlib style license, so you can extract the code or use the SDK). OpenGL does not and should not support fonts directly.