lists@lowfrequency.or

Is this possible? I've successfully *rendered* to a larger-than- 

screen-context on OS X and max 1.6.2b2 (using the software renderer 

with "noaccell 1" sent to the jit.window) but on 1..6rc1, when trying 

to capture to a texture larger than the screen (using a jit.gl.sketch 

object with the "@capture TEXNAME" set and a jit.gl.texture with @dim 

set to something obscenely large, like 4000x3200) I get errors like 

"cannot create context XXXX" in the max window and a blank screen. 

When I set "noaccel 0" again and resize the textures to the actual 

screen size in pixels, the error goes away and all works.

Any insight into this, before I go an wrack my brains and spend a few 

hours trying out different settings? An example patch showing this 

Is this possible? I've successfully *rendered* to a larger-than- 
screen-context on OS X and max 1.6.2b2 (using the software renderer  
with "noaccell 1" sent to the jit.window) but on 1..6rc1, when trying  
to capture to a texture larger than the screen (using a jit.gl.sketch  
object with the "@capture TEXNAME" set and a jit.gl.texture with @dim  
set to something obscenely large, like 4000x3200) I get errors like  
"cannot create context XXXX" in the max window and a blank screen.   
When I set "noaccel 0" again and resize the textures to the actual  
screen size in pixels, the error goes away and all works.

Any insight into this, before I go an wrack my brains and spend a few  
hours trying out different settings?  An example patch showing this  
error is easy to whip up:

how-to-capture-to-texture-larger-than-screen

Yes it's possible with HW acceleration with a amx dim of 2048x2048.

> Is this possible? I've successfully *rendered* to a

> larger-than-screen-context on OS X and max 1.6.2b2 (using the software

> renderer with "noaccell 1" sent to the jit.window) but on 1..6rc1, when

> trying to capture to a texture larger than the screen (using a jit.gl.sketch

> object with the "@capture TEXNAME" set and a jit.gl.texture with @dim set to

> something obscenely large, like 4000x3200) I get errors like "cannot create

> context XXXX" in the max window and a blank screen. When I set "noaccel 0"

> again and resize the textures to the actual screen size in pixels, the error

> Any insight into this, before I go an wrack my brains and spend a few hours

> trying out different settings? An example patch showing this error is easy

> #P newex 210 340 184 196617 jit.matrix readback 4 char 4000 3200;

> #P message 274 276 108 196617 glreadpixels readback , bang;

> #P newex 274 313 178 196617 jit.gl.sketch t00b1g @automatic 0;

> #P message 427 83 339 196617 reset , glenable cull_face , glcullface back

> , shapeslices 50 20 , glcolor 0.4 0.4 0 , cylinder 0.05 0.05 0.5 ,

> moveto 0 0 -0.5 , shapeorient 180 0 0 , circle 0.1 , glcolor 0.3 0.2 1 ,

> moveto 0 0 0.5 , circle 0.2 , moveto 0 0 0.75 , shapeorient 0 0 0 ,

> #P newex 430 161 178 196617 jit.gl.sketch t00b1g @capture ouch;

> #P newex 210 372 162 196617 jit.window sm4llz @size 320 240;

> #P newex 522 242 224 196617 jit.gl.texture t00b1g @name ouch @dim 4000 3200;

> #P message 307 214 57 196617 getcamera;

> #P newex 118 295 69 196617 print window;

> #P newex 21 235 127 196617 route size update;

> #P newex 21 268 72 196617 s window-size;

> #P comment 43 135 57 196617 16:9 ratio;

> #P message 44 150 70 196617 size 320 180;

> #P message 44 110 70 196617 size 320 240;

> #P newex 35 174 176 196617 jit.window t00b1g @depthbuffer 1 @fsmenubar 0

Yes it's possible with HW acceleration with a amx dim of 2048x2048.
This is an OSX limitation.

On 6/4/07, evan.raskob [lists]  wrote:
> Is this possible? I've successfully *rendered* to a
> larger-than-screen-context on OS X and max 1.6.2b2 (using the software
> renderer with "noaccell 1" sent to the jit.window) but on 1..6rc1, when
> trying to capture to a texture larger than the screen (using a jit.gl.sketch
> object with the "@capture TEXNAME" set and a jit.gl.texture with @dim set to
> something obscenely large, like 4000x3200) I get errors like "cannot create
> context XXXX" in the max window and a blank screen.  When I set "noaccel 0"
> again and resize the textures to the actual screen size in pixels, the error
> goes away and all works.
>
> Any insight into this, before I go an wrack my brains and spend a few hours
> trying out different settings?  An example patch showing this error is easy
> to whip up:
>
> max v2;
> #N vpatcher 241 536 1132 983;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 215 271 50 196617 t b b;
> #P newex 210 340 184 196617 jit.matrix readback 4 char 4000 3200;
> #P window linecount 2;
> #P message 274 276 108 196617 glreadpixels readback , bang;
> #P window linecount 1;
> #P newex 274 313 178 196617 jit.gl.sketch t00b1g @automatic 0;
> #P window linecount 4;
> #P message 427 83 339 196617 reset , glenable cull_face , glcullface back
> , shapeslices 50 20 , glcolor 0.4 0.4 0 , cylinder 0.05 0.05 0.5 ,
> moveto 0 0 -0.5 , shapeorient 180 0 0 , circle 0.1 , glcolor 0.3 0.2 1 ,
> moveto 0 0 0.5 , circle 0.2 , moveto 0 0 0.75 , shapeorient 0 0 0 ,
> cylinder 0 0.2 0.25;
> #P window linecount 1;
> #P newex 430 161 178 196617 jit.gl.sketch t00b1g @capture ouch;
> #P newex 210 372 162 196617 jit.window sm4llz @size 320 240;
> #P window linecount 2;
> #P newex 522 242 224 196617 jit.gl.texture t00b1g @name ouch @dim 4000 3200;
> #P window linecount 1;
> #P message 307 214 57 196617 getcamera;
> #P toggle 100 271 15 0;
> #P newex 118 270 29 196617 gate;
> #P newex 118 295 69 196617 print window;
> #P message 43 71 42 196617 getsize;
> #P newex 21 235 127 196617 route size update;
> #P newex 21 268 72 196617 s window-size;
> #P comment 43 135 57 196617 16:9 ratio;
> #P comment 44 95 51 196617 4:3 ratio;
> #P message 44 150 70 196617 size 320 180;
> #P message 44 110 70 196617 size 320 240;
> #P window linecount 3;
> #P newex 35 174 176 196617 jit.window t00b1g @depthbuffer 1 @fsmenubar 0
> @noaccel 1 @size 4000 3200 @visible 0;
> #P user panel 33 60 97 112;
> #X brgb 184 197 245;
> #X frgb 149 149 149;
> #X border 1;
> #X rounded 5;
> #X shadow 0;
> #X done;
> #P toggle 247 55 15 0;
> #P window linecount 1;
> #P newex 247 85 57 196617 qmetro 10;
> #P newex 287 173 42 196617 t erase;
> #P newex 247 149 50 196617 gate 2;
> #P newex 247 118 50 196617 uzi 2;
> #P newex 247 239 224 196617 jit.gl.render t00b1g @erase_color 0. 0. 0. 1.;
> #P fasten 7 1 13 0 187 223 26 223;
> #P connect 13 0 12 0;
> #P fasten 9 0 7 0 49 171 40 171;
> #P fasten 8 0 7 0 49 129 40 129;
> #P fasten 14 0 7 0 48 90 40 90;
> #P fasten 13 1 14 0 84 258 199 258 199 63 48 63;
> #P connect 17 0 16 0;
> #P connect 16 0 15 0;
> #P connect 13 2 16 1;
> #P connect 26 0 25 0;
> #P connect 25 0 20 0;
> #P connect 0 0 26 0;
> #P connect 5 0 4 0;
> #P connect 4 0 1 0;
> #P connect 1 2 2 0;
> #P fasten 18 0 0 0 312 234 252 234;
> #P connect 2 0 0 0;
> #P fasten 3 0 0 0 292 195 252 195;
> #P connect 26 1 24 0;
> #P connect 24 0 23 0;
> #P connect 1 0 2 1;
> #P connect 2 1 3 0;
> #P connect 22 0 21 0;
> #P pop;
>
>
>
>


> Yes it's possible with HW acceleration with a amx dim of 2048x2048.

Do you happen to know if this is a limitation in winXP too? I'd like to 

attempt a capture-to-texture screen size of 3360*1050 - perhaps one 

could capture two parts of the jit.gl.sketch and display them side by side?

Wesley Smith skrev:
> Yes it's possible with HW acceleration with a amx dim of 2048x2048.
> This is an OSX limitation.
>
> wes 

Do you happen to know if this is a limitation in winXP too? I'd like to 
attempt a capture-to-texture screen size of 3360*1050 - perhaps one 
could capture two parts of the jit.gl.sketch and display them side by side?

What about without hardware acceleration? That doesn't seem to work 

for me with the @capture attribute, unless I'm doing something wrong.

On Jun 4, 2007, at 11:03 PM, Wesley Smith wrote:

>> Is this possible? I've successfully *rendered* to a

>> larger-than-screen-context on OS X and max 1.6.2b2 (using the 

>> renderer with "noaccell 1" sent to the jit.window) but on 1..6rc1, 

>> trying to capture to a texture larger than the screen (using a 

>> object with the "@capture TEXNAME" set and a jit.gl.texture with 

>> something obscenely large, like 4000x3200) I get errors like 

>> context XXXX" in the max window and a blank screen. When I set 

>> again and resize the textures to the actual screen size in pixels, 

>> Any insight into this, before I go an wrack my brains and spend a 

>> trying out different settings? An example patch showing this 

>> #P newex 210 340 184 196617 jit.matrix readback 4 char 4000 3200;

>> #P message 274 276 108 196617 glreadpixels readback , bang;

>> #P newex 274 313 178 196617 jit.gl.sketch t00b1g @automatic 0;

>> #P message 427 83 339 196617 reset , glenable cull_face , 

>> , shapeslices 50 20 , glcolor 0.4 0.4 0 , cylinder 0.05 0.05 

>> moveto 0 0 -0.5 , shapeorient 180 0 0 , circle 0.1 , glcolor 

>> moveto 0 0 0.5 , circle 0.2 , moveto 0 0 0.75 , shapeorient 0 0 

Thanks, good to know.
What about without hardware acceleration?  That doesn't seem to work  
for me with the @capture attribute, unless I'm doing something wrong.

> Yes it's possible with HW acceleration with a amx dim of 2048x2048.
> This is an OSX limitation.
>
> wes
>
> On 6/4/07, evan.raskob [lists]  wrote:
>> Is this possible? I've successfully *rendered* to a
>> larger-than-screen-context on OS X and max 1.6.2b2 (using the  
>> software
>> renderer with "noaccell 1" sent to the jit.window) but on 1..6rc1,  
>> when
>> trying to capture to a texture larger than the screen (using a  
>> jit.gl.sketch
>> object with the "@capture TEXNAME" set and a jit.gl.texture with  
>> @dim set to
>> something obscenely large, like 4000x3200) I get errors like  
>> "cannot create
>> context XXXX" in the max window and a blank screen.  When I set  
>> "noaccel 0"
>> again and resize the textures to the actual screen size in pixels,  
>> the error
>> goes away and all works.
>>
>> Any insight into this, before I go an wrack my brains and spend a  
>> few hours
>> trying out different settings?  An example patch showing this  
>> error is easy
>> to whip up:
>>
>> max v2;
>> #N vpatcher 241 536 1132 983;
>> #P window setfont "Sans Serif" 9.;
>> #P window linecount 1;
>> #P newex 215 271 50 196617 t b b;
>> #P newex 210 340 184 196617 jit.matrix readback 4 char 4000 3200;
>> #P window linecount 2;
>> #P message 274 276 108 196617 glreadpixels readback , bang;
>> #P window linecount 1;
>> #P newex 274 313 178 196617 jit.gl.sketch t00b1g @automatic 0;
>> #P window linecount 4;
>> #P message 427 83 339 196617 reset , glenable cull_face ,  
>> glcullface back
>> , shapeslices 50 20 , glcolor 0.4 0.4 0 , cylinder 0.05 0.05  
>> 0.5 ,
>> moveto 0 0 -0.5 , shapeorient 180 0 0 , circle 0.1 , glcolor  
>> 0.3 0.2 1 ,
>> moveto 0 0 0.5 , circle 0.2 , moveto 0 0 0.75 , shapeorient 0 0  
>> 0 ,
>> cylinder 0 0.2 0.25;
>> #P window linecount 1;
>> #P newex 430 161 178 196617 jit.gl.sketch t00b1g @capture ouch;
>> #P newex 210 372 162 196617 jit.window sm4llz @size 320 240;
>> #P window linecount 2;
>> #P newex 522 242 224 196617 jit.gl.texture t00b1g @name ouch @dim  
>> 4000 3200;
>> #P window linecount 1;
>> #P message 307 214 57 196617 getcamera;
>> #P toggle 100 271 15 0;
>> #P newex 118 270 29 196617 gate;
>> #P newex 118 295 69 196617 print window;
>> #P message 43 71 42 196617 getsize;
>> #P newex 21 235 127 196617 route size update;
>> #P newex 21 268 72 196617 s window-size;
>> #P comment 43 135 57 196617 16:9 ratio;
>> #P comment 44 95 51 196617 4:3 ratio;
>> #P message 44 150 70 196617 size 320 180;
>> #P message 44 110 70 196617 size 320 240;
>> #P window linecount 3;
>> #P newex 35 174 176 196617 jit.window t00b1g @depthbuffer 1  
>> @fsmenubar 0
>> @noaccel 1 @size 4000 3200 @visible 0;
>> #P user panel 33 60 97 112;
>> #X brgb 184 197 245;
>> #X frgb 149 149 149;
>> #X border 1;
>> #X rounded 5;
>> #X shadow 0;
>> #X done;
>> #P toggle 247 55 15 0;
>> #P window linecount 1;
>> #P newex 247 85 57 196617 qmetro 10;
>> #P newex 287 173 42 196617 t erase;
>> #P newex 247 149 50 196617 gate 2;
>> #P newex 247 118 50 196617 uzi 2;
>> #P newex 247 239 224 196617 jit.gl.render t00b1g @erase_color 0.  
>> 0. 0. 1.;
>> #P fasten 7 1 13 0 187 223 26 223;
>> #P connect 13 0 12 0;
>> #P fasten 9 0 7 0 49 171 40 171;
>> #P fasten 8 0 7 0 49 129 40 129;
>> #P fasten 14 0 7 0 48 90 40 90;
>> #P fasten 13 1 14 0 84 258 199 258 199 63 48 63;
>> #P connect 17 0 16 0;
>> #P connect 16 0 15 0;
>> #P connect 13 2 16 1;
>> #P connect 26 0 25 0;
>> #P connect 25 0 20 0;
>> #P connect 0 0 26 0;
>> #P connect 5 0 4 0;
>> #P connect 4 0 1 0;
>> #P connect 1 2 2 0;
>> #P fasten 18 0 0 0 312 234 252 234;
>> #P connect 2 0 0 0;
>> #P fasten 3 0 0 0 292 195 252 195;
>> #P connect 26 1 24 0;
>> #P connect 24 0 23 0;
>> #P connect 1 0 2 1;
>> #P connect 2 1 3 0;
>> #P connect 22 0 21 0;
>> #P pop;
>>
>>
>>
>>


textures also have an inherant limit of 2048x2048. BTW, I am not 100%

sure about the max context size on OSX as Andreas' post reminded me of

the massive proportions of a triplehead2go. I am however quite

certain about max texture sizes which is obviously going to limit

@capture. Now whether that is still an issue with the software

renderer, I can't say. Are you explicitly setting the texture's

> What about without hardware acceleration? That doesn't seem to work

> for me with the @capture attribute, unless I'm doing something wrong.

> On Jun 4, 2007, at 11:03 PM, Wesley Smith wrote:

> > Yes it's possible with HW acceleration with a amx dim of 2048x2048.

> > On 6/4/07, evan.raskob [lists] wrote:

> >> Is this possible? I've successfully *rendered* to a

> >> larger-than-screen-context on OS X and max 1.6.2b2 (using the

> >> renderer with "noaccell 1" sent to the jit.window) but on 1..6rc1,

> >> trying to capture to a texture larger than the screen (using a

> >> object with the "@capture TEXNAME" set and a jit.gl.texture with

> >> something obscenely large, like 4000x3200) I get errors like

> >> context XXXX" in the max window and a blank screen. When I set

> >> again and resize the textures to the actual screen size in pixels,

> >> Any insight into this, before I go an wrack my brains and spend a

> >> trying out different settings? An example patch showing this

> >> #P newex 210 340 184 196617 jit.matrix readback 4 char 4000 3200;

> >> #P message 274 276 108 196617 glreadpixels readback , bang;

textures also have an inherant limit of 2048x2048.  BTW, I am not 100%
sure about the max context size on OSX as Andreas' post reminded me of
the massive proportions of a triplehead2go.  I am however quite
certain about max texture sizes which is obviously going to limit
@capture.  Now whether that is still an issue with the software
renderer, I can't say.  Are you explicitly setting the texture's
dimension?

On 6/5/07, evan.raskob [lists]  wrote:
> Thanks, good to know.
> What about without hardware acceleration?  That doesn't seem to work
> for me with the @capture attribute, unless I'm doing something wrong.
>
> Thanks
> Evan
>
>
>
> On Jun 4, 2007, at 11:03 PM, Wesley Smith wrote:
>
> > Yes it's possible with HW acceleration with a amx dim of 2048x2048.
> > This is an OSX limitation.
> >
> > wes
> >
> > On 6/4/07, evan.raskob [lists]  wrote:
> >> Is this possible? I've successfully *rendered* to a
> >> larger-than-screen-context on OS X and max 1.6.2b2 (using the
> >> software
> >> renderer with "noaccell 1" sent to the jit.window) but on 1..6rc1,
> >> when
> >> trying to capture to a texture larger than the screen (using a
> >> jit.gl.sketch
> >> object with the "@capture TEXNAME" set and a jit.gl.texture with
> >> @dim set to
> >> something obscenely large, like 4000x3200) I get errors like
> >> "cannot create
> >> context XXXX" in the max window and a blank screen.  When I set
> >> "noaccel 0"
> >> again and resize the textures to the actual screen size in pixels,
> >> the error
> >> goes away and all works.
> >>
> >> Any insight into this, before I go an wrack my brains and spend a
> >> few hours
> >> trying out different settings?  An example patch showing this
> >> error is easy
> >> to whip up:
> >>
> >> max v2;
> >> #N vpatcher 241 536 1132 983;
> >> #P window setfont "Sans Serif" 9.;
> >> #P window linecount 1;
> >> #P newex 215 271 50 196617 t b b;
> >> #P newex 210 340 184 196617 jit.matrix readback 4 char 4000 3200;
> >> #P window linecount 2;
> >> #P message 274 276 108 196617 glreadpixels readback , bang;
> >> #P window linecount 1;
> >> #P newex 274 313 178 196617 jit.gl.sketch t00b1g @automatic 0;
> >> #P window linecount 4;
> >> #P message 427 83 339 196617 reset , glenable cull_face ,
> >> glcullface back
> >> , shapeslices 50 20 , glcolor 0.4 0.4 0 , cylinder 0.05 0.05
> >> 0.5 ,
> >> moveto 0 0 -0.5 , shapeorient 180 0 0 , circle 0.1 , glcolor
> >> 0.3 0.2 1 ,
> >> moveto 0 0 0.5 , circle 0.2 , moveto 0 0 0.75 , shapeorient 0 0
> >> 0 ,
> >> cylinder 0 0.2 0.25;
> >> #P window linecount 1;
> >> #P newex 430 161 178 196617 jit.gl.sketch t00b1g @capture ouch;
> >> #P newex 210 372 162 196617 jit.window sm4llz @size 320 240;
> >> #P window linecount 2;
> >> #P newex 522 242 224 196617 jit.gl.texture t00b1g @name ouch @dim
> >> 4000 3200;
> >> #P window linecount 1;
> >> #P message 307 214 57 196617 getcamera;
> >> #P toggle 100 271 15 0;
> >> #P newex 118 270 29 196617 gate;
> >> #P newex 118 295 69 196617 print window;
> >> #P message 43 71 42 196617 getsize;
> >> #P newex 21 235 127 196617 route size update;
> >> #P newex 21 268 72 196617 s window-size;
> >> #P comment 43 135 57 196617 16:9 ratio;
> >> #P comment 44 95 51 196617 4:3 ratio;
> >> #P message 44 150 70 196617 size 320 180;
> >> #P message 44 110 70 196617 size 320 240;
> >> #P window linecount 3;
> >> #P newex 35 174 176 196617 jit.window t00b1g @depthbuffer 1
> >> @fsmenubar 0
> >> @noaccel 1 @size 4000 3200 @visible 0;
> >> #P user panel 33 60 97 112;
> >> #X brgb 184 197 245;
> >> #X frgb 149 149 149;
> >> #X border 1;
> >> #X rounded 5;
> >> #X shadow 0;
> >> #X done;
> >> #P toggle 247 55 15 0;
> >> #P window linecount 1;
> >> #P newex 247 85 57 196617 qmetro 10;
> >> #P newex 287 173 42 196617 t erase;
> >> #P newex 247 149 50 196617 gate 2;
> >> #P newex 247 118 50 196617 uzi 2;
> >> #P newex 247 239 224 196617 jit.gl.render t00b1g @erase_color 0.
> >> 0. 0. 1.;
> >> #P fasten 7 1 13 0 187 223 26 223;
> >> #P connect 13 0 12 0;
> >> #P fasten 9 0 7 0 49 171 40 171;
> >> #P fasten 8 0 7 0 49 129 40 129;
> >> #P fasten 14 0 7 0 48 90 40 90;
> >> #P fasten 13 1 14 0 84 258 199 258 199 63 48 63;
> >> #P connect 17 0 16 0;
> >> #P connect 16 0 15 0;
> >> #P connect 13 2 16 1;
> >> #P connect 26 0 25 0;
> >> #P connect 25 0 20 0;
> >> #P connect 0 0 26 0;
> >> #P connect 5 0 4 0;
> >> #P connect 4 0 1 0;
> >> #P connect 1 2 2 0;
> >> #P fasten 18 0 0 0 312 234 252 234;
> >> #P connect 2 0 0 0;
> >> #P fasten 3 0 0 0 292 195 252 195;
> >> #P connect 26 1 24 0;
> >> #P connect 24 0 23 0;
> >> #P connect 1 0 2 1;
> >> #P connect 2 1 3 0;
> >> #P connect 22 0 21 0;
> >> #P pop;
> >>
> >>
> >>
> >>
>
>


I am explicitly setting the texture's dims, so I believe that it is 

true that the max texture size for any renderer on os x must be 

I'm pretty sure that the max context size is variable, though, 

because I was able to use glreadpixels to read and save an image from 

a larger-than-screen window rendered via the software-renderer 

(3600x2400 pixels). Although, I can see where the max texture size 

is probably the problem here (for me, anyway).

It just may not be possible to do texture-feedback in this manner, I 

On Jun 5, 2007, at 11:47 AM, Wesley Smith wrote:

> textures also have an inherant limit of 2048x2048. BTW, I am not 100%

> sure about the max context size on OSX as Andreas' post reminded me of

> the massive proportions of a triplehead2go. I am however quite

> certain about max texture sizes which is obviously going to limit

> @capture. Now whether that is still an issue with the software

> renderer, I can't say. Are you explicitly setting the texture's

>> What about without hardware acceleration? That doesn't seem to work

>> for me with the @capture attribute, unless I'm doing something wrong.

>> On Jun 4, 2007, at 11:03 PM, Wesley Smith wrote:

>> > Yes it's possible with HW acceleration with a amx dim of 2048x2048.

>> > On 6/4/07, evan.raskob [lists] wrote:

>> >> Is this possible? I've successfully *rendered* to a

>> >> larger-than-screen-context on OS X and max 1.6.2b2 (using the

>> >> renderer with "noaccell 1" sent to the jit.window) but on 1..6rc1,

>> >> trying to capture to a texture larger than the screen (using a

>> >> object with the "@capture TEXNAME" set and a jit.gl.texture with

>> >> something obscenely large, like 4000x3200) I get errors like

>> >> context XXXX" in the max window and a blank screen. When I set

>> >> again and resize the textures to the actual screen size in pixels,

>> >> Any insight into this, before I go an wrack my brains and spend a

>> >> trying out different settings? An example patch showing this

I am explicitly setting the texture's dims, so I believe that it is  
true that the max texture size for any renderer on os x must be  
2048x2048.

I'm pretty sure that the max context size is variable, though,  
because I was able to use glreadpixels to read and save an image from  
a larger-than-screen window rendered via the software-renderer  
(3600x2400 pixels).  Although, I can see where the max texture size  
is probably the problem here (for me, anyway).

It just may not be possible to do texture-feedback in this manner, I  
guess.

> textures also have an inherant limit of 2048x2048.  BTW, I am not 100%
> sure about the max context size on OSX as Andreas' post reminded me of
> the massive proportions of a triplehead2go.  I am however quite
> certain about max texture sizes which is obviously going to limit
> @capture.  Now whether that is still an issue with the software
> renderer, I can't say.  Are you explicitly setting the texture's
> dimension?
>
> wes
>
> On 6/5/07, evan.raskob [lists]  wrote:
>> Thanks, good to know.
>> What about without hardware acceleration?  That doesn't seem to work
>> for me with the @capture attribute, unless I'm doing something wrong.
>>
>> Thanks
>> Evan
>>
>>
>>
>> On Jun 4, 2007, at 11:03 PM, Wesley Smith wrote:
>>
>> > Yes it's possible with HW acceleration with a amx dim of 2048x2048.
>> > This is an OSX limitation.
>> >
>> > wes
>> >
>> > On 6/4/07, evan.raskob [lists]  wrote:
>> >> Is this possible? I've successfully *rendered* to a
>> >> larger-than-screen-context on OS X and max 1.6.2b2 (using the
>> >> software
>> >> renderer with "noaccell 1" sent to the jit.window) but on 1..6rc1,
>> >> when
>> >> trying to capture to a texture larger than the screen (using a
>> >> jit.gl.sketch
>> >> object with the "@capture TEXNAME" set and a jit.gl.texture with
>> >> @dim set to
>> >> something obscenely large, like 4000x3200) I get errors like
>> >> "cannot create
>> >> context XXXX" in the max window and a blank screen.  When I set
>> >> "noaccel 0"
>> >> again and resize the textures to the actual screen size in pixels,
>> >> the error
>> >> goes away and all works.
>> >>
>> >> Any insight into this, before I go an wrack my brains and spend a
>> >> few hours
>> >> trying out different settings?  An example patch showing this
>> >> error is easy
>> >> to whip up:
>> >>
>> >> max v2;
>> >> #N vpatcher 241 536 1132 983;
>> >> #P window setfont "Sans Serif" 9.;
>> >> #P window linecount 1;
>> >> #P newex 215 271 50 196617 t b b;
>> >> #P newex 210 340 184 196617 jit.matrix readback 4 char 4000 3200;
>> >> #P window linecount 2;
>> >> #P message 274 276 108 196617 glreadpixels readback , bang;
>> >> #P window linecount 1;
>> >> #P newex 274 313 178 196617 jit.gl.sketch t00b1g @automatic 0;
>> >> #P window linecount 4;
>> >> #P message 427 83 339 196617 reset , glenable cull_face ,
>> >> glcullface back
>> >> , shapeslices 50 20 , glcolor 0.4 0.4 0 , cylinder 0.05 0.05
>> >> 0.5 ,
>> >> moveto 0 0 -0.5 , shapeorient 180 0 0 , circle 0.1 , glcolor
>> >> 0.3 0.2 1 ,
>> >> moveto 0 0 0.5 , circle 0.2 , moveto 0 0 0.75 , shapeorient 0 0
>> >> 0 ,
>> >> cylinder 0 0.2 0.25;
>> >> #P window linecount 1;
>> >> #P newex 430 161 178 196617 jit.gl.sketch t00b1g @capture ouch;
>> >> #P newex 210 372 162 196617 jit.window sm4llz @size 320 240;
>> >> #P window linecount 2;
>> >> #P newex 522 242 224 196617 jit.gl.texture t00b1g @name ouch @dim
>> >> 4000 3200;
>> >> #P window linecount 1;
>> >> #P message 307 214 57 196617 getcamera;
>> >> #P toggle 100 271 15 0;
>> >> #P newex 118 270 29 196617 gate;
>> >> #P newex 118 295 69 196617 print window;
>> >> #P message 43 71 42 196617 getsize;
>> >> #P newex 21 235 127 196617 route size update;
>> >> #P newex 21 268 72 196617 s window-size;
>> >> #P comment 43 135 57 196617 16:9 ratio;
>> >> #P comment 44 95 51 196617 4:3 ratio;
>> >> #P message 44 150 70 196617 size 320 180;
>> >> #P message 44 110 70 196617 size 320 240;
>> >> #P window linecount 3;
>> >> #P newex 35 174 176 196617 jit.window t00b1g @depthbuffer 1
>> >> @fsmenubar 0
>> >> @noaccel 1 @size 4000 3200 @visible 0;
>> >> #P user panel 33 60 97 112;
>> >> #X brgb 184 197 245;
>> >> #X frgb 149 149 149;
>> >> #X border 1;
>> >> #X rounded 5;
>> >> #X shadow 0;
>> >> #X done;
>> >> #P toggle 247 55 15 0;
>> >> #P window linecount 1;
>> >> #P newex 247 85 57 196617 qmetro 10;
>> >> #P newex 287 173 42 196617 t erase;
>> >> #P newex 247 149 50 196617 gate 2;
>> >> #P newex 247 118 50 196617 uzi 2;
>> >> #P newex 247 239 224 196617 jit.gl.render t00b1g @erase_color 0.
>> >> 0. 0. 1.;
>> >> #P fasten 7 1 13 0 187 223 26 223;
>> >> #P connect 13 0 12 0;
>> >> #P fasten 9 0 7 0 49 171 40 171;
>> >> #P fasten 8 0 7 0 49 129 40 129;
>> >> #P fasten 14 0 7 0 48 90 40 90;
>> >> #P fasten 13 1 14 0 84 258 199 258 199 63 48 63;
>> >> #P connect 17 0 16 0;
>> >> #P connect 16 0 15 0;
>> >> #P connect 13 2 16 1;
>> >> #P connect 26 0 25 0;
>> >> #P connect 25 0 20 0;
>> >> #P connect 0 0 26 0;
>> >> #P connect 5 0 4 0;
>> >> #P connect 4 0 1 0;
>> >> #P connect 1 2 2 0;
>> >> #P fasten 18 0 0 0 312 234 252 234;
>> >> #P connect 2 0 0 0;
>> >> #P fasten 3 0 0 0 292 195 252 195;
>> >> #P connect 26 1 24 0;
>> >> #P connect 24 0 23 0;
>> >> #P connect 1 0 2 1;
>> >> #P connect 2 1 3 0;
>> >> #P connect 22 0 21 0;
>> >> #P pop;
>> >>
>> >>
>> >>
>> >>
>>
>>


FWIW, max_viewport_dims and max_texture_size are HW dependent. Many 

cards for OS X support 4096x4096 for both, but only the software 

renderer on OS X supports really large possibilities 16384x16384

http://homepage.mac.com/arekkusu/bugs/GLInfo.html

For Windows XP, or to query yourself on OS X, see GLView or GL 

Of course you can also render in slices, which may work properly for you 

if you set up your viewport/frustum/modelview transformation matrix just 

right using jit.gl.sketch. Check Google/RedBook for more info:

http://www.google.com/search?q=tile+rendering+OpenGL

FWIW, max_viewport_dims and max_texture_size are HW dependent. Many 
cards for OS X support 4096x4096 for both, but only the software 
renderer on OS X supports really large possibilities 16384x16384
http://homepage.mac.com/arekkusu/bugs/GLInfo.html

For Windows XP, or to query yourself on OS X, see GLView or GL 
Extensions Wrangler:
http://www.realtech-vr.com/glview/
http://glew.sourceforge.net/

Of course you can also render in slices, which may work properly for you 
if you set up your viewport/frustum/modelview transformation matrix just 
right using jit.gl.sketch. Check Google/RedBook for more info:

So, does this mean that the behavior I've noticed is a bug? Am I 

properly using the software renderer in my original patch in this 

thread, or is there a problem with capturing to textures using the 

software renderer, above a certain size? On my Powerbook (Radeon 

X1600 256MB ram) I've seen that 2048x2048 is the max size of a 

texture I can capture to using either the hardware renderer or 

I'd really like to avoid rendering in slices... that would be awful.

On Jun 6, 2007, at 3:12 AM, andrew benson wrote:

> FWIW, max_viewport_dims and max_texture_size are HW dependent. Many 

> cards for OS X support 4096x4096 for both, but only the software 

> renderer on OS X supports really large possibilities 16384x16384

> For Windows XP, or to query yourself on OS X, see GLView or GL 

> Of course you can also render in slices, which may work properly 

> for you if you set up your viewport/frustum/modelview 

> transformation matrix just right using jit.gl.sketch. Check Google/ 

So, does this mean that the behavior I've noticed is a bug?  Am I  
properly using the software renderer in my original patch in this  
thread, or is there a problem with capturing to textures using the  
software renderer, above a certain size?  On my Powerbook (Radeon  
X1600 256MB ram) I've seen that 2048x2048 is the max size of a  
texture I can capture to using either the hardware renderer or  
software renderer.

> Hello,
>
> FWIW, max_viewport_dims and max_texture_size are HW dependent. Many  
> cards for OS X support 4096x4096 for both, but only the software  
> renderer on OS X supports really large possibilities 16384x16384
> http://homepage.mac.com/arekkusu/bugs/GLInfo.html
>
> For Windows XP, or to query yourself on OS X, see GLView or GL  
> Extensions Wrangler:
> http://www.realtech-vr.com/glview/
> http://glew.sourceforge.net/
>
> Of course you can also render in slices, which may work properly  
> for you if you set up your viewport/frustum/modelview  
> transformation matrix just right using jit.gl.sketch. Check Google/ 
> RedBook for more info:
>
> http://www.google.com/search?q=tile+rendering+OpenGL
>
> Best,
> Andrew B.


how to capture to texture larger than screen?