vincoof : heheh... just stunned by the code... I guess when you become an expert in OpenGL, code like this is easy to come up with.
BTW, I''m dying trying to figure out a problem with a Bezier curve program I created... mind checking it out... it''s under a post I made a couple of days ago.
Thanks.
-----------------------------
"Q: How many Microsoft engineers does it take to change a light bulb?
A: None. Bill Gates will just redefine Darkness(TM) as the new industry standard. "
~wUn LoVe tO aLl ThE mAlUs OuT tHeRe!~
Torus coordinates
Here is a link for the math behind the torus.
http://astronomy.swin.edu.au/~pbourke/modelling/torus/
http://astronomy.swin.edu.au/~pbourke/modelling/torus/
Shannara: That link is awesome. Thank you for posting it !
''center'' (in this topic) represents ''r0'' (in the link), and ''radius'' represents ''r1''.
mAdMaLuDaWg:
thank you. but that''s not the work of an expert.
I wrote that when I was a student, and since it is a pretty good algorithm I kept it.
what does make you stunned ?
the ability to play with math functions (such as sin and cos) to serve _the_ 3D ?
the lisibility of the code ?
the possibility to use one triangle strip only (instead of multiple quadstrips) ?
''center'' (in this topic) represents ''r0'' (in the link), and ''radius'' represents ''r1''.
mAdMaLuDaWg:
thank you. but that''s not the work of an expert.
I wrote that when I was a student, and since it is a pretty good algorithm I kept it.
what does make you stunned ?
the ability to play with math functions (such as sin and cos) to serve _the_ 3D ?
the lisibility of the code ?
the possibility to use one triangle strip only (instead of multiple quadstrips) ?
He thnx for the link 
I''m going to check it out.
And about the code.
Well the way you use the ''math functions (such as sin and cos) to serve _the_ 3D'' make me stunned
But I shall search on google if I can find a good explanation about the sin and cos functions
I''m going to check it out.And about the code.
Well the way you use the ''math functions (such as sin and cos) to serve _the_ 3D'' make me stunned
But I shall search on google if I can find a good explanation about the sin and cos functions
vincoof : I was refereing to math calculation. Those sin/cos are a BIG hit (specialy if you use original functions) and NEVER use (float)i conversion when performance matters.
from your code:
theta / (2 * M_PI)
calculte someVal = 0.5f / M_PI; onece then use theta * someVal;
...
There are more worlds than the one that you hold in your hand...
from your code:
theta / (2 * M_PI)
calculte someVal = 0.5f / M_PI; onece then use theta * someVal;
...
There are more worlds than the one that you hold in your hand...
Ok I see the optimizations you''re talking about.
I know I could win a lot.
But I don''t really care about that because the model is compiled in the display list. So, only the list compilation is slow. The list call is not slower, which is the most important.
I prefer keeping the code lisible, so I can modify it more easily if I need to.
Anyway, if the torus had to be drawn without display lists, I agree that some optimizations would be welcomed. But I assume that display lists are available.
I know I could win a lot.
But I don''t really care about that because the model is compiled in the display list. So, only the list compilation is slow. The list call is not slower, which is the most important.
I prefer keeping the code lisible, so I can modify it more easily if I need to.
Anyway, if the torus had to be drawn without display lists, I agree that some optimizations would be welcomed. But I assume that display lists are available.
good point.. with display list this realy doesn''t matter. But I dont use them becouse I need to change details while running (and compiling lists at frame to frame basis is a big no-no)
There are more worlds than the one that you hold in your hand...
There are more worlds than the one that you hold in your hand...
eh eh of course this needs some optims for drawing without display lists, and of course you gotta not use display lists for a dynamic model (unless the rendering fits some particular puposes).
Animated torus, eh ?
You could probably have two vertex arrays and then just morph between the two.
This way you''d *just* need to initialize the ''start'' and ''end'' vertex arrays, and rendering would *just* need an interpolation (which can be done very fast). Such a method could use ''slow'' initializations like I did above, because they''re just inits.
Animated torus, eh ?
You could probably have two vertex arrays and then just morph between the two.
This way you''d *just* need to initialize the ''start'' and ''end'' vertex arrays, and rendering would *just* need an interpolation (which can be done very fast). Such a method could use ''slow'' initializations like I did above, because they''re just inits.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
