Hi,
I know the question is pretty generic, but hopefully there's some common cause of this kind of error or something:
Basically the short version is, what can cause a GL stack UNDERflow error???
I have written a simple fragment shader in glsl for blending two texture in different classic blending modes (add, multiply, difference...); I have a few (16) instances of the same shader (an abstraction containing a [glsl_fragment], a [glsl_vertex] and a [glsl_program], the abstraction being repeated 16 times) rendering at the same time. I am using uniform variables to tell each "instance" what texture to use and I use the message [texunit ...( to [pix_texture] objects in order to "name" the textures with some numbers.
Now, I am getting some unexpected results like: the texture being used is not the one I expect, so I am trying to debug my own work since there's certainly some stupid error, but I have realized that the console shows this error message:
GL: subdesbordamiento de pila
which is in spanish and I guess it is a bad translation of "stack underflow". While I can easily think about errors I may make that may produce stack OVERflows, I really can't figure out what the hell I may have done wrong that may cause a stack UNDERflow. I don't know what kind of anomaly to look for.
At the moment I can't attach the patch, however it wouldn't be of great use: I would need to isolate the problem but I don't know where to start from. I attach the fragment shader in case it is of any help though I doubt it.
My hope is that there is something very "typical" to take care of which "usually" cause stack underflows.
For example is it a problem that I sometimes "cut off" a piece of rendering chain in order to not display some objects?? i.e.
[gemhead] | (....) | | | [spigot] | (...)
I do this very often but this is the first time I use shaders. Is there something I should do (e.g. some message to send to the [glsl_program]) when it starts/stops receiving the gemlist????
Any help will be greatly appreciated
Thanks in advance m.
Matteo Sisti Sette a écrit :
Hi,
I know the question is pretty generic, but hopefully there's some common cause of this kind of error or something:
Basically the short version is, what can cause a GL stack UNDERflow error???
you try to get value from the stack when it is empty.
you can have such error when using glPopMatrix without using glPushMatrix...
why do you always send your mail to the pd list AND gem-dev? this 2 lists are for different purpose, and people on Gem-dev are also on pd-list.
c
cyrille henry escribió:
you try to get value from the stack when it is empty.
you can have such error when using glPopMatrix without using glPushMatrix...
First of all thank you for helping.
I never explicitly use these functions, that is, I never use [GEMglPopMatrix] nor [GEMglPushMatrix].
I guess [separator] has something to do with pushing and popping from that matrix, but shouldn't its push and pop operations always automatically "match"? Whay kind of anomaly in a patch can cause a call to a pop without a "matching" push? Do you think it is unrelated to the use of shaders? Btw is that the only stack that can underflow?
Thanks
why do you always send your mail to the pd list AND gem-dev? this 2 lists are for different purpose, and people on Gem-dev are also on pd-list.
Oh sorry about that. Maybe I shouldn't; I'll stop doing that right now. Since there isn't (to my knowledge) a "gem-list", specific to gem but not to developing, I thought I'd send gem-related questions to gem-dev too... You make me realise it is unnecessary and probably inappropriate, if most people in gem-dev are also on pd-list.
Matteo Sisti Sette a écrit :
cyrille henry escribió:
you try to get value from the stack when it is empty.
you can have such error when using glPopMatrix without using glPushMatrix...
First of all thank you for helping.
I never explicitly use these functions, that is, I never use [GEMglPopMatrix] nor [GEMglPushMatrix].
I guess [separator] has something to do with pushing and popping from that matrix, but shouldn't its push and pop operations always automatically "match"?
yes, it should
Whay kind of anomaly in a patch can cause a call to a pop without a "matching" push?
save your patch. simplify it until it did not print this error. You can then find the cause of this inappropriate pop...
Do you think it is unrelated to the use of shaders?
i never saw a shader doing this kind of error. you can easily test this if you remove the shader from the rendering pipe...
c
Btw is that the only stack that can underflow?
Thanks
why do you always send your mail to the pd list AND gem-dev? this 2 lists are for different purpose, and people on Gem-dev are also on pd-list.
Oh sorry about that. Maybe I shouldn't; I'll stop doing that right now. Since there isn't (to my knowledge) a "gem-list", specific to gem but not to developing, I thought I'd send gem-related questions to gem-dev too... You make me realise it is unnecessary and probably inappropriate, if most people in gem-dev are also on pd-list.
By the way is there any trick to "track" a GL error to find the object triggering it? (apart deleting objects until you find the one)
cyrille henry escribió:
Matteo Sisti Sette a écrit :
cyrille henry escribió:
you try to get value from the stack when it is empty.
you can have such error when using glPopMatrix without using glPushMatrix...
First of all thank you for helping.
I never explicitly use these functions, that is, I never use [GEMglPopMatrix] nor [GEMglPushMatrix].
I guess [separator] has something to do with pushing and popping from that matrix, but shouldn't its push and pop operations always automatically "match"?
yes, it should
Whay kind of anomaly in a patch can cause a call to a pop without a "matching" push?
save your patch. simplify it until it did not print this error. You can then find the cause of this inappropriate pop...
Do you think it is unrelated to the use of shaders?
i never saw a shader doing this kind of error. you can easily test this if you remove the shader from the rendering pipe...
c
Btw is that the only stack that can underflow?
Thanks
why do you always send your mail to the pd list AND gem-dev? this 2 lists are for different purpose, and people on Gem-dev are also on pd-list.
Oh sorry about that. Maybe I shouldn't; I'll stop doing that right now. Since there isn't (to my knowledge) a "gem-list", specific to gem but not to developing, I thought I'd send gem-related questions to gem-dev too... You make me realise it is unnecessary and probably inappropriate, if most people in gem-dev are also on pd-list.
On Fri, Jan 1, 2010 at 11:32 AM, Matteo Sisti Sette < matteosistisette@gmail.com> wrote:
By the way is there any trick to "track" a GL error to find the object triggering it? (apart deleting objects until you find the one)
The GL error comes from the driver, and GEM just asks the driver once per rendering pass if any errors occur. Doing this check for each object is typically unnecessary and slows down rendering.
chris clepper escribió:
On Fri, Jan 1, 2010 at 11:32 AM, Matteo Sisti Sette <matteosistisette@gmail.com mailto:matteosistisette@gmail.com> wrote:
By the way is there any trick to "track" a GL error to find the object triggering it? (apart deleting objects until you find the one)The GL error comes from the driver, and GEM just asks the driver once per rendering pass if any errors occur. Doing this check for each object is typically unnecessary and slows down rendering.
Oh I see, thanks a lot for clarifying :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matteo Sisti Sette wrote:
chris clepper escribió:
On Fri, Jan 1, 2010 at 11:32 AM, Matteo Sisti Sette <matteosistisette@gmail.com mailto:matteosistisette@gmail.com> wrote:
By the way is there any trick to "track" a GL error to find the object triggering it? (apart deleting objects until you find the one)The GL error comes from the driver, and GEM just asks the driver once per rendering pass if any errors occur. Doing this check for each object is typically unnecessary and slows down rendering.
Oh I see, thanks a lot for clarifying :)
but you can do it manually by inserting [GEMglReportError] after the objects where you expect a problem to appear. [GEMglReportError] is a wrapper around "glGetError()" (which is available as [GEMglGetError]) which will additionally pint the error-string (in fact, it is what is used each render-cycle) it will also clear the error-flag, so the "other" (automatically generated error-message at the end of each render-cycle) will be suppressed...
fgmasdr IOhannes
IOhannes m zmölnig escribió:
but you can do it manually by inserting [GEMglReportError] after the objects where you expect a problem to appear.
WOW Great!! That will help a lot. Thanks m.
Wow wow wow!!!
It seems my underflow problem (now I was getting both underflows and overflows) is in some way related to the use of texunits AND [gemframebuffer]s.
I still have to understand how exactly the texunit thingie works (the "texunit" message to [pix_texture] is not even documented btw), but I had been able to use texunits in order to assign textures a "texunit" and then refer to these numbers in the shader code to access textures, without problems until I began to use them in addition to gemframebuffers (without suspecting they could interact).
Well now I have just realized that [gemframebuffer] outputs a message like "using texunit N", and I had some messages like this:
[loadbang] | [texunit 0( // or 1 | [pix_texture]
So I guess I was assigning this texture the same texunit that was used by the gemframebuffer; I still have to figure out what it means but I guess it is not good.
Removing the texunit messages, now the stack under/overflows seem to have disappeared.
Thanks again for your help
m.
there is an exemple of how to use multiple texture / textunit in the gem exemple folder, in directory 10.GLSL
Matteo Sisti Sette a écrit :
Wow wow wow!!!
It seems my underflow problem (now I was getting both underflows and overflows) is in some way related to the use of texunits AND [gemframebuffer]s.
I still have to understand how exactly the texunit thingie works (the "texunit" message to [pix_texture] is not even documented btw), but I had been able to use texunits in order to assign textures a "texunit" and then refer to these numbers in the shader code to access textures, without problems until I began to use them in addition to gemframebuffers (without suspecting they could interact).
Well now I have just realized that [gemframebuffer] outputs a message like "using texunit N", and I had some messages like this:
[loadbang] | [texunit 0( // or 1 | [pix_texture]
So I guess I was assigning this texture the same texunit that was used by the gemframebuffer; I still have to figure out what it means but I guess it is not good.
Removing the texunit messages, now the stack under/overflows seem to have disappeared.
Thanks again for your help
m.
cyrille henry escribió:
there is an exemple of how to use multiple texture / textunit in the gem exemple folder, in directory 10.GLSL
You mean 05.multitexture.pd?
Yes I've seen it (it is thanks to that example that I have been able to do something - btw iirc it is yours, so thank you).
But that doesn't show any interaction with [gemframebuffer] nor [pix_snap]. That's where my troubles begin (apparently)
Matteo Sisti Sette a écrit :
cyrille henry escribió:
there is an exemple of how to use multiple texture / textunit in the gem exemple folder, in directory 10.GLSL
You mean 05.multitexture.pd?
Yes I've seen it (it is thanks to that example that I have been able to do something - btw iirc it is yours, so thank you).
But that doesn't show any interaction with [gemframebuffer] nor [pix_snap]. That's where my troubles begin (apparently)
the exemple 06 show how to use gemframebuffer and multiple texture.
exemple 07 is also usefull for you.
c
Thank you for pointing me to the examples, but it definitely seems there is some kind of interaction with [pix_snap]: even if I force [gemframebuffer] to use texunit 0 and my textures to use texunits 1,2,3 and 4, I still get under/overflows as soon as pix_snap takes a snap, and my shader is using a snapped picture (which does not correspond to any other texture) instead of the texture I expect it to use.......
Well I will try to post a simplified patch because this explanation of mine is a mess, but it seems I have to figure out how to avoid pixsnap to mess with textures. It does not accept a texunit message (dunnow if it would make any sense)......
cyrille henry escribió:
Matteo Sisti Sette a écrit :
cyrille henry escribió:
there is an exemple of how to use multiple texture / textunit in the gem exemple folder, in directory 10.GLSL
You mean 05.multitexture.pd?
Yes I've seen it (it is thanks to that example that I have been able to do something - btw iirc it is yours, so thank you).
But that doesn't show any interaction with [gemframebuffer] nor [pix_snap]. That's where my troubles begin (apparently)
the exemple 06 show how to use gemframebuffer and multiple texture.
exemple 07 is also usefull for you.
c
why do you use pix_snap?
you don't need a pix_snap with a frambuffer since you can directly send the content of a framebuffer to a pix_texture (and then using it with multitexture)
c
Matteo Sisti Sette a écrit :
Thank you for pointing me to the examples, but it definitely seems there is some kind of interaction with [pix_snap]: even if I force [gemframebuffer] to use texunit 0 and my textures to use texunits 1,2,3 and 4, I still get under/overflows as soon as pix_snap takes a snap, and my shader is using a snapped picture (which does not correspond to any other texture) instead of the texture I expect it to use.......
Well I will try to post a simplified patch because this explanation of mine is a mess, but it seems I have to figure out how to avoid pixsnap to mess with textures. It does not accept a texunit message (dunnow if it would make any sense)......
cyrille henry escribió:
Matteo Sisti Sette a écrit :
cyrille henry escribió:
there is an exemple of how to use multiple texture / textunit in the gem exemple folder, in directory 10.GLSL
You mean 05.multitexture.pd?
Yes I've seen it (it is thanks to that example that I have been able to do something - btw iirc it is yours, so thank you).
But that doesn't show any interaction with [gemframebuffer] nor [pix_snap]. That's where my troubles begin (apparently)
the exemple 06 show how to use gemframebuffer and multiple texture.
exemple 07 is also usefull for you.
c
cyrille henry escribió:
why do you use pix_snap?
you don't need a pix_snap with a frambuffer since you can directly send the content of a framebuffer to a pix_texture (and then using it with multitexture)
Every once in a while (NOT at every frame) I need to take a snapshot of what you are seing and "print" it into a rectangle which is in the background. I guess I could do that with one more framebuffer without pix_snap but I do need to snap a single frame (i'm not really sure how you would do that); also, I first wrote this patch without any shader and it was pretty simple with the pix_snap. I didn't need shaders until I needed to add the "difference" blending mode...
So is pix_snap a problem in relation to "texunit"s?
pix_snap is probably using texunit 0 which is the default for any texturing call. pix_snap actually uses a function called glReadPixels(), and that might use texture units internally to grab the frame and store it before read back to main memory.
Also, you cannot use any value for the texunit pix_texture uses most GPUs have at least 8 so texunits 0 to 7 are valid. Lots of GPUs have much more than 8 so you have to figure out where they end.
On Fri, Jan 1, 2010 at 1:38 PM, Matteo Sisti Sette < matteosistisette@gmail.com> wrote:
Thank you for pointing me to the examples, but it definitely seems there is some kind of interaction with [pix_snap]: even if I force [gemframebuffer] to use texunit 0 and my textures to use texunits 1,2,3 and 4, I still get under/overflows as soon as pix_snap takes a snap, and my shader is using a snapped picture (which does not correspond to any other texture) instead of the texture I expect it to use.......
Well I will try to post a simplified patch because this explanation of mine is a mess, but it seems I have to figure out how to avoid pixsnap to mess with textures. It does not accept a texunit message (dunnow if it would make any sense)......
cyrille henry escribió:
Matteo Sisti Sette a écrit :
cyrille henry escribió:
there is an exemple of how to use multiple texture / textunit in the gem exemple folder, in directory 10.GLSL
You mean 05.multitexture.pd?
Yes I've seen it (it is thanks to that example that I have been able to do something - btw iirc it is yours, so thank you).
But that doesn't show any interaction with [gemframebuffer] nor [pix_snap]. That's where my troubles begin (apparently)
the exemple 06 show how to use gemframebuffer and multiple texture.
exemple 07 is also usefull for you.
c
-- Matteo Sisti Sette matteosistisette@gmail.com http://www.matteosistisette.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
chris clepper escribió:
pix_snap is probably using texunit 0 which is the default for any texturing call. pix_snap actually uses a function called glReadPixels(), and that might use texture units internally to grab the frame and store it before read back to main memory.
Uh, so I guess I should use texunits starting from 1 for [gemframebuffer] and [pix_texture]s?
I actually have 2 [pix_snap]s, not one. Will they both use texunit 0, or 0 and 1? Can I safely assume they won't use any higher texunit?
thanks m.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matteo Sisti Sette wrote:
chris clepper escribió:
pix_snap is probably using texunit 0 which is the default for any texturing call. pix_snap actually uses a function called glReadPixels(), and that might use texture units internally to grab the frame and store it before read back to main memory.
Uh, so I guess I should use texunits starting from 1 for [gemframebuffer] and [pix_texture]s?
I actually have 2 [pix_snap]s, not one. Will they both use texunit 0, or 0 and 1? Can I safely assume they won't use any higher texunit?
i wouldn't assume anything here. i haven't looked at the code, but i doubt that it mentions the used texunit somewhere, so it is implicitely "assumed".
if glReadPixels() internally uses texture units for grabbing, then you cannot really know anything about it.
finally, you can get the number of available texture units in your system with [GEMglGetIntegerv GL_MAX_TEXTURE_UNITS]
fgmasdr IOhannes
Well it seems that:
- by avoiding texunit 0 and (probably unnecessarily) 1, I have actually
resolved the weird interactions with [pix_snap]
- I still have stack underflows and overflows printed at each frame
which I'll investigate but it's probably not causing any "visible" issue
- What was still driving me crazy is that I didn't know that I have to
take into account that the texture size is actually the next power of two of the expected image size.
Since using [pix_texture] you don't have to worry about "padded" image size, AND since ALL glsl examples in Gem use 512x512 images, gently "avoiding" the problem, I naively thought that a MxN image used as a texture would simply have its M pixels spanning the [0,1] range in the x axis (and same for N on y).
Is there some "standard" way, some utility function or something, to deal with non-power-of-two size textures? or have I to explicitely write the calculations to get the correct coordinates? I think I can do that, but if I can have the machine do it for me I prefer that :)
Thanks m.
chris clepper escribió:
pix_snap is probably using texunit 0 which is the default for any texturing call. pix_snap actually uses a function called glReadPixels(), and that might use texture units internally to grab the frame and store it before read back to main memory.
Also, you cannot use any value for the texunit pix_texture uses most GPUs have at least 8 so texunits 0 to 7 are valid. Lots of GPUs have much more than 8 so you have to figure out where they end.
On Fri, Jan 1, 2010 at 1:38 PM, Matteo Sisti Sette <matteosistisette@gmail.com mailto:matteosistisette@gmail.com> wrote:
Thank you for pointing me to the examples, but it definitely seems there is some kind of interaction with [pix_snap]: even if I force [gemframebuffer] to use texunit 0 and my textures to use texunits 1,2,3 and 4, I still get under/overflows as soon as pix_snap takes a snap, and my shader is using a snapped picture (which does not correspond to any other texture) instead of the texture I expect it to use....... Well I will try to post a simplified patch because this explanation of mine is a mess, but it seems I have to figure out how to avoid pixsnap to mess with textures. It does not accept a texunit message (dunnow if it would make any sense)...... cyrille henry escribió: Matteo Sisti Sette a écrit : cyrille henry escribió: there is an exemple of how to use multiple texture / textunit in the gem exemple folder, in directory 10.GLSL You mean 05.multitexture.pd? Yes I've seen it (it is thanks to that example that I have been able to do something - btw iirc it is yours, so thank you). But that doesn't show any interaction with [gemframebuffer] nor [pix_snap]. That's where my troubles begin (apparently) the exemple 06 show how to use gemframebuffer and multiple texture. exemple 07 is also usefull for you. c -- Matteo Sisti Sette matteosistisette@gmail.com <mailto:matteosistisette@gmail.com> http://www.matteosistisette.com _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matteo Sisti Sette wrote:
Well it seems that:
- by avoiding texunit 0 and (probably unnecessarily) 1, I have actually
resolved the weird interactions with [pix_snap]
- I still have stack underflows and overflows printed at each frame
which I'll investigate but it's probably not causing any "visible" issue
- What was still driving me crazy is that I didn't know that I have to
take into account that the texture size is actually the next power of two of the expected image size.
Since using [pix_texture] you don't have to worry about "padded" image size, AND since ALL glsl examples in Gem use 512x512 images, gently "avoiding" the problem, I naively thought that a MxN image used as a texture would simply have its M pixels spanning the [0,1] range in the x axis (and same for N on y).
Is there some "standard" way, some utility function or something, to deal with non-power-of-two size textures? or have I to explicitely write the calculations to get the correct coordinates? I think I can do that, but if I can have the machine do it for me I prefer that :)
use rectangle textures ([rectangle 1( to [pix_texture]).
even better: try the SVN trunk which tries to use normalized texcoords for all texture modes (rectangle, normalized) by setting up the GL_TEXTURE matrices accordingly. i haven't tested it with a shader, so i would be glad if you could do that.
fg,masdr IOhannes
IOhannes m zmölnig escribió:
use rectangle textures ([rectangle 1( to [pix_texture]).
But the help patch for pix_texture says:
"Inlet 1: rectangle 0|1 : use rectangle-texturing when available (default=1)"
So sending [rectangle 1( to it should have no effect since it is the default value (if available; if not then I couldn't activate it).
Indeed with [pix_texture] I have no problem using non-power-of-two-size textures, the question is how to use them in a shader.....
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matteo Sisti Sette wrote:
IOhannes m zmölnig escribió:
use rectangle textures ([rectangle 1( to [pix_texture]).
But the help patch for pix_texture says:
"Inlet 1: rectangle 0|1 : use rectangle-texturing when available (default=1)"
hmm, i think this is wrong. rectangle is enabled by default on osx, but not on the other platforms (cannot remember why now; but i guess it made some problems)
So sending [rectangle 1( to it should have no effect since it is the default value (if available; if not then I couldn't activate it).
see above. with rectangle textures your texcoords should be 0..width-1 and 0..height-1 (rather than 0,,1); don't ask me why; i think it's one of the more stupid decisions of the ARB.
Indeed with [pix_texture] I have no problem using non-power-of-two-size textures, the question is how to use them in a shader.....
you don't have problems because Gem tries to take care of everything. with shaders you somehow circumvent Gem's trickery, so it you have to manually take care.
fgmasdr IOhannes
IOhannes m zmölnig escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matteo Sisti Sette wrote:
IOhannes m zmölnig escribió:
use rectangle textures ([rectangle 1( to [pix_texture]).
But the help patch for pix_texture says:
"Inlet 1: rectangle 0|1 : use rectangle-texturing when available (default=1)"
hmm, i think this is wrong. rectangle is enabled by default on osx, but not on the other platforms (cannot remember why now; but i guess it made some problems)
Ohhhh OK
with rectangle textures your texcoords should be 0..width-1 and 0..height-1 (rather than 0,,1); don't ask me why; i think it's one of the more stupid decisions of the ARB.
And I have to use texture2DRec instead of texture2D, don't I?
Indeed with [pix_texture] I have no problem using non-power-of-two-size textures, the question is how to use them in a shader.....
you don't have problems because Gem tries to take care of everything. with shaders you somehow circumvent Gem's trickery, so it you have to manually take care.
Yeah that's what I guessed
Thanks m.
2010/1/2 Matteo Sisti Sette matteosistisette@gmail.com
And I have to use texture2DRec instead of texture2D, don't I?
Yes, that is very important to understand. All of the texture objects have to use the same mode. As already pointed out, once you use shaders the automagic selection of these types in GEM is no longer going to work properly. The user has know how these things work.
A copy of the GLSL 'Orange Book' might come in handy too.
chris clepper escribió:
2010/1/2 Matteo Sisti Sette <matteosistisette@gmail.com mailto:matteosistisette@gmail.com>
And I have to use texture2DRec instead of texture2D, don't I?Yes, that is very important to understand. All of the texture objects have to use the same mode.
Ok thank you very much!
The user has know how these things work.
That's my big problem - lol
A copy of the GLSL 'Orange Book' might come in handy too.
Yeah I think I'll buy it soon. And the red one also, no? Would you recommend me the blue book too, or is that too much?
Matteo Sisti Sette a écrit :
A copy of the GLSL 'Orange Book' might come in handy too.
Yeah I think I'll buy it soon. And the red one also, no?
read the red book before the orange book!
Would you recommend me the blue book too, or is that too much?
that will be useful when you'll start to contribute to Gem development ;-)
c
IOhannes m zmölnig escribió:
use rectangle textures ([rectangle 1( to [pix_texture]).
Do I have to set it to all the [pix_texture] objects that "create" the textures, or only to the one using the shader?
That is, having
[gemhead] | (...something...) | | [texunit 1( |/ [pix_texture] //let's call it texture 1
[gemhead] | (...something...) | | [texunit 2( |/ [pix_texture] //let's call it texture 2
[gemhead] | (... vertex&fragment stuff) | [glsl_program] | [pix_texture] //be it "*" | [square 4]
Do I send [rectangle 1( to textures 1 and 2 or to "*"? Or both?
Thanks m.
Regarding the stack overflow and underflow error messages, I get these continuously (once per frame at least) if I send [texunit( messages to [pix_texture]s and I don't get them if I don't....
They start when a [pix_snap] takes a snapshot.
Any idea?
thanks m.
Hi,
I have to use some shaders that blend multiple textures; the only way I know to select which textures to use within a shader is to "assign" them a "texunit" (dunnow if the terminology is correct) by sending a [texunit N( messge to a [pix_texture] object so that in the shader I access that texture by the number it has been assigned.
Now, in my patch I also have one [gemframebuffer] object, two [pix_snap]s and a [pix_write].
I have understood that gemframebuffer also use a texunit and that messing with texunits causes inconsistencies (I get stack over/underflows and weird texture mess)
So I have sent it a [texunit ...( message with a number that is not in conflict with any of the other textures, but I still have problems.
I suspect [pix_snap] is also related: is that so? Can I send a texunit message to pix_snap also? And what about pix_write? Can I use any arbitrary numbers provided I avoid conflicts?
Thanks m.
Matteo Sisti Sette escribió:
Wow wow wow!!!
It seems my underflow problem (now I was getting both underflows and overflows) is in some way related to the use of texunits AND [gemframebuffer]s.
-
chris clepper -
cyrille henry -
IOhannes m zmölnig -
Matteo Sisti Sette