On Sat, Oct 29, 2011 at 9:04 PM, vade <[email protected]> wrote:
> 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?
>
I'm not trying for magic :-)
I set the image metadata to GL_TEXTURE_2D first. Then, one could call
GL_REPEAT (or not), and there's no errors, and everything is fine. One
hasn't actually needed to call GL_REPEAT, it's "just happened" as a freebie
when setting image metadata to GL_TEXTURE_2D, in the past. If you choose to
do so, all is well, and you can also go and clamp the image, if you don't
like the default repeat function (in Leopard and SL).
As I'm thinking more and more about it, and because of your comment about
texture target, it occurs to me that I'll try skipping the metadata route
and after setting the context, manually set the texture, target, mipmapping
levels, etc. I feel like that route is more likely to work. I guess I could
get into binding the texture representation to cgl context manually, but
I'm unsure if that would help either. I feel like I'll keep backing away
from the QC convenience stuff until it works.... or just cave in and use
Image Texturing Properties, but at this point, I'm just curious and want to
solve it.
> 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..).
>
I'm not sure about the mechanics behind it, but adding the GL_TEXTURE_2D
metadata has been enough to make any image texture repeat, regardless of
the metadata on the input at the input port. At least, until now.
>
> 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.
>
Again, not "reading" the texture as 2D, "setting" it to 2D.
>
> So, perhaps just 'swizzle' the image type to 2D via Image Texture
> Properties patch and see if that works for you.
>
Yeah, that's where I originally got the idea.
>
> 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.
>
In more testing, I see that the split second I enable the GL_TEXTURE_2D in
Lion, tiling occurs perfectly, then it goes blank. I think that I need to
back down (or up?... I get confused on the semantics) a level, and be
manually specifying something like "withTarget: GL_TEXTURE_2D" once I've
set the image context, instead of doing it on the metadata of the input
image port.
>
> 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 ;)
>
>
I'm not sure exactly what you mean by "crash caused by the runtime". I
could refer you to some standard API plugins that will crash QC, or just do
horrible things to GL state. The same goes for someone using the skankySDK
- they could code something that just isn't right. I don't think one is
inherently less stable than the other, over the course of the past years.
My point is more that, I seem to observe that Apple uses a decent amount of
GFPlugins in their own apps, so if something breaks with it, it would seem
to be a priority. Also, Chris Wright, who wrote the SkankySDK, works at
Apple, and I'd imagine that this would have to flavor development. Thirdly,
the SkankySDK is just a reverse engineer of what QC *is*, from using tools
like class dump. In that sense, it's sort of hard for it to be "wrong",
though one can code incorrectly or lazily, not pay attention to differences
between the 32 and 64 bit runtimes when coding, take dangerous liberties
with ports, etc. On the other side, QCPlugins haven't been updated to be
able to use some fundamental QC types, you can't make environments, and I
just don't feel (speculation) that it matters much if anything in it
breaks. How many major products use it? Not many.
All that said, I don't mean that as a slag to anyone that uses the standard
API. There are obvious pros and cons to each, and I think it just makes
sense to be pragmatic about it. If I had to do something that was standard
API, I'd be using it, and it wouldn't be horrible. I don't really find many
"gotchas" to the GFPlugin approach at all - if something is different or
changes, there's usually a way to write around it (not always of course).
The QCPlugin api doesn't always allow that flexibility.
-gt
>
> 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 <[email protected]>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 <[email protected]>wrote:
>>
>>>
>>>
>>> On Sat, Oct 29, 2011 at 5:15 PM, vade <[email protected]> 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 <[email protected]>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 <[email protected]>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 (
>>>> [email protected])
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>> http://lists.apple.com/mailman/options/quartzcomposer-dev/doktorp%40mac.com
>>>>
>>>> This email sent to [email protected]
>>>>
>>>>
>>>>
>>>
>>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Quartzcomposer-dev mailing list ([email protected])
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/quartzcomposer-dev/doktorp%40mac.com
>
> This email sent to [email protected]
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Quartzcomposer-dev mailing list ([email protected])
> Help/Unsubscribe/Update your Subscription:
>
> http://lists.apple.com/mailman/options/quartzcomposer-dev/gtoledo3%40gmail.com
>
> This email sent to [email protected]
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com
This email sent to [email protected]
