lets say I want to render a texture mapped sphere that is rotating, an image of a rotating planet for example.
Which way is faster ?
a) Rotate the texture mapped sphere.
b) use TexCoord to change where the texture gets mapped and give the impression that the sphere is rotating.
For the 3D pros, same question as above, but with a bumpmapped sphere
Gracias
Even if it should be faster to rotate the texture, then i still think it’s better to rotate the entire sphere. Rotating the texture would just be weird and more complicated.
it maybe weird to program, but would it look graphically weird?
and even if it is weird to program, is it faster?
what do you think?
Well, dunno, but what about giving it a try and benchmark it?
I would think the fastest way would be to create a display list of the sphere(and texture) and then adjust the rotation with glRotate() before the call to render the display list of the sphere. This should be way faster than regenerating the sphere each time and either rotating the sphere or modifying the texture coordinates.
Unless your sphere has LOTS of faces, and I
mean LOTS, making each face about one to two
pixels in size, rotating the texture will
look weird.
Besides, I can’t see how there would be any
performance difference for GL; it still
applies the modelview matrix to the vertexes
no matter whether you rotate the globe or
not.
Last, updating the texture coordinates takes
writes to memory, whereas just rotating
something which can live in a display list
or vertex buffer takes no memory access. Thus
rotating the whole thing will probably be
faster on HT&L hardware, and will not be any
slower on rasterizing-only hardware.
Thanks bgl,I seem to agree with your viewpoint. We actually tried it with 1000 spheres (all in view) on a TNT2, not much difference but rotating the sphere was better. The more polys made up the sphere the closer both methods where in performance, at one point modifying the texture got faster (we never changed the texture size 256x256). As bgl said the difference between the 2 methods was visually apparent when a face took up 4 or less pixels, at which point it seemed to visually lag.
I didn’t do the actual coding but I will look it over (perhaps modify it) and maybe place a demo on a site if anyone is interested (not that it is hard to do). The debate started when we were finding ways to make a simulation of a planet faster. So if anyone has any ideas lemme know.
Later,