View Full Version : GL_FLOAT, GL_INT or GL_SHORT: that is the question
08-12-2002, 05:59 PM
When using vertex and normal arrays, which of those data types are the fastest. I seem to recall floats being on the fastest supported types. Is that still true today?
08-12-2002, 09:21 PM
floats are the format that needs no conversion for the gpu.
the others need
the others are sometimes smaller => less bandwith..
bench it http://www.opengl.org/discussion_boards/ubb/smile.gif
08-13-2002, 03:01 AM
Bench tests take up valuable time away from the development of Spider3D. It's faster to ask http://www.opengl.org/discussion_boards/ubb/smile.gif.
Hmmmmm, now I'm torn.
Thanks for your reply dave.
08-13-2002, 06:01 AM
This can be hardware depended, but for the most part, float for vertex and normal.
color : float or ubyte (3 or 4)
tex coord : float
indices : short
glReadPixels, glDrawPixels and textures: uchar (RGBA)
The one I'm concerned about is color. It is likely to change. Perhaps textures and glDrawPixels glReadPixels will be needed floats soon.
08-13-2002, 09:06 AM
If you're targeting HT&L cards, then the less data you send, the better. However, the GF/GF2 can only unpack float and signed short types, and unsigned byte types only for colors. So I'd suggest:
vertex: signed short
normal: signed short
texcoord: signed short
color: unsigned byte
If you really need the precision in the "vertex" case, send it as float. Also, if you do processing on the CPU, it's likely that both vertex and normal need to get sent as float, to avoid having the CPU do expensive conversion.
Anyway, you're saying that benchmarking takes away time from development of your engine. That's a rather surprising attitude. I'd think that benchmarking and profiling is a rather valuable part of engine development. That's almost (but not quite) like saying "unit tests take away development time" or even "debugging takes away development time". But I guess that's a topic for another forum.
08-13-2002, 11:05 AM
It'd probably take you 30 minutes to write a good benchmarker from scratch for this question.
You should really do some benchmarking automatically at app startup anyway (render-to-texture/subimage speeds, etc.)...maybe this could be included, but I don't think you'd see significant speed differences.
08-13-2002, 12:30 PM
Thanks guys, I appreciate it.
Don't get me wrong about the benchmarking. I should have been a bit more specific. I meant in this case that it would be faster to just ask rather than spend time creating a program for benchmarking the datatypes.
I'm doing CPU calculations on my vertices and normals so I think I'm going to stick with floats. However, I am using 4ub for colors.
Spider3D supports static mesh animation, but it's focus is on skeletal animation, so I don't think I need to worry about any memory contsraints.
Powered by vBulletin® Version 4.2.2 Copyright © 2014 vBulletin Solutions, Inc. All rights reserved.