Can a call to gluNurbsSurface be put inside a display list? I ask because of the GLUnurbsObj that is passed into it. All of the examples in the Red Book make use of a global object created at the begining of the program in an init() function. They never delete the object. I might want to change the values in the GLUnurbsObj per surface (maybe GLU_FILL one and GLU_OUTLINE_POLYGON for another).
I guess another way of looking at this question is, do all the values in the GLUnurbsObj get copied out when the call is made or is the pointer copied?
My suspicion is that the pointer is copied. In the past I have always needed a seperate GLUnurbsObj per surface, and that isnt possible in my current project (thousands and thousands of patches). Or, I have used a single GLUnurbsObj for all surfaces, but was forced to have all surfaces have the same properties.
What is the deal with the GLUnurbsObj?
thanks.
I’ve never been able to place a call to gluNurbsSurface in a display list, the surface itself never display’s correctly.
When i use the glu nurbs stuff, I always use seperate GLUnurbsObj’s for surfaces that need to be rendered differently. If thats not very useful, have you thought about creating only a few GLUnurbsObj’s with the parameters for each style of rendering you may want? ie, have two, one for wireframe one for filled, when drawing use either one or the other when calling gluNurbsSurface() ?
[This message has been edited by Rob The Bloke (edited 04-14-2001).]
I have considered the “minimal set” of nurbsObj approach you mention. But the display list thing is still a hitch in the giddy-up.
I have managed to put a surface in a display list, but to do it I had to have the nurbsObj be a member of the Surface class that doesn’t get deleted. I even manage to capture trimming information within the list. However, texture mapping doesn’t seem to want to cooperate. Maybe it is the second call to gluNurbsSurface that corrupts things.
Any other thoughts? Does anyone actually use this or does everyone try to break their patches into Beziers by hand?
[This message has been edited by tvthompsonii (edited 04-16-2001).]
Any other thoughts? Does anyone actually use this or does everyone try to break their patches into Beziers by hand?
I have to say, I’m starting to look for other approaches. GLUnurbs is a fairly nice interface, but it’s starting to get on my nerves somewhat. Texturing issue’s are probably my major gripe, followed by the slowness of it all. I’ve started putting together some code to do beziers, and the speed of the surfaces is very nice, plus I pre-empt the lod, and arrange some classes to catch all the data and arrange it into nice vertex arrays. For me variable tessalation lod’s aren’t an issue, Im trying to animate whole models, so I’ve started setting up all arrays required beforehand + all of the indices required for the vertex arrays. This way all I do is move CV’s, calculate vertices & normals (uv’s remain constant) and then use the vertex arrays to draw it. So far it seems to be a lot quicker than doing the equivalent with evaluators. I’ll let you know when I get nurbs working…