From 3964e2714e9672fb4a45c8a16a96153ab7cae05b Mon Sep 17 00:00:00 2001 From: Hans-Christoph Steiner Date: Wed, 27 Aug 2008 22:27:30 +0000 Subject: merged in relevant changes from the v0-40 pd-extended release branch svn path=/trunk/externals/pdp/; revision=10266 --- opengl/doc/objects/3dp_snap-help.pd | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 opengl/doc/objects/3dp_snap-help.pd (limited to 'opengl/doc/objects/3dp_snap-help.pd') diff --git a/opengl/doc/objects/3dp_snap-help.pd b/opengl/doc/objects/3dp_snap-help.pd new file mode 100644 index 0000000..261ac4f --- /dev/null +++ b/opengl/doc/objects/3dp_snap-help.pd @@ -0,0 +1,13 @@ +#N canvas 23 127 436 363 10; +#X text 38 16 couping 3dp and pdp can be done using 3dp_snap and pdp_convert. +the correct way to do it is to put 3dp_snap in a rendering chain and +give it arguments like this: [3dp_snap image/*/* 320 240] if you specify +the subtype to be image/multi/* \, the packet will not be colour space +converted: it will stay rgb. if you want to make a snapshot to store +as a high quality png image \, snap to bitmap/rgb/* and store it in +pdp_reg to save. to convert an image back to a texture \, use [pdp_convert +texture/*/*] if you snap to a texture (which is the default) the dimensions +don't need to be specified. a texture will be allocated that can contain +the entire screen. this is because texture coordinates are relative +and data is always interpolated. snapping only works correctly when +the window is not covered by other windows.; -- cgit v1.2.1