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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
