Missing GLU constants?

OpenGL Development JOGL Development
#1

Dear all,

I’m working on a program involving NURBS, and I notice that there seem to be lots of constants that are referred to in general glu literature, that are not defined in GLU.java of JOGL. In particular, many of those relating to gluNurbsProperty, such as GLU_SAMPLING_TOLERANCE. Is this because the underlying implementation relating to these constants is still incomplete? I’ve tried manually inputting some arbitrary constants from a copy of glu.h I have lying around, and don’t appear to be getting the results I’d expect, but this could be due to some other lapse in my understanding; I haven’t tried equivalent code outside JOGL.

Cheers,
Peter

#2

The glu nurbs port is not totally finished.
See: http://www.java-gaming.org/index.php/topic,16839.0.html

I use it for some time and the quality is good. I didn’t experienced any bug. Howe’ver, it’s much slower than the original implementation especially for surfaces.

#3

Thanks,

I noticed the presence of a nurbs surface ap in jogl-demos, so I thought that seemed to indicate that it was well enough developed to be usable; which indeed does seem to be the case. As for performance, JOGL gluNurbs seems to offer a major advance over what I had before, so that is something. I think it’s fast enough for me now, although I might consider porting the application to native code at some point if it’s likely to offer significant performance benefits.

Is it safe to assume that missing constants correspond fairly directly to missing functionality?

#4

Does it use immediate mode?

#5

I’m not sure how the actual rendering is handled with gl evaluators and higher level glu functions, but it seems that allowing the hardware to compute the geometry with gluNurbsSurface has a big performance advantage over the jgeom library used previously; regardless of the method used to render the vertices thus computed. The rendering used to be quite a small portion of the cost, enough so that using immediate mode was really not a bottleneck according to my crude measurements.

So even if glu is using immediate mode (and I see no reason it should), I’m not too concerned as for now it seems to give me access to some processing which greatly improves the efficacy of the overall program.

#6

Ok but immediate mode is not available on JOGL-ES and it will be removed from OpenGL in the next release (maybe in some years). Then, we will have to find a solution to get the vertices and put them into something else (VBO?) to render them in the future.

#7

Ah, I see where you’re coming from. Well, I hope we can trust evaluators and associated higher level glu functions not to become deprecated even if immediate mode vertex calls etc do. If necessary, reworking glu to use VBO, vertex arrays or whatever should be relatively straightforward for the people responsible.

However, I’m beginning to wonder how much of my observed performance benefits were due to rather loose default sampling tolerance; I just tried one of my more complex models (an interpretation of the protein “5pti”, not that I understand much about biology) and realised that it’s really not as smooth as before…

So, I would really like to be able to set gluNurbsProperties with some of these missing constants, but I guess I will have to accept that the implementation is not complete; perhaps I could try to look into what’s required, but it’s not really practical for me to work on improving that myself now.

#8

I’ve just read that evaluators are not supported in OpenGL-ES.

#9

I also finally got around to looking at the source of GLU.gluNurbsProperty and found not only

// TODO glunurbsproperty

in the method body, but also


  /**
   * Sets a property on a NURBS object. (NOTE: this function is not currently implemented.)
   * ...
   */

the latter of which I really should have noticed before. ::slight_smile:

So the answer to my original question seems to be (surprise surprise) that there is indeed a fairly direct correspondence between missing features, and missing constant definitions.

I wonder how much work is required on this. I fear it would be unwise for me to attempt it just now; I’m quite busy. I understand of course that for most people, this is far from being a core feature.

Cheers,
Peter

ps. is there a JOGL roadmap anywhere?

#10

I think that it will be hard to implement missing features except if some of us contribute.

#11

Okaay… well I’m quite serious that I would be interested in contributing and also quite serious that it would irresponsible for me to commit to anything right now, given that I have a masters that needs finishing soon and other work that has been somewhat neglected also needing some serious concentration over the next month…

To be honest, I don’t know how deep it’s necessary to delve in order to implement this. I guess it’s probably a relatively small job. If I do get curious and manage to achieve something useful, I’ll be sure to feed it back into the project if it’s wanted. However, it seems like there are other people who already deeply understand the internals and could probably do the work both better and more efficiently. As I say, I really don’t know if it’s a big job or not; maybe not, in which case I might manage something.

#12

I noticed a remark in https://jogl.dev.java.net/nonav/source/browse/checkout/jogl/doc/userguide/index.html?rev=HEAD&content-type=text/html that you can specify -Djogl.glu.nojava system property and it should use the C implementation of GLU (which it says may have some problems) rather than the java one. Well, I tried and it didn’t seem to change anything, perhaps because I’m on windows and don’t have glu 1.3? Not sure exactly what having glu 1.3 even means…