jit.gl.texture error message


    Feb 05 2007 | 5:16 pm
    it's perhaps a long shot to ask without a patch, which i can post if needed...
    i keep on getting these error messages in the max window:
    jit.gl.texture : setting subteximage during submission.: GL Error : Invalid enumeration
    jit.gl.texture : setting subteximage during submission.: GL Error : Invalid operation
    all i am doing is using jit.gl.model with jit.gl.texture, i'm not really doing anything that different to the help files for both objects.
    the textures are in gif format 128 128. sometimes it works, sometimes it refuses to print the texture and i get the messages. what do they mean?
    i get a feeling its an initialisation problem... but its becoming very difficult to track down the source of this problem!
    thanks,
    justin

    • Feb 05 2007 | 5:24 pm
      Most of these texture issues have been fixed with 1.6.3b2.
      Try the beta release and see if it resolves itself. Plenty on the archives about this.
      On Feb 5, 2007, at 12:16 PM, justin wrote:
      > > it's perhaps a long shot to ask without a patch, which i can post > if needed... > > i keep on getting these error messages in the max window: > > jit.gl.texture : setting subteximage during submission.: GL Error : > Invalid enumeration > > jit.gl.texture : setting subteximage during submission.: GL Error : > Invalid operation > > all i am doing is using jit.gl.model with jit.gl.texture, i'm not > really doing anything that different to the help files for both > objects. > > the textures are in gif format 128 128. > sometimes it works, sometimes it refuses to print the texture and i > get the messages. what do they mean? > > i get a feeling its an initialisation problem... but its becoming > very difficult to track down the source of this problem! > > thanks, > > justin
      v a d e //
      www.vade.info abstrakt.vade.info
    • Feb 05 2007 | 5:28 pm
      If it's possible please post a patch. Also, for these types of things it's imperative that you post OS, Jitter version, and graphics card model.
      thanks, wes
      On 2/5/07, justin wrote: > > it's perhaps a long shot to ask without a patch, which i can post if needed... > > i keep on getting these error messages in the max window: > > jit.gl.texture : setting subteximage during submission.: GL Error : Invalid enumeration > > jit.gl.texture : setting subteximage during submission.: GL Error : Invalid operation > > all i am doing is using jit.gl.model with jit.gl.texture, i'm not really doing anything that different to the help files for both objects. > > the textures are in gif format 128 128. > sometimes it works, sometimes it refuses to print the texture and i get the messages. what do they mean? > > i get a feeling its an initialisation problem... but its becoming very difficult to track down the source of this problem! > > thanks, > > justin >
    • Feb 05 2007 | 5:50 pm
      thanks for looking into this, it's really starting to do my head in!!! probably something real stupid.
      i havent tried the latest beta, where do i download it? not sure i want to try that just yet as might screw other patches up...
      here is the patch(es) + 3d.obj file + texture.gif
      the main patch is: 3dmodel+texture_glitch.pat with an abstraction loaded as bpatcher: model.texture
      * files need to be in the max searchpath!
      assuming it can find the files, it should auto load model and texture file.
      the system is: macbookpro 2.16 core duo 1gb ram ATI radeon X1600 - 256 ram
      osx.4.8 + latest updates
      maxmsp 4.6.2 jitter 1.6.2 + latest pluggo (cant remember vesion number, but shouldnt make a difference)
    • Feb 05 2007 | 6:05 pm
      Hi Justin, I tried it on Jitter 1.6.3 beta1 on basically an identical system (imac instead of mac book pro) and I don't get any errors. I'm going to provisionally say that this is fixed unless someone with a beta version of Jitter gets the errors as well.
      wes
    • Feb 05 2007 | 6:08 pm
      weird, just tested it on an old g4 1ghz with a ATI Mobility Radeon 9000, same patch, version of OSX and maxmsp jitter... and no error messages!
    • Feb 05 2007 | 6:10 pm
      cheers wes, really need this to work for an upcoming performance...
      i'm going to have to go with the beta, where's the URL? searched the forums couldnt find any mention.
      justin
    • Feb 05 2007 | 6:15 pm
      I also had no errors on 1.6.3b2, fwiw.
      On Feb 5, 2007, at 1:05 PM, Wesley Smith wrote:
      > Hi Justin, > I tried it on Jitter 1.6.3 beta1 on basically an identical system > (imac instead of mac book pro) and I don't get any errors. I'm going > to provisionally say that this is fixed unless someone with a beta > version of Jitter gets the errors as well. > > wes
      v a d e //
      www.vade.info abstrakt.vade.info
    • Feb 05 2007 | 6:17 pm
      downloading... will let you know how it goes!
      thanks again
    • Feb 05 2007 | 7:25 pm
      still getting this after the upgrade. it must be my patch...
      :(
    • Feb 05 2007 | 7:35 pm
      I didnt get the issue with your patch on my hardware. Does it happen off the bat when you lock render, or do you have to trigger something to make it happen? On Feb 5, 2007, at 2:25 PM, justin wrote:
      > > still getting this after the upgrade. it must be my patch... > > :(
      v a d e //
      www.vade.info abstrakt.vade.info
    • Feb 05 2007 | 7:38 pm
      Don't know hat you're doing exactly to get this error, but I tried it on a Pb 1.67 with a Radeon 9700 and had no texture errors with Jitter 1.6.3b2 10.4.8. Perhaps if you organized the patch to be cleaner, it might be easier to figure this out.
      wes
      On 2/5/07, justin wrote: > > still getting this after the upgrade. it must be my patch... > > :( >
    • Feb 05 2007 | 7:47 pm
      Er, Im doing too many things at once - click render I meant On Feb 5, 2007, at 2:35 PM, vade wrote:
      > I didnt get the issue with your patch on my hardware. Does it > happen off the bat when you lock render, or do you have to trigger > something to make it happen? > On Feb 5, 2007, at 2:25 PM, justin wrote: > >> >> still getting this after the upgrade. it must be my patch... >> >> :( > > v a d e // > > www.vade.info > abstrakt.vade.info > > >
      v a d e //
      www.vade.info abstrakt.vade.info
    • Feb 05 2007 | 8:14 pm
      Quote: wesley.hoke@gmail.com wrote on Mon, 05 February 2007 12:38 ---------------------------------------------------- Perhaps if you organized the patch to be cleaner, it > might be easier to figure this out. > > wes > > On 2/5/07, justin wrote: > > > > still getting this after the upgrade. it must be my patch... > > > > :( > > > ----------------------------------------------------
      this is a very rough early development of the patch i want to build. hence, it's not very clean. ;)
      i'm going through it at the moment, and i've already found a few probs. alas still not there... foolishly, i was hoping it was something obvious!
    • Feb 05 2007 | 8:16 pm
      Quote: vade wrote on Mon, 05 February 2007 12:47 ---------------------------------------------------- > Er, Im doing too many things at once - click render I meant > On Feb 5, 2007, at 2:35 PM, vade wrote:
      immediately after click render.
    • Feb 05 2007 | 9:00 pm
      on my investigations, i discovered that the precision message doesnt seem to work on the jit.gl.texture object help file...
      ?error : "jit.gl.texture object doesnt understand precision"
      jitter 1.6.3b2
    • Feb 06 2007 | 1:34 pm
      this morning, i made a break through with the problem! i'm not quite out of the woods yet...
      the problem appears to stem from jit.gl.texture, which would make sense considering the error message refers to it. after changing the texgen message from none to something else then back to none, and tinkering with the material_mode > jit.gl.model the object works??? i actually want the material mode to be set to 0, also i have a side issue (unrelated to this problem) with cheetah3d exporting .obj files with default material - how do i turn this off?
      i think there is a clash in the messages between material_mode and tex_map > jit.gl.model and texgen > jit.gl.texture... it's still difficult for me to find the exact way of achieving this, but there seems to be a problem under the hood.
      also i would like to understand the difference between 2 different ways to control the mapping of the texture. what's difference between the tex_map message which you can send straight to the jit.gl.model object, and the texgen message which you send to the jit.gl.texture object?
      a cleaner version of the patch is attached, i think loadbang was guilty of some initialisation problem with tex_map and material_mode... but i still get the error message every time i hit render. i have to play around with the mentioned msg until it works, but at this point i cannot seem to make sense of what is going on????????????????
      j
    • Feb 06 2007 | 4:38 pm
      Are you seeing the message "jit.gl.texture: setting subteximage during submission: GL Error: Invalid Operation"? I get this and will look into it. Thanks for the clear patch.
      > i think there is a clash in the messages between material_mode and tex_map > jit.gl.model and texgen > jit.gl.texture... it's still difficult for me to find the exact way of achieving this, but there seems to be a problem under the hood.
      This is correct. jit.gl.texture is a relatively new jitter object, so there may be some overlap between its functionality and attributes of other jit.gl objects. I beleive that if @tex_map is 0, jit.gl.texture's @texgen setting will take precedence. Otherwise, the object's @tex_map will have the f inal say.
      > > also i would like to understand the difference between 2 different ways to control the mapping of the texture. what's difference between the tex_map message which you can send straight to the jit.gl.model object, and the texgen message which you send to the jit.gl.texture object? >
      There is no difference. Under the hood they're doing the same thing. It depends on your preference.
      wes
    • Feb 06 2007 | 5:13 pm
      Quote: wesley.hoke@gmail.com wrote on Tue, 06 February 2007 09:38 ---------------------------------------------------- > Are you seeing the message "jit.gl.texture: setting subteximage during > submission: GL Error: Invalid Operation"? I get this and will look > into it. Thanks for the clear patch.
      thanks for the clarification on the texture mapping messages. these are the 2 messages i have seen in the max window:
      jit.gl.texture : setting subteximage during submission.: GL Error : Invalid enumeration
      jit.gl.texture : setting subteximage during submission.: GL Error : Invalid operation
      although the last one is the most frequent...
      since my last post, i also discovered the problem to be related to matrixouput 1 on the jit.gl.model object. if i remove this attr and render directly to jit.gl.render then i dont get this error message???
      glad you liked the "clearer patch" ;)
      thanks, justin
    • Feb 08 2007 | 5:16 am
      Just to follow up. I did manage to track down the issue that was causing the errors. Thanks for your persistence in making it easy to track down.
      wes
    • Feb 08 2007 | 10:44 am
      Quote: wesley.hoke@gmail.com wrote on Wed, 07 February 2007 22:16 ---------------------------------------------------- > Just to follow up. I did manage to track down the issue that was > causing the errors. Thanks for your persistence in making it easy to > track down. > > wes > ----------------------------------------------------
      no problem, is this an "easy fix"? will it make it in an incremental update, or the next jitter beta?
      i would like to know because i was hoping to be able to make a patch using these 2 objects for a show next month... otherwise i was going to ask if there is a way to stop textures from interpolating (or equivalent of @filter none in jit.gl.texture)?
      that's one of the main reasons i started exploring the object, just so i could turn off texture interpolation!
      thanks,
      justin
    • Feb 08 2007 | 7:08 pm
      On Feb 8, 2007, at 2:44 AM, justin wrote:
      > no problem, is this an "easy fix"? will it make it in an > incremental update, or the next jitter beta?
      It will require a new beta, which I'll try to get ready soon.
      > i would like to know because i was hoping to be able to make a > patch using these 2 objects for a show next month... otherwise i > was going to ask if there is a way to stop textures from > interpolating (or equivalent of @filter none in jit.gl.texture)?
      Btw, virtually all the jitter objects use jit.gl.texture under the hood, so if you have another version of the patch that works, you can often use "sendtexture" or similar to set attributes of the jit.gl.texture object. Or, if you use "rectangular" textures (it's okay if they're really powers of two in dimension), you might find that it works with the current implementation. Wesley could better speak to this.
      -Joshua
    • Feb 08 2007 | 7:37 pm
      Quote: jkc wrote on Thu, 08 February 2007 12:08 ---------------------------------------------------- > It will require a new beta, which I'll try to get ready soon.
      thanks, any idea of how long this would take? as i said i am kind of relying on this object for a performance next month. but if this is too soon, i will have to work out a way around it...
      > Btw, virtually all the jitter objects use jit.gl.texture under the > hood, so if you have another version of the patch that works, you can > often use "sendtexture" or similar to set attributes of the > jit.gl.texture object. Or, if you use "rectangular" textures (it's > okay if they're really powers of two in dimension), you might find > that it works with the current implementation. Wesley could better > speak to this.
      i'm not quite sure i follow you here. are you saying that all globjects use jit.gl.texture under the hood? in which case if i were to send the message "sendtexture filter none" to the jit.gl.model object it should stop the anti-aliasing from occuring.
      all the textures i use are 128x128 pixels, and all consist of vertical / horizontal lines of 2 different colours (one of the texture gif files is attached to my first post). but with the old way of texturing objects i still had a blurry edge on lines within a texture. i want the lines to be jagged, not smooth...
      i'm after a lofi computer graphics aesthetic, so blurry textures are no good.
      hope that makes sense, and apologies if i seem impatient on the jit.gl.texture fix. i just need to know what course of action to take as the deadline is looming on the horizon...
      justin
    • Feb 08 2007 | 7:49 pm
      What you are looking for is jit.gl.texture foo @filter nearest
      That will do nearest neighbor sampling for that pixely retro look that we all love.
      Cheers, Andrew B.
    • Feb 08 2007 | 8:03 pm
      Quote: andrewb@cycling74.com wrote on Thu, 08 February 2007 19:49 ---------------------------------------------------- > What you are looking for is jit.gl.texture foo @filter nearest > > That will do nearest neighbor sampling for that pixely retro look that > we all love. > > Cheers, > Andrew B. > ----------------------------------------------------
      thanks andrew, but jit.gl.texture gives me error messages as discussed above. so for the moment i cant use it, i was wandering if there was any way of using the old texture method:
      jit.qt.movie > prepend texture foo > jit.gl.model
      and still being able to use jit.gl.texture messages to turn off the aliasing with "filter none / nearest"?
      i cant get enough of that pixely retro look ;)
      j
    • Feb 08 2007 | 8:26 pm
      Are you able to use the jit.gl.slab object?
      If so, try using jit.gl.slab foo @file td.resample.jxs @param interp 0.
      This should do roughly the same thing, rounding down instead of doing nearest neighbor.
      AB
    • Feb 08 2007 | 9:00 pm
      Hi
      when, on mac, i want a jit.window to go on the 2nd screen, is there a message for this (which I could loadbang)??
      there is such a thing with soft vns, I was reallly sure it also did exist with jitter (I would _swear_ I used it) but can not find it........
      best
      kasper -- Kasper T. Toeplitz noise, composition, bass, computer http://www.sleazeArt.com
    • Feb 08 2007 | 9:06 pm
    • Feb 08 2007 | 9:08 pm
      Quote: andrewb@cycling74.com wrote on Thu, 08 February 2007 20:26 ---------------------------------------------------- > Are you able to use the jit.gl.slab object? > > If so, try using jit.gl.slab foo @file td.resample.jxs @param interp 0. > > This should do roughly the same thing, rounding down instead of doing > nearest neighbor. > > AB > ----------------------------------------------------
      hmm... yeah have used jit.gl.slab, seems a little bit of a long way round though?!
      i'll give it a go over the weekend... it's a shame cos when i can get jit.gl.texture to work properly it does the job perfectly. only problem is initalising the object, it seems to be quite temperemental on my system, which is not good for a performance setup.
      aargh... back to bludgeoning my head against a brick wall thanks for the suggestions anyway, will see how it goes.
    • Feb 08 2007 | 9:26 pm
      On Feb 8, 2007, at 11:37 AM, justin wrote:
      > thanks, any idea of how long this would take? as i said i am kind > of relying on this object for a performance next month. but if this > is too soon, i will have to work out a way around it...
      I'll try to get out before next friday.
      > i'm not quite sure i follow you here. are you saying that all > globjects use jit.gl.texture under the hood? in which case if i > were to send the message "sendtexture filter none" to the > jit.gl.model object it should stop the anti-aliasing from occuring.
      The trick is to send to jit.gl.render where I believe you are defining the texture. The sendtexture message works only for objects like jit.gl.render, jit.gl.videoplane, jit.gl.slab, or jit.gl.imageunit which manage the "under the hood" jit.gl.texture instances for you (not the client objects like jit.gl.plato to which they are applied). For jit.gl.slab and jit.gl.imageunit, it would be "sendinput" or "sendoutput".
      The "classic" jit.gl.render way to accomplish this (in the jit.gl.render help patch, and I believe the docs) is "usetexture foo, interp 0"->jit.gl.render. You can also do the same thing with "usetexture foo, sendtexture filter nearest".
      -Joshua
    • Feb 08 2007 | 11:37 pm
      after a few drinks down the pub, reading this is very soothing. alcohol may have to do something with the dramatization... what can i say apart from ur a star!
      cheers.
      j
      Quote: jkc wrote on Thu, 08 February 2007 21:26 ---------------------------------------------------- > > On Feb 8, 2007, at 11:37 AM, justin wrote: > > > thanks, any idea of how long this would take? as i said i am kind > > of relying on this object for a performance next month. but if this > > is too soon, i will have to work out a way around it... > > I'll try to get out before next friday. > > > i'm not quite sure i follow you here. are you saying that all > > globjects use jit.gl.texture under the hood? in which case if i > > were to send the message "sendtexture filter none" to the > > jit.gl.model object it should stop the anti-aliasing from occuring. > > > The trick is to send to jit.gl.render where I believe you are > defining the texture. The sendtexture message works only for objects > like jit.gl.render, jit.gl.videoplane, jit.gl.slab, or > jit.gl.imageunit which manage the "under the hood" jit.gl.texture > instances for you (not the client objects like jit.gl.plato to which > they are applied). For jit.gl.slab and jit.gl.imageunit, it would be > "sendinput" or "sendoutput". > > The "classic" jit.gl.render way to accomplish this (in the > jit.gl.render help patch, and I believe the docs) is "usetexture foo, > interp 0"->jit.gl.render. You can also do the same thing with > "usetexture foo, sendtexture filter nearest". > > -Joshua > > > > > > ----------------------------------------------------
    • Feb 09 2007 | 12:36 am
      I am working on my openGL random-shape performance patch, and I am looking for ways to set up colour templates in an easy fashion, to tell the patch "I want these shades of orange and grey for my objects and background" etc. I made a quick fix at one point by doing preset->swatch, but that was hardly elegant, and screwed things up, as per usual. Then jit.charmap springs to mind, but I am still wondering how to do this in the sleekest way.
      I have a growing collection of simple textures I am using, so perhaps bubble sort-> jit.matrix getcell from these? Or can charmap be loaded easily with a texture, so that all data passing through charmap will conform to its colours?
      I am probably missing something ridiculously simple, hence this email. I have a tendency to complicate things. The help files that apply to these objects used multisliders, and I am having a tough time extrapolating the concepts to my needs.
      thanks, Andreas.
    • Feb 09 2007 | 2:55 am
      Hi Andreas, You can make color relationships and use jit.rbg2hsl->jit.hsl2rgb to shift the palette through the colorspace while maintaining the relative relationships of colors. You could probably got some interesting transpositions of color relationships by doing this in combination with scaling and offsetting the values in hsl space. Below is a start, but the matrix probably has more colors than you want in a given palette. Just replace the colors matrix with your own.
      wes
    • Feb 12 2007 | 1:07 pm
      back onto the original topic of this thread - error messages from using jit.gl.texture with jit.gl.model.
      i discovered another problem when using matrixoutput on jit.gl.model. if u set a texture (1) in jit.gl.model with matrixoutput 0, then enable matrixoutput and set a new texture (2), now disable matrixoutput and it returns to texture (1)... (?)
      i expect it to use the last texture which is currently loaded, regardless of matrixoutput state. i assume this problem is related to the error messages.
      strange...
      justin
    • Feb 12 2007 | 8:29 pm
      On Feb 12, 2007, at 1:07 PM, justin wrote:
      > > back onto the original topic of this thread - error messages from > using jit.gl.texture with jit.gl.model. > > i discovered another problem when using matrixoutput on > jit.gl.model. if u set a texture (1) in jit.gl.model with > matrixoutput 0, then enable matrixoutput and set a new texture (2), > now disable matrixoutput and it returns to texture (1)... (?) > > i expect it to use the last texture which is currently loaded, > regardless of matrixoutput state. i assume this problem is related > to the error messages.
      Don't think it's the error messages, but rather the use of displaylists in the object. It can be considered a bug, but it probably won't be fixed in the near term. You can probably resent the texture message again as a workaround when toggling, or send the "rebuild_geometry" message to jit.gl.model. let us know if this does or doesn't work for you, and if not, please send a simple example.
      -Joshua
    • Feb 12 2007 | 9:15 pm
      cool, will check that out and let you know...
      Quote: jkc wrote on Mon, 12 February 2007 20:29 ---------------------------------------------------- > > On Feb 12, 2007, at 1:07 PM, justin wrote: > > > > > back onto the original topic of this thread - error messages from > > using jit.gl.texture with jit.gl.model. > > > > i discovered another problem when using matrixoutput on > > jit.gl.model. if u set a texture (1) in jit.gl.model with > > matrixoutput 0, then enable matrixoutput and set a new texture (2), > > now disable matrixoutput and it returns to texture (1)... (?) > > > > i expect it to use the last texture which is currently loaded, > > regardless of matrixoutput state. i assume this problem is related > > to the error messages. > > Don't think it's the error messages, but rather the use of > displaylists in the object. It can be considered a bug, but it > probably won't be fixed in the near term. You can probably resent the > texture message again as a workaround when toggling, or send the > "rebuild_geometry" message to jit.gl.model. let us know if this does > or doesn't work for you, and if not, please send a simple example. > > -Joshua > ----------------------------------------------------
    • Feb 13 2007 | 10:54 pm
      Hello Wesley, sorry for the late reply - I've been brooding over this one.
      Wesley Smith skrev: > Hi Andreas, > You can make color relationships and use jit.rbg2hsl->jit.hsl2rgb to > shift the palette through the colorspace while maintaining the > relative relationships of colors. [snip] Wow. That's a very nice patch! Inspirational, for sure - yoink! I ended up using the getcell method I hinted at earlier - nothing has been implemented yet, but it seems like a rational choice nonetheless. I simply save my swatches when making my textures, and leave in a few of the discarded choices. That leaves me little files like the one attached to this email, that can easily be passed through your patch further down the line. I think I will stick to little 16 pixel images, they're a nice change from all the 128^2 that's going around these days.
      Cheers, Andreas.