site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=YB0UHcKyySVaQZhZjp7+t+1B1WMHDuLpWKqOrQ1LPGo=; b=fzuLzdc7r8xGUDr8DEDI6okJ783fIkAgH8+u1ivhHbtVgAstEbYcCKG2H8ESBwjJMp 6JM2Z0t2+/iU05E+ElVcrC8s1wPA+z3XXOC0AJFU3oHXMf9QVYlYEdxZJjmbkSpW3bFz 7kJAOSsq0yLAy56Wj/ct7vXgQmzxKi1RYF144= Hi list, It appears there are some inconsistencies in respect to the data that is fed down to plugins under various circumstances when called from Final Cut Pro X.  This concerns only GPU rendering. I see two scenarios when my plugin is called from Final Cut: 1. Expected behavior. Happens prior to rendering, say while I change parameters in my plugin UI and if I export when NO pre-rendered data is available (say if flush optimized media and turn background rendering OFF and export to H.264) - In this case renderOutput:withInput:withInfo: gets called with the following: FxTexture input depth = 16 FxTexture output depth = 16 FxRenderInfo.depth = kFxDepth_FLOAT16 Binding the input texture and doing a glGetTexLevelParameteriv(… GL_TEXTURE_INTERNAL_FORMAT…) reveals that the Internal format of the input texture handed down to renderOutput: is GL_RGBA32F_ARB. In my fragment shader I see the data that I expect; that is, super-white values over 1.0 etc.. In short, everything behaves as expected. Motion 5 everything behaves similar to above expected behavior both during playback/editing and exporting. 2. Unexpected behavior. This is where things gets strange… This happens (only?) when the plugin is called during background rendering. Here renderOutput:withInput:withInfo: gets called with the following: FxTexture input depth = 32 FxTexture output depth = 32 FxRenderInfo.depth = kFxDepth_FLOAT32 However, glGetTexLevelParameteriv(… GL_TEXTURE_INTERNAL_FORMAT…) reveals that the internal format of the texture is GL_RGBA8_EXT... (8bit pr channel...) In addition, in my fragment shader I see mostly the same data as in the 1st case but the over-range > 1.0 (i.e. super-white etc.) data is being truncated/clamped to 1.0… which is not the way its supposed to work.. I hope! :-) Any insights or workaround for this problem is highly appreciated. If not, I hope its something that can be addressed in an upcoming update. Cheers, Michael Rig: MacBookPro8,2 / Radeon HD 6750M / MacOSX 10.6.8. _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.ap... This email sent to site_archiver@lists.apple.com