Texturing n sided cone approximation

[Kanoisa]

Hi all,

Im wokring through NEHE's tutorials at the moment and building a cone approximation class to play with the code and learn from the examples but iv reached a snag.

I cant get texturing the top curved part of the cone to work (i have called it a pyramid but its a cone approximation), it comes out all messed up and i have tried a few things i have hand calculated the coords on paper and it should work. But as im writing this it does not and so i dont understand why not. so if any of the opengl programmers could look at my code (to big to post so i attach the project)

I want the texture to look like it was drawn on say a piece of cloth draped over the cones shape, not just stretched round its circumfrence.

The work calculating the coordinated for the 2d texture and rendering the cone are all done in the class'es methods InitGeo(...) which does all the calculating and Render() which again as the name implies renders the shape. Its part of his lesson 6 and im using the texture he used and the same code to load it etc.

Also it was only meant to be one struct but i ended up with three of them, they are defined in rgbaColor.h

Many thanks in advance.

[mike_2000_17]

In your InitGeo function, you call sinf(theta) several times and theta IS IN DEGREES! That's your problem. use the angle variable instead. In the future, it might be a good idea to get used to using only radians for everything, degrees are meaningless and useless most of the time.

The rest looks fine to me.

[Kanoisa]

Hi mike,

It took me some fiddling to get the angle in radians to match what i needed to get 0->1 as a result from sin and 1->0 in the other bit but once i got that figured out (good ole quick console app to figure it out) it works perfectly.

Thanks allot for the help (i didnt know sin only took radians untill you mentioned it so i appreciate that point)

So yeah its perfect what i wanted now again thanks allot, it was a real head scratcher as im not very used to working with radians.

Just as an off point about my cone class so far, i think its not a bad job, whats your opinion? Anything you would suggest/criticise? or is it ok for a beginners first shape class?

[mike_2000_17]

>>Just as an off point about my cone class so far, i think its not a bad job, whats your opinion? Anything you would suggest/criticise? or is it ok for a beginners first shape class?

Well, for a first shape class it's very nicely done! Of course.. on a more advanced level there are quite a few things that could be improved: (and I put them in order of priority, given the level you are at now, you should probably not worry about the last two points)

First, you probably want to have a base class or just an interface like "renderable" or "visible_object" interface for a virtual render() method. This way you can use polymorphism to store a list of visible objects or shapes of any kind, and render the entire "world" by traversing that list.

In a best practices' perspective, this cPyramid class is a very good candidate to use RAII (Resource Allocation Is Initialization). This means that in this case you don't really need InitGeo(), InitColor() and SetTexture(), because the first two will be more easily done together and the third one is trivial. Thus, you can put all their implementations together in a parametrized constructor for cPyramid and don't provide set/get methods. This way, when you create a new cPyramid, you define permanently how it is (width, colour, texture, etc.) and if you need to change it, you delete it and create a new one. That's the essence of RAII in the sense that you don't have to bother making functions to reinitialize the object after it was constructed because it is just as easy to create a new one.

In the Render() function, for this kind of thing, it is much better to use a VertexBuffer, but if you are at NEHE 6, that's a bit further down the line. Using a vertexbuffer will essentially reduce the size of this function to about 3 lines (3 OpenGL function calls, i.e. BindTexutre(), glDrawElements(), glDrawElements() and that's it).

Finally, for independence and code-reuse, I would suggest you have a class that renders a vertexbuffer (or list of points with position, texcoords, colour, normal, etc. and some identifier like GL_TRIANGLE_FAN, GL_TRIANGLES, GL_QUAD_STRIP, etc.) and a means to render them (glBegin() .. glEnd() or glDrawElements() or glCallLists(), and fixed-functionality or pixel-shaders). This way all your "shape" classes need to do is initialize the list of points or vertices and associate the right texture. The point is that if you are going to implement many different shapes, you don't want to rewrite the glBegin() .. glEnd() piece every time because it's always the same, only how you generate the points is different, so that's the only code you should need to create new. And the same goes for the textures, I know now you are only beginning to use a few simple textures, but when the number of textures increase there are a lot of issues to handle and you typically need a singleton to manage texture swaps and texture objects loaded on the graphics card.