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/archive%40mail-archive.com This email sent to [email protected]
