I re-read this topic with great interest just recently.
You clearly did not read it carefully enough. For example:
If I can’t use wglUseFontOutlines with a >=3.0 context
As I previously said:
I know that there are several libraries available as alternatives to wglUseFontOutlines but they seem to be made for OSs other than Windows (Linux mainly), and they require other libraries that work only if other libraries are present, etc.
FreeType. It creates images from fonts and gives you font metrics. It doesn’t rely on anything else.
At least wglUseFontOutlines is very simple.
Simple doesn’t imply “powerful” or even “good”. It is only simple to use.
Font outlines don’t support kerning or antialiasing (beyond multisample, which affects more than just text).
In fact, I read it quite carefully, and not necessarily just your posts. Dukey wrote that wglUseFontBitmaps cannot be used with a 3.1 context and I assume the same is true for wglUseFontOutlines.
I meant libraries based on Freetype or Freetype2 or whatever and not Freetype itself. And since I wrote that I use extruded 3D text a lot, what good an image created by Freetype from a font would do? I need vertex, normal and texcoord data and not a bitmap image.
BTW wglUseFontOutlines does support kerning and even gives you font metrics (although the kerning pairs you get are imcomplete). And it does not create images, it draws primitives, so antialiasing is not a concern, at least not at that point.
Dukey wrote that wglUseFontBitmaps cannot be used with a 3.1 context
And yet, he did not explain why. I don’t know of anything that could possibly have changed to cause this, since wglUseFontBitmaps uses OpenGL commands, and those OpenGL commands still exist and do what they have always done.
So until he shows some proof, I’m going to consider his statement to be in doubt.
A hearty second for Freetype. There’s always GLU/Mesa for triangulation routines. A search for ‘triangulation library’ turns up GTS, CGAL and a few thousand others.
One could probably whip up a bare bones, brute force CDT implementation in under 300 lines of code or so - more than adequate to the task of triangulating a few glyphs for extrusion or whatnot.
I am not going to pretend that I can whip up a CDT implementation (any force) but I would still like to know why do you think Freetype is the way to go?
But you wrote that it creates an image from fonts. How can I make it to give me a set of vertex, etc. data instead? Please don’t tell me to create a CDT whatever because I have no idea what that is.
How can I make it to give me a set of vertex, etc. data instead?
FreeType is a library for accessing font data (metrics, curves, etc) and rasterizing fonts. If you want a “set of vertex data” for a glyph, you will have to generate it from the glyph’s actual data (the set of bezier curves and such).
In short, there’s no simple function call to do what you want. You can do this with FreeType, but it will require actual effort on your part.
Thanks, now I understand. It is not what I was hoping for because my knowledge in ‘CGT’ or whatever is very limited. I was hoping for a library that ‘converts’ a font to a set of buffers I can upload to a VBO but it seems it does not exist.
BTW is moving to OpenGL >=3.0 really worth the effort? Compared to 2.1 + GLSL 1.2, what do you think are the main benefits of the new API? And I don’t mean in theory, because it is clear to me that for a brand new project one should always use the latest API. But in practice, do you think it would be worth the considerable effort to convert/redo a project I have been working on for three years that now works reasonably well in 2.1/GLSL 1.2?
For my personal projects, I have moved to core-GL3.2. I did not regret it yet.
What I like most of it is that it somehow “frees your mind”:
1.) You no longer need to decide “do I use fixed function for this, or do I write a shader?”. Now everything is done in shaders. And writing a just small shader is most times easier than to configure the FFP to achieve a certain effect.
2.) Which version of an extension do I use (EXT/ARB/Core)? Things like geometry shaders and FBOs are “just there”.
3.) In your program, you no longer need to care about mixing various fixed function states and their modern counterparts. No longer you need to care about glEnable(GL_TEXTURE_2D) and the like. I never need to use glUseProgram(0). Shaders are always active, etc…
4.) No more wondering “do I use built-in GL state in my shaders or do I use my own? Which one is faster?”. Since most built-in stuff is gone, the answer is clear now
There are some downsides, though. Currently, there is no measurable performance improvement between the core-profile and the compatibility profile. But there’s hope, that one day, the drivers will make a distinction and reward my efforts
I used immediate mode for drawing debugging stuff. I needed to implement a small “Immediate Mode Emulation” for that purpose now. Since all matrix-stack stuff is gone, I needed to implement it by myself, using UBOs. Once done, I don’t miss it anymore.
What I really miss a bit is glPushAttrib/glPopAttrib… I used it often to temporarily change state and then restore it when done. I have now resorted to some kind of “fixed default state”. I just assume some “default state” that must be set is always set this way. Whenever I need to desert from this state, I restore it by hand afterwards.
I really wonder how “foreign” OpenGL code can work together with my code, because I now have to do many assumptions on how state is set, how matrices are transported into my shaders and the like…
On the professional side, things are a bit different. The by far biggest problem is that for GL3.2 you need to assume most recent drivers. And that can be a real pain. Customers are often reluctant to change their (certified) drivers. So you often have to deal with 2-years old drivers So GL3.2 is a no go yet… maybe in 5 years. If I only could tell them, that our software would run 2x times faster with GL3.2 they probably would get interested, though…
I really wonder how “foreign” OpenGL code can work together with my code, because I now have to do many assumptions on how state is set, how matrices are transported into my shaders and the like…
That’s my main beef with this bind-to-edit model. 3rd party code wreaks havoc to your assumptions and results in an interoperability nightmare.
The only sane solution is to code defensively, assume that state is always thrashed and take the resulting speed hit. Or you can bite the bullet, fall back to the compatibility profile and use Push/PopAttribs liberally (and take that speed hit, which is generally less).
There’s nothing we can do about the drivers however… my solution is to fall back to 2.1 if WGL/GLX_create_context_attribs fails, query for the necessary extensions and bail out with a “update your drivers” message if they are not supported. Hopefully the situation will become better in the future. Not holding my breath, though.
It depends if you are using glBegin/glEnd, if you are using fixed function sometime, if you are using built in stuff with your shaders.
If you are not, then converting is easy.
Sure, do it if it is for learning purposes.
I see. So there is no real performance benefit yet. Since I do almost everything with shaders the only question is how much better a well written 1.5(afaik) shader would perform than a well written 1.2. (By well written I mean complex, one that would need all the resources).
From your post I presume the difference is not that big. I understand perfectly about the driver and compatibility issues. Luckily these do not concern me, I can afford to support only nvidia (my choice) and the latest drivers. Still it seems to me that I should not rush to switch from opengl 2.1/1.2.
it’s not just reluctance - laptop drivers are a nightmare. I have a customer with a dell laptop who is unable to upgrade from 175.97 because nvidia screwed up the external monitor handling code (it remains screwed in all subsequent driver versions…go figure). He does a lot of presentations, and it’s totally impractical for him to not be able to pipe the display to an external device. I have no answer for this guy, I simply have to maintain a legacy code path for people like him. Laptops are becoming the main computer amongst our customers (desktop replacements), yet the drivers still seem to be a black art for people like nvidia.
#&*%^@! laptops. People who use laptops should probably be ferried off to some far away magical island where they can dance with the bears and make little origami figurines.
well you say that, but I’m using my laptop as a desktop replacement now. It renders faster than my desktop. The mobile gpu’s are now just as capable. It’s just such a shame that the IHV’s don’t address these driver problems. They just seem to sweep them under the carpet and blame the laptop manufacturer. Granted, the manufacturers should be shouldering 50% of the blame too, but none of that is any help to the customer. I certainly wouldn’t recommend nvidia mobile GPU’s to our customers, if it wasn’t for the fact that AMD’s OpenGL implementation is so lousy.
‘Just as capable’ is a huge exaggeration but I agree that they are better than ever before. However, until someone makes a card with SDI output (fill&key) that I can put in a laptop, I simply cannot use them. Although I would love to because I have to carry my PC a lot.
huge exaggeration? I have one of these… http://www.nvidia.com/object/product_quadro_fx_3800_m_us.html
probably outperforms whatever you’ve currently got in your desktop. I say probably, because I suppose it is remotely possible you’ve paid out for a quadro 4800 or, even less likely, 5800.
I have a ‘lowly’ gtx 285. In what respect do you think yours would outperform mine? The specs certainly would not suggest it, and I am not quite certain about the benefits of a quadro over a geforce. AFAIK the chips are the same (the quadro 4800 and 5800 are based on the same chip as mine).
So GL3.2 is a no go yet… maybe in 5 years. If I only could tell them, that our software would run 2x times faster with GL3.2 they probably would get interested, though…