|
|
possible Read Pixel bug and/or newby dullardness hi all, just discovered the 'read pixel' patch which will help me immensely. there seems to be a problem is when i 'full screen' the viewer in 4 x 3 aspect ratio, the sprite/billboard rendering the 'reading' is offset to the rights by a number of units. attached is an example illustrating this. in 4 x3 mode non-full screen the two images are in the same position and then in full screen they are not. does this happen for anyone else? why is this? is there a fix? thanks as always for the incredible patches. r.
|
Don't set to a fixed ratio seemed to clear up a lot of positional stuff you complained off. Set to 16:9 in the Viewer window results in an interesting variation on the reported behaviour.
However the only solution to your problem as far as I could make out is to give the sprites a square dimension and then let the positions and full screening take care of itself.
See attached reworking.
hmm, very interesting.
ideally i would like to able to use this patch in a viewer with fixed ratio... i usually stack up compositions and full screen to a projector out and many others i use depend on the 4:3 aspect ratio.
kineme folks? any thoughts?
thanks for your help.
r
Have you, like, actually tried it on an actual 4:3 screen? I'm pretty sure it won't matter if the screen's dimensions actually are what the forced aspect ratio is.
Looks like it's grabbing pixels from the unused margin -- I'm not sure why that is, but I'll take a look at fixing it for the next beta.
I've isolated the issue, and fixed it. The next beta of GLTools will have this fixed. (no eta at this time)
awesome.
any chance of sending that patch to a loyal kineme user working on a tight deadline? :)
from https://kineme.net/users/grapejuice: member for 9 weeks, 6 days -- hardly long enough to be considered loyal (compared to https://kineme.net/users/franz, for example) ;) [I jest]
Should be in your mail box -- I still think just having the projector actually set to 4:3 will make it work happily anyway though (as a work-around).
thank you x 1000.
in my non JS/GL able Quartz Composing world that Read Pixel patch is a game changer.
does using kineme tools to melt the faces of several thousand festival goers simultaneously over the next few weeks up my loyalty cred? :)
r.
Only if you post pics/videos when you're done ;)
i'll see what i can do!
?
Why can't you just use the straight video output to melt faces?
Interesting. It will be cool to see the what and why of how the read pixel comes into play.
i don't actually use any 'video' in my comps - it's all live modulated animation.
so for instance i might have several line based images outputting to billboards which all rotate around creating moire patterns and interference with each other.
with 'read pixel' i can then take the output of all the previous renderers and send the sum to an iterator to make feedback type effects etc. it's sort of like a 'video out' for my images.
i will again emphatically state my amateur status - there is probably a much more 'pro' way to do this - there's that intimidating looking 'core image accumulator' thing people seem to use - but i haven't got that far yet... ergo, read pixel. :)
r!
and so, by a wee ironic happen-chance, you end up using a KIneme's Read Pixel, which is like even more experimental / pro.
It may have an intimidating title , but Core Image Accumulator is a brilliant, though interface wise slightly counter intuitive patch to work with.
Definitely worth exploring and experimenting with, grapejuice.
Does tend to require either a Render in Image or an Image outputting patch
Cool... In a weird case of our paths overlapping, I was totally investigating the Droste effect and Escher patterns and was doing an infinite tunnel using read pixels last night! Then I backed off and stared down an image filter route.
So you mean that the visuals you are going to show are going to make people's brains melt... or maybe faces as well :)