If the input image type is not GL_TEXTURE_2D, you cannot magically apply
GL_REPEAT for the texture wrap parameter, its is invalid, and will throw a GL
Error. Perhaps ensure that the texture target is GL_TEXTURE_2D by using the
supplied image texturing properties patch?
You cannot treat a GL_TEXTURE_RECTANGLE_EXT type texture as a GL_TEXTURE_2D, or
apply any pertaining texture properties to it..Unless the metadata API / QC
Skank SDK does an additional render to texture pass setting the final output as
GL_TEXTURE_2D, (then technically speaking its a different image..).
So, considering most patches (Core Image, Render to Image by default), all Core
Video based patches (Movie Importer, Video Input) and the Image Input patch all
deliver GL_TEXTURE_RECTANGLE.. its not going to be prudent to assume you can
just treat the input as 2D. Most cases, it wont be.
So, perhaps just 'swizzle' the image type to 2D via Image Texture Properties
patch and see if that works for you.
The only thought I might have on how this metadata is handled in the back
end/runtime is that the upstream patches see the requested 2D format and change
their FBO render target to 2D in cases where QC controls the image buffer, but
that doesn't necessarily help you when you are passed images from other sources
that can only be Rect.
Good luck.
I am tempted to take you to task about the 3rd party plugin API not being
'stable' ? I've never seen a crash caused by the runtime... And have seen
plenty caused by skank SDk plugins ;)
On Oct 29, 2011, at 6:05 PM, George Toledo wrote:
> Hmm, I am setting the metadata directly instead of something like this
> first...
>
> if([inputImage imageValue] != nil)
> {
> id image = [inputImage imageValue];
> etc...
>
> I'll look at it more, and thanks for the thoughts Vade.
>
> On Sat, Oct 29, 2011 at 5:53 PM, George Toledo <gtole...@gmail.com> wrote:
> I realize part of my explanation was unclear (or maybe in explanation for WHY
> it has these functions). If I'm rendering a bunch of 3D objects of rabbits,
> it can be convenient to have a different texture on each one, but GL_REPEAT
> isn't needed at all in that context. If I'm rendering a bunch of planes, I
> may want to change the image texture scale, and then be able to take
> advantage of the GL_REPEAT effect (because tiling on a bunch of sprites looks
> so darn cool and modern).
>
>
> On Sat, Oct 29, 2011 at 5:43 PM, George Toledo <gtole...@gmail.com> wrote:
>
>
> On Sat, Oct 29, 2011 at 5:15 PM, vade <dokt...@me.com> wrote:
> You have no control over how the target consumer patch is going to handle
> rendering, or if it is going to override any GL state on texture unit 0, or
> for that Gluint texture ID. Just because you set an image to have a
> particular parameter does not mean downstream consumers cant change those
> values, or that intermediate image processing patches, be it GLSL or Core
> Image Units wont change the associated parameter, on the original or on its
> new resulting output texture.
>
>
> No, this is a consumer patch. I'm taking the input image and setting the
> metadata to GL Texture 2D, and texture repeat. There's nothing downstream at
> all, n/a.
>
>
> Why not just tile where you need to tile, while rendering
>
> Are you rendering something in this patch (ie, consumer, writing vertex data
> to the GL Scene), or are you just tagging metadata on an input image and
> sending it back out and on its way?
>
> This is a consumer patch that renders multiple objects.
>
> I'm taking QCStruct or NSArray, and using that to dictate vector positions.
> Then I'm using another input to dictate geometry, whether it be raw
> QCStructures or Kineme3D Object types.
>
> I have an image port, and an image structure port. If image comes from the
> image port, every item is textured identically. If I use the structure port,
> each object can get a different texture.
>
> The reason to control repeat inside of the plugin, is that if you're already
> feeding video to a bunch of pips, and are feeding keyed data that established
> the placement of the pips, it's really easy to pass more parameters to
> control the texture offsets - but it has to happen IN the patch. Well... the
> offsetting will work if one has placed an image texturing properties, set to
> 2D target, but I'd like to maintain the way this has worked in Leopard, and
> Snow Leopard, at least function-wise.
>
>
> The internal QC image pipeline is probably going to change, as the runtime
> version is now 4.5 (and will most likely change in subtle ways in 5.0, etc).
> This is the whole reason the internal state mechanisms of QC are meant to be
> internal, so bugs can be fixed and isolated from 3rd party developers.
> Perhaps you relied on a bug, or unsupported behavior in 4.0, and now 4.5 has
> fixed internal bugs, resulting in different behavior? I dont know, and,
> strictly speaking neither *should* you, because this is internal to the QC
> runtime, and not for your eyes.
>
>
> I understand the preaching, but if this has changed and doesn't work, I'm
> certain that other patches have been affected, and likely Apple ones. I'm not
> confident that this has been recognized, or was even intended. I would guess
> it's likely not known and totally unintended, if I had to bet.
>
> How about explaining what you are trying to accomplish? Of course, I know,
> there are still things 3rd party plugins using vanilla API can't accomplish.
> That sucks, but it is stable, and does work as intended (except, you know,
> that whole port ordering issue, the execution time parameter bug and, well
> some other stuff, har).
>
> ;)
>
>
> Agree to disagree. :-) The vanilla API isn't so stable, it's barely used by
> Apple so it gets absolutely no love, and it has some major bugs (port order,
> rendering time, lack of qc types). On the flip side, QC Lion was worked on by
> the same person that made the SkankySDK, new patches are skanky, etc.
>
> The one thing that's hackish is assuming that when a texture is set on
> context, that it's bound, and that's not "on" the SkankySDK, so to speak. I
> thought it was gnarly when I originally did it. Now, it was originally pretty
> hackish to stop at GL_TEXTURE_2D once GL_REPEAT started happening on it's own.
>
> Also, I'd use the vanilla api, but I'm using custom ports to read the K3D
> objects and QCMesh.
>
>
> On Oct 29, 2011, at 4:39 PM, George Toledo wrote:
>
>> So, I'm testing more. To recap, in SL, it used to be that setting the
>> metadata of the image to be a 2D texture would automatically put the image
>> in a mode where it was in GL_REPEAT.
>>
>> In SL, what was in the last post can be boiled down to:
>>
>> if([inputGLTEXTURE2D booleanValue])
>> {
>> [[inputImage
>> imageValue]setMetadata:[NSNumber numberWithInt:GL_TEXTURE_2D]
>> forKey:@"textureTarget" shouldForward:YES];
>> }
>> [inputImage setOnOpenGLContext: context
>> unit:GL_TEXTURE0];
>>
>> //glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
>>
>> //glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
>> glTexParameteri(GL_TEXTURE_2D,
>> GL_TEXTURE_WRAP_S, GL_REPEAT);
>> glTexParameteri(GL_TEXTURE_2D,
>> GL_TEXTURE_WRAP_T, GL_REPEAT);
>>
>> //glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_R, GL_REPEAT);
>>
>> }
>>
>> To get it working, and have "tiling" repeat effect.
>>
>> Now, since just making the image 2D to begin with gives the GL_REPEAT
>> freebie, I've reconfirmed this by testing:
>>
>> if([inputGLTEXTURE2D booleanValue])
>> {
>> [[inputImage
>> imageValue]setMetadata:[NSNumber numberWithInt:GL_TEXTURE_2D]
>> forKey:@"textureTarget" shouldForward:YES];
>> }
>> [inputImage setOnOpenGLContext: context
>> unit:GL_TEXTURE0];
>>
>> //glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
>>
>> //glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
>> glTexParameteri(GL_TEXTURE_2D,
>> GL_TEXTURE_WRAP_S, GL_CLAMP);
>> glTexParameteri(GL_TEXTURE_2D,
>> GL_TEXTURE_WRAP_T, GL_CLAMP);
>>
>> //glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_R, GL_REPEAT);
>>
>> }
>>
>> This, as expected in Snow Leopard, results in a clamped texture.
>>
>> By this process of elimination, I'm pretty darn sure I'm calling my
>> parameters in the correct place, and the correct way. This is making me feel
>> like there has been a regression in the QC Image pipeline that's likely to
>> effect more patches negatively, but I'm not 100% sure about that of course.
>>
>> Again, any thoughts or help are greatly appreciated. As is, I think this is
>> a bug, but since I'm using GFPlugin, I can't really file.
>>
>> Best,
>> gt
>>
>> On Sat, Oct 29, 2011 at 4:26 PM, George Toledo <gtole...@gmail.com> wrote:
>> So, I'm trying more, and this won't work either - well, it works fine in SL,
>> but produces no output in Lion.
>>
>> if([inputGLTEXTURE2D booleanValue])
>> {
>> [[inputImage
>> imageValue]setMetadata:[NSNumber numberWithInt:GL_TEXTURE_2D]
>> forKey:@"textureTarget" shouldForward:YES];
>> }
>> [inputImage setOnOpenGLContext: context
>> unit:GL_TEXTURE0];
>> glTexParameteri(GL_TEXTURE_2D,
>> GL_TEXTURE_MIN_FILTER, GL_LINEAR);
>> glTexParameteri(GL_TEXTURE_2D,
>> GL_TEXTURE_MAG_FILTER, GL_LINEAR);
>> glTexParameteri(GL_TEXTURE_2D,
>> GL_TEXTURE_WRAP_S, GL_REPEAT);
>> glTexParameteri(GL_TEXTURE_2D,
>> GL_TEXTURE_WRAP_T, GL_REPEAT);
>> glTexParameteri(GL_TEXTURE_2D,
>> GL_TEXTURE_WRAP_R, GL_REPEAT);
>>
>> }
>>
>>
>> This seems like it should work, because I'm setting the metadata to 2D
>> texture, then after the texture context is set, I'm trying to pass the
>> parameters.
>>
>> I've wondered if I should be using glTexParameterf, but I wouldn't think
>> that would be making the difference here.
>>
>> I'm kind of worried, because it's feeling like maybe one can't make any
>> assumptions that when texture is set on context, that it's bound. Or maybe
>> it's just a stupid error here, but as said, both work in SL, but not Lion.
>> Any help is greatly appreciated.
>>
>> I'm guessing I can just treat the image with "Image Texturing Properties"
>> ahead of time if needed, but it's not as eloquent as having that happen
>> inside of the patch, and it's problematic to pass the output of Image
>> Texturing Properties to some things, so this has been great to be able to
>> have happen in the past.
>>
>> On Sat, Oct 29, 2011 at 2:34 PM, George Toledo <gtole...@gmail.com> wrote:
>> In Leopard and SL, I was able to make image into a QC Image port do GL
>> Repeat by doing something like this:
>>
>> if([inputGLTEXTURE2D booleanValue])
>> {
>> [[inputImage imageValue]setMetadata:[NSNumber numberWithInt:GL_TEXTURE_2D]
>> forKey:@"textureTarget" shouldForward:YES];
>> }
>> [inputImage setOnOpenGLContext: context unit:GL_TEXTURE0];
>> }
>>
>>
>> For some reason, this has broken in Lion. What's the quickest way for me to
>> get this going again, and is this a bug? I understand I'm not going "all the
>> way" and specifying the repeat, but this used to "just work". What's the
>> proper way to set the metadata to get the repeat? I'm not using the standard
>> API, so I take my lumps on that one, but any help would be great.
>>
>> -gt
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/quartzcomposer-dev/doktorp%40mac.com
>>
>> This email sent to dokt...@mac.com
>
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/quartzcomposer-dev/doktorp%40mac.com
>
> This email sent to dokt...@mac.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
