Quesa or Open GL

Moderator
Posts: 508
Joined: 2002.09
Post: #1
I was thinking. What should be better to learn: Plain Open GL or Quesa? I know Quesa works on Mac OS X and has a QD3D implementation in Open GL, so that's kinda cool since I have the QD3D programming book.

But really, which one is best and easiest?

"When you dream, there are no rules..."
Quote this message in a reply
ededed
Unregistered
 
Post: #2
If you have a book you should do the tutorials in that but overall (I dont know quesa). Pure OpenGL is probably best.

try out space goon from my site. It is made with pure OpenGL:
http://www.geocities.com/ed72678954/index.html
Quote this message in a reply
Member
Posts: 57
Joined: 2002.04
Post: #3
QD3D is, as far as Apple is concerned, a dead API, so you'd likely be much better off learning OpenGL. I'd only recommend Quesa if you already know QD3D or are working with QD3D code; since it's built on top of OpenGL there's probably some overhead associated with it, and it won't gain new features nearly as quickly as OpenGL, if at all. I don't have any practical experience with either, so I can't really say which is easier, but there's an incredible amount of documentation, sample code, and tutorials for OpenGL and virtually none for QD3D, so OGL probably wins on ease of use as well.
Quote this message in a reply
Moderator
Posts: 365
Joined: 2002.04
Post: #4
I did a whole load of stuff in QD3D a few years ago, and once you get used to the quasi-object-oriented API it's quite nice and fairly easy to use. It does a lot of fundamental stuff for you that you'd be forced to write yourself with OpenGL. There's also a handy built in maths library.

I still reckon that QD3D/Quesa is useful for prototyping ideas and as a way of gaining experience with 3D graphics (it worked well for me). However, learning OpenGL will do you more good in the long run because it's better supported, more flexible, and more likely to be speedy when used for games. All my recent stuff uses OpenGL.

Neil Carter
Nether - Mac games and comic art
Quote this message in a reply
Feanor
Unregistered
 
Post: #5
I have some experience with the development of Quesa, being one of the few people keeping up with it from a Cocoa standpoint. I just built it again yesterday. It has issues, the two most prominent being for me that there are some difficulties with using it with Project Builder, and that it is very slow. They haven't done any optimizations yet.

I did some profiling of their test apps, and there is a lot of redundancy in the state change calls. Some times glColor3f() gets called for every single vertex being submitted to OpenGL. Large models made of smaller ones aren't merged, so each component is submitted to OpenGL individually, meaning dozens of calls to glDrawElements instead of one. It may be that it is up to the developer to identify such opportunities to optimize, but I don't know. Unfortunately I haven't ever had time to dig into the implementation code, so I don't know if the examples I'm testing with are realistic. Using textures instead of vertex colours would perhaps help a lot, but I can't say.

The main feature of Quesa/QD3D is its ability to manage large numbers of objects intuitively. They've done a lot of work for you. But this doesn't cut down on the amount of APIs you have to learn. It's a big library, even learning the basics is significant work. No more or less than OpenGL, but once you know it, you can do more right off the bat.

If you do give it a try, I'd like to hear about your progress.

--FÎanor
Quote this message in a reply
Moderator
Posts: 365
Joined: 2002.04
Post: #6
Quote:Originally posted by Feanor
I did some profiling of their test apps, and there is a lot of redundancy in the state change calls.

The thing with Quesa is that it's a work in progress. They're still working on adding core functionality (such as generic mesh objects and parts of the IO code), so they're concentrating more on making it work than making it optimal. I think it'll become more efficient after a final version is released.

Taxxodium, you might want to check out their mailing list at <http://www.quesa.org/>. There's a lot of discussion about which parts of Quesa are slow and what they plan to do to fix them.

Neil Carter
Nether - Mac games and comic art
Quote this message in a reply
-dair
Unregistered
 
Post: #7
I'm one of the main authors of Quesa, and started the project way back when, so might as well delurk and give my 2 cents at this point... Smile

In terms of which to learn, I'd have to say the answer is probably "both". If you're just looking for a high-level 3D toolkit then you should take a look at Quesa, however you will always benefit (in any field) from being able to know how things work at a lower level.

But one of the the nice things about Quesa is that there's no conflict between using it and OpenGL: if you think of it as just a library of utility code, there's nothing to stop you mixing calls to Quesa with calls to OpenGL while rendering (i.e., Quesa goes straight to OpenGL underneath, so either your code calls OpenGL or Quesa calls it - but OpenGL has no way of knowing/caring who's pushing commands down into it).

Or you could even just use the non-OpenGL portions of Quesa - there's a large math library to do things like quaternions/intersections, as well as basic types/operations on staples like points/vectors/matrices. Plus a plug-in architecture for file I/O, so you can import files into a known data structure like a TriMesh and pull the data out into your own rendering system.


In terms of Quesa's performance, it has always been our goal to get a correct implementation in place first (i.e., one which matches the QD3D API), and then to focus on performance. We're very close to wrapping up the first part, and are now able to start thinking about performance and extensions over and above QD3D (e.g., lightmaps or environment maps - this is a good example of where Quesa can be useful to you as, you won't have to worry about/care if they're implemented using multipass or multitexturing: the plan is you could simply assign one to an object, and the library will try for multitexturing if available or fall back automatically to multipass if not).

However, we are about to make some performance improvements which should be useful - I've just checked in a change to make most of the math routines inlined (so doing something like Q3Vector3D_Dot to calculate a dot product can now be done without a function call), and am about to check in our new TriMesh code (which will always use a single glDrawElements call to draw TriMesh objects - the previous code was quite convoluted, because the QD3D TriMesh is unfortunately quite flexible).


It's all open source (LGPL) - so if you do see a bug/performance problem, sign up for the mailing list and make sure it gets logged into Bugzilla.

Note that the current release on the web site (http://www.quesa.org/) is about a year out of date, and you will need to use CVS (instructions on the web site) to get the latest source: the plan is to package this up into another release fairly soon.

Hope that was useful, if a bit long. Unfortunately we don't really have any docs other than those which existed for QD3D (there's an API reference generated by HeaderDoc, but no "Guide To Programming" book), so people willing and able to write would be welcome... Smile


-dair
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Placing Quesa Objects in an OpenGL Context? lpetrich 2 2,609 Feb 13, 2003 06:53 AM
Last Post: -dair