How do i explain this? I''m using geospheres to represent planets in a space sim. Starting with a basic Octahedron, and recursively tessellating each triangle I get the following results :- 1 tess = 32 triangles (very blocky) 2 = 128 (blocky) 3 = 512 (reasonable sphere if not too close) 4 = 2048 (pretty good sphere) 5 = 8192 (excellent sphere) 6 = 32768 (good enough to fly right next to without seeing any angles at all) Now, that''s a lot of triangles at the sixth level ... but the idea is to increase the tess level depending upon the angular size of the planet (in eye coordinates). That is easy enough. But even with culling, an unnecessary number of polys will be sent to the card each frame. So i decided to divide each sphere into 8 quadrants/sectors (in reality just tessellate 1 triangle from the original octahedron) and treat each one as a seperate entity. The reason being the at most only 4 sectors (or half the sphere) will be visible at any given time from a certain viewpoint. Also, with the sixth tessellation level, it''s possible that only 1 sector will be visible, because you''d have to be extremely close before that level would be rendered. Of course the worst case scenario would be if you looked directly at the poles, in which case you could still see 4 sectors. Now to the question ... how would i go about calculating which sectors are visible from eye coordinates? I realise that the normal of a face of an octahedron could be used to determine the direction of the entire tessellated sector, but how do I then calculate whether or not that face would be visible? (bearing in mind that many rotations and transformations would have already taken place before placing the planet in a given location) I hope that makes sense! Many Regards!

Maybe you should look at a patch scheme to model your planets. I haven''t worked with them in openGL yet, so maybe there''s a fundamental problem (like no hardware accelleration).

An alternative method would be to have a hemisphere that always aims at the camera. You''d need to procedurally generate your textures to mimic the natural rotations that would come into play. But drawing a hemisphere in this way would greatly simplify your calculations, I would think. You could set up a subdivision scheme to recursively subdivide based on screen coverage, or not draw if it was off screen.

Just a couple thoughts...

It wouldn''t be possible to implement revised texture coordinates per frame with a rotating planetary body, unless 2 fps is exceptable! the calculations would be too prohibative! And patches are irrellevant int this case! All i''m talking about is which vertices to send to the card!

All i want to know, is how to calculate whether or not a certain sector is visible form the eye view point!

This can''t be that hard to do surely!!!! i just can''t get my head around it! lol

Someone must have done something similar!

Regards

If you use tglTexGen (or whatever it''s called) to generate your texture coordinates, then it should be pretty fast. Clearly if you calculated them on your own, you''d not get very far. I wouldn''t be surprised to find the texture generation to be a trivial operation, but I dunno for sure.

In your current method, a faciness check would be as follows: You''d need to get your normals into the camera space (this is the hard part, but it''s not that hard if you grab the matrices with glGetFloatv), then calculate the dot product of the normal of the quadrant and the eye vector. It''s sign will tell you if it''s back facing or not, I believe. (I think you can even just check the z coord of your normal, but I''m not sure that''s Kosher for a perspective camera).

You could check your coordinates of each remaining quadrant to see if they''re off screen by multiplying each point into screen space (if you did it with the normals, this should be pretty easy).

If you''re looking for the specifics of the math involved for getting into camera space, I''m sure it''s available online. You should be just one vector multiply away if you grab the matrices from openGL.