jit.gl.texture error message
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
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
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
>
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)
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
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!
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
OS X Universal Binary:
https://cycling74.com/download/jitter163b2.dmg
wes
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
downloading... will let you know how it goes!
thanks again
still getting this after the upgrade. it must be my patch...
:(
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
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...
>
> :(
>
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
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!
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.
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
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
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
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
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
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
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
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
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.
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
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
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
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.
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
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
>
>
>
>
>
>
----------------------------------------------------
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.
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
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
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
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
>
----------------------------------------------------
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.