jit.gl.texture error message

Feb 5, 2007 at 5:16pm

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

#30125
Feb 5, 2007 at 5:24pm

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 //

http://www.vade.info
abstrakt.vade.info

#95590
Feb 5, 2007 at 5:28pm

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
>

#95591
Feb 5, 2007 at 5:50pm

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)

#95592
Feb 5, 2007 at 6:05pm

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

#95593
Feb 5, 2007 at 6:08pm

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!

#95594
Feb 5, 2007 at 6:10pm

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

#95595
Feb 5, 2007 at 6:15pm
#95596
Feb 5, 2007 at 6:15pm

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 //

http://www.vade.info
abstrakt.vade.info

#95597
Feb 5, 2007 at 6:17pm

downloading… will let you know how it goes!

thanks again

#95598
Feb 5, 2007 at 7:25pm

still getting this after the upgrade. it must be my patch…

:(

#95599
Feb 5, 2007 at 7:35pm

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 //

http://www.vade.info
abstrakt.vade.info

#95600
Feb 5, 2007 at 7:38pm

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…
>
> :(
>

#95601
Feb 5, 2007 at 7:47pm

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 //
>
> http://www.vade.info
> abstrakt.vade.info
>
>
>

v a d e //

http://www.vade.info
abstrakt.vade.info

#95602
Feb 5, 2007 at 8:14pm

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!

#95603
Feb 5, 2007 at 8:16pm

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.

#95604
Feb 5, 2007 at 9:00pm

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

#95605
Feb 6, 2007 at 1:34pm

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

#95606
Feb 6, 2007 at 4:38pm

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

#95607
Feb 6, 2007 at 5:13pm

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

#95608
Feb 8, 2007 at 5:16am

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

#95609
Feb 8, 2007 at 10:44am

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

#95610
Feb 8, 2007 at 7:08pm

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

#95611
Feb 8, 2007 at 7:37pm

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 128×128 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

#95612
Feb 8, 2007 at 7:49pm

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.

#95613
Feb 8, 2007 at 8:03pm

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

#95614
Feb 8, 2007 at 8:26pm

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

#95615
Feb 8, 2007 at 9:00pm

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

http://www.myspace.com/sleazeart

#95616
Feb 8, 2007 at 9:06pm

#95617
Feb 8, 2007 at 9:08pm

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.

#95618
Feb 8, 2007 at 9:26pm

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

#95619
Feb 8, 2007 at 11:37pm

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
>
>
>
>
>
>
—————————————————-

#95620
Feb 9, 2007 at 12:36am

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.

#95621
Feb 9, 2007 at 2:55am

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

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 80 22 48 196617 loadbang;
#P newex 580 130 55 196617 slide 5. 5.;
#P newex 580 110 40 196617 / 255.;
#P newex 580 88 71 196617 drunk 255 10;
#P newex 492 125 55 196617 slide 5. 5.;
#P newex 492 105 40 196617 / 255.;
#P newex 492 83 71 196617 drunk 255 10;
#P user jit.pwindow 303 253 202 202 0 1 0 0 1 0;
#P flonum 641 157 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 641 177 49 196617 lscale $1;
#P flonum 696 157 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 696 177 53 196617 loffset $1;
#P flonum 526 157 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 526 177 51 196617 sscale $1;
#P flonum 581 157 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 581 177 55 196617 soffset $1;
#P flonum 409 157 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 409 177 51 196617 hscale $1;
#P flonum 464 157 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 464 177 55 196617 hoffset $1;
#P newex 304 230 58 196617 jit.hsl2rgb;
#P newex 304 208 58 196617 jit.rgb2hsl;
#P newex 304 176 86 196617 jit.matrix colors;
#P toggle 304 135 15 0;
#P newex 304 155 57 196617 qmetro 30;
#P user jit.pwindow 79 126 202 202 0 0 0 0 1 0;
#P newex 80 105 160 196617 jit.matrix colors 4 char 100 100;
#P button 80 43 15 0;
#P newex 80 63 142 196617 jit.matrix 4 float32 100 100;
#P newex 80 84 391 196617 jit.expr @expr “1″ “pow(norm[0]\, 0.5)”
“sin(norm[0]*PI)” “pow(norm[1]\, 0.5)”;
#P connect 29 0 2 0;
#P connect 5 0 7 0;
#P connect 5 0 23 0;
#P connect 5 0 26 0;
#P connect 28 0 15 0;
#P connect 26 0 27 0;
#P connect 27 0 28 0;
#P connect 24 0 25 0;
#P connect 25 0 11 0;
#P connect 23 0 24 0;
#P fasten 18 0 8 0 701 200 309 200;
#P fasten 20 0 8 0 646 200 309 200;
#P fasten 14 0 8 0 586 200 309 200;
#P fasten 16 0 8 0 531 200 309 200;
#P fasten 10 0 8 0 469 200 309 200;
#P fasten 12 0 8 0 414 200 309 200;
#P connect 9 0 22 0;
#P connect 13 0 12 0;
#P connect 11 0 10 0;
#P connect 17 0 16 0;
#P connect 15 0 14 0;
#P connect 21 0 20 0;
#P connect 19 0 18 0;
#P connect 8 0 9 0;
#P connect 7 0 8 0;
#P connect 6 0 5 0;
#P connect 0 0 3 0;
#P connect 1 0 0 0;
#P connect 3 0 4 0;
#P connect 2 0 1 0;
#P window clipboard copycount 30;

#95622
Feb 12, 2007 at 1:07pm

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

#95623
Feb 12, 2007 at 8:29pm

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

#95624
Feb 12, 2007 at 9:15pm

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
>
—————————————————-

#95625
Feb 13, 2007 at 10:54pm

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.

#95626

You must be logged in to reply to this topic.