Archived

This topic is now archived and is closed to further replies.

is texture bound?

This topic is 5128 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Best way is to simply keep track of it yourself. I have glBindTexture wrapped up in a function of my own that has a static variable to keep track of this. I pass in the handle to the texture and the texture unit I want to bind the texture to. The static variable is an array of integers, each element representing a texture unit and the value of the element being the texture that''s been bound to it. My function first checks the array to see if the texture unit in question already has the given texture bound to it. If it has, then it exits the function. If it hasn''t, then it assigns that texture handle to that element in the array and bind the texture with glBindTexture.

Share this post


Link to post
Share on other sites
Even if their was such a function it''d be silly to call it everytime you need to use a texture because that in itself would be quite costly. Like he said, keep track of it yourself. Most people sort their polygon rendering by texture/material. This helps keep render times to a minumum.

Share this post


Link to post
Share on other sites
shane do you think its costly to check everything to avoid error within opengl?

im writing a wrapper, and so far, it makes sure opengl will never error out. For instance, when you call gl->ClipPlane, its going to check if the plane you passed in is actually enabled. Is that too much overhead in the long run? so far ive done it with every function. The one thing i know that i do have right, is a variable that tracks glBegin and glEnd. A lot of functions opengl dont work between begin and end, so i have a boolean variable that i check for those functions, before actually calling it.

Share this post


Link to post
Share on other sites
Querying server-side state takes up AGP bandwidth that could better be used for other purposes. It may not matter for small scale programs or scenes, but the more complex your program or scene gets, the more server-side state you might end up querying. It''s a good practice in general to keep track of everything client-side.

Share this post


Link to post
Share on other sites
quote:
Original post by Ostsol
Querying server-side state takes up AGP bandwidth that could better be used for other purposes. It may not matter for small scale programs or scenes, but the more complex your program or scene gets, the more server-side state you might end up querying. It's a good practice in general to keep track of everything client-side.


thats what i've done

i now prevent any chance of rundundant state changes

i also went a step further, and i prevent null pointers, negative values (where applicable), and other things from entering opengl

[edited by - fireking on November 30, 2003 8:19:24 PM]

Share this post


Link to post
Share on other sites
fwiw, as a slight variation on this theme - i like using recursive sentries in my engine for this type of thing ( glBegin/glEnd, glPushAttrib/glPopAttrib, glPushMatrix/glPopPopMatrix, wglMakeCurrent, etc ). in the ctor is the push, in the dtor the pop, sometimes a static count variable to skip the gl call when redundant - everything managed by scoping. i like the pattern because i don''t have to worry about the bookkeeping which for me, can make my brain hurt where i''m managing multiple contexts in a windowed app.

of course some may not like the trade offs. but adding to the stack pointer is cheap, i/o is expensive and debugging state can be a royal pain.

sorry if slightly off topic...

Share this post


Link to post
Share on other sites
I simply keep track of a few states with some flag members and i use them to prevent errors. You could even use this method to keep track of which texture is currently bound. It SHOULD be faster, and the space used for it is trivial.

Share this post


Link to post
Share on other sites
It can be signifanctly faster depending on your scene. I have a scene of ~10,000 polygons with 10 textures. When I sorted the polygons by texture so that I only have 10 calls to glBindTexture(), my fps went from 80 -> 300+

Share this post


Link to post
Share on other sites
yes, i believe bind texture is the most expensive call within the opengl list of functions (at least, at a per vertex/object level). There are probably other operations that take some time, but they aren''t used to render you''re scene, more like utility functions used at start up.

I wonder if i should throw my wrapper class away, because I still have a lot of functions to do, and I really dont want to do the work if its not very necessary. I was wanting to build the wrapper as a layer for my engine to sit on, but maybe the engine should just sit on opengl, and be designed to avoid redundant state changes.... but im not exactley sure how to do that yet, im still weeding through all this very slowly

Share this post


Link to post
Share on other sites
quote:
Original post by shadow_bobble
It can be signifanctly faster depending on your scene. I have a scene of ~10,000 polygons with 10 textures. When I sorted the polygons by texture so that I only have 10 calls to glBindTexture(), my fps went from 80 -> 300+



btw, how exactley did you sort by texture? im still unclear on this idea..

Share this post


Link to post
Share on other sites