Difficult choice between Vincent and Klimt

Hallo everybody,

I am new in Opengl and in Opengl ES. I am working on a project: porting the very famous open source 3d suite Blender (www.blender3d.org) on PDA. Blender uses massively Opengl!
I need some advise to know which implementation should I use. This choice will really determine the future of this project!

I look on Internet and find lot of very interesting information. Today I don’t know what is the best solution:

  1. Choose Klimt, with glBegin/glEnd, working on Windows (to ease development task) but without really lot of documentation and without lot of support. If I make this choice, I will have to go deeply in the source to understand how it work because I didn’t find lot of information on the web.
  2. Choose Opengl ES Vincent. I see that this implementation is younger as Klimt, in line with Opengl ES, but without glbegin/glend. But I will probably easily find more support, red book examples, this implementation is dynamic, I will be able to take advantage of its improvement (ex: integration of PocketHAL… not working with klimt).

I have the feeling that Vincent will be more efficient, that I will be able to find answers to my questions with Vincent (I already find lot of tutorials! Not for Klimt) but I am really afraid with this story of glbegin/glend. If I choose Vincent, will I have to convert ALL glbegin/glend? I don’t see a end of such a work for a so big application!

What do you think about it? And for the performance, what is the best choice?

Thank you for your help!
I hope I will be able to offer the community this wonderful software on PDA… I can dream :=)

Thanks a lot,

I think porting to OpenGL ES proper will pay off even more if you consider going to a hardware implementation (eg Dell Axim x50v).

I have never looked at the blender code, but if it’s not totally hacked together, then the rendering calls should be organized nicely together.

If you search for “glBegin”, how many hits do you get?

Also, there are conversion layers such as DOGLESS
that could get you started more quickly. Actually, even Daniel (the original author of Klimt) has moved on to working on such a conversion library. I do not know, however, if he ever decided to make it public.

  • HM

Hallo Hans Martin,

Thanks for your reply.
First, I will not make an hardware implementation (even if I don’t really understand what that means :=). My aim is to work the open source to have Blender as portable as possible. This is the philosophy of this software. And if I make an hardware implementation, very few people will be able to use it…

The blender code is nicely organised. If I search glbegin in the source, I find more than 350 calls! Yesterday, I had a look what is this glbegin and how to convert it with glDrawElements. It will be impossible for me to convert everythink! I also made a comparison between Vincent and Klimt… Klimt support more opengl function… really more.
So my choice is done for klimt! But I suffer the lack of documentation. And it seems that klimt is not maintained any more :=( Even the documentation provided is difficult for me. But there are good examples… I hope I will understand how klimt works with these examples.

Concerning DOGLESS, I had a look on that a few month ago (when I was beginning to think about porting Blender)… But Dogless is written for Windows, not for PDA… so to use Dogless, I will have to port it for PDA… What do you think about it? To be honest I didn’t really understand how to use it… I put opengl and opengl es on my pda… with Dogless… and Dogless will use these two libraries to make an opengl implementation work on PDA?? Really? It seems to easy :=)

Daniel is working on such a library,cool :=) Maybe he will be able to advise me about the best approach…

Do you know where I can find more information about these “conversion layers such as DOGLESS”? How to use them?

Thank you for your help,

Hardware implementation = In implementation of the OpenGL ES API that is implemented using an actual GPU (graphics hardware). The Axim is one of the first Pocket PCs that has a GPU. So my point is that you should consider if you want to tie yourself to features of a specific software software renderer, or (even considering 1 year timeframe) would want to gain more from targeting the general API, which will be included in more and more of the devices.

If your timeframe requires a different approach, however, use whatever fulfills your needs.

  • HM

PS: As for the conversion libraries: Drop an email to Daniel…

[ May 26, 2005: Message edited by: Hans-Martin Will ]

Thank you for your help!

I contacted Daniel :=)

Thanks again!


If you write code for Vincent, then the very same code can be used to run the program with hardware acceleration. I would not recommend to use libraries which are no longer maintained.

It is possible to implement glBegin and glEnd on top of OpenGL ES. It might even be worth the trouble in this kind of cases. Briefly: you would have one reusable vertex buffer, having enough room for all used vertex attributes for at least a hundred or so primitives. glBegin() would note the primitive type, glVertex(), glNormal() etc would write into the vertex buffer (and glVertex() advancing to next vertex), and glEnd() would trigger drawing the vertex buffer. Knowing and taking advantage of vertex buffer objects is recommended, too. I have not tried it myself. I would consider this kind of solution a hack, but it might work for you.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.