diff options
Diffstat (limited to 'opengl/README')
| -rw-r--r-- | opengl/README | 239 |
1 files changed, 0 insertions, 239 deletions
diff --git a/opengl/README b/opengl/README deleted file mode 100644 index fb756b3..0000000 --- a/opengl/README +++ /dev/null @@ -1,239 +0,0 @@ -pdp_opengl (3dp): opengl extensions for pdp -warning: this is still experimental and incomplete - -this library extends pdp with texture and render context packets, -to use some of the power of current video hardware. - -it is very much like gem (sort of a redesign, filled with my own -idiosyncrasies). gem, like it is now, is not very suited for interaction -with pdp image processing because of its hardcoded window centric rendering, -so i thought i'd write some gem like stuff on top of pdp myself. (3dp right -now only supports window centric rendering itself, but adding pbuffer -or pixmap rendering is easy enough, though it requires a rather new glx -library) - -so, 3dp is an experimental gem clone with tight pdp integration. unless -you like experiments, use gem, since it is better supported, has more -features and runs on linux, windows and mac osx. - -requires glx (opengl on x window). - -building: - -edit Makefile.config to reflect your system and run make. the library is -pdp_opengl.pd_linux - -some of the examples use the abstractions in opengl/abstractions. best to -add this to your pd path. - - -there are some fatal X bugs floating around, so be careful with resizing -windows and closing patches. there are a lot of other, non-fatal bugs -or badly implemented features. if you have remarks, just let me know. - - -i'll move to autoconf once i no longer consider it experimental. - - -TIPS & TRICKS - - -* the 3dp_windowcontext creates a window to draw in. the window packet -will be be output to the left outlet when a bang is received. control -flow for context is right to left, this means if a 3dp object has 2 -context outlets, the rightmost will be propagated before the leftmost. -there is no fanout. all operations are accumulative, including the -geometric transformations. if you need to branch use a 3dp_push object. - - -* geometric transformations can be done using the 3dp_view object. -the first argument is the kind of transformation: scale, scalex, -scaley, scalez, rotx, roty, rotz, rota, transx, transy, transz, -transxyz. - -repectively this scales the object, the x, y, z axis, rotates -around the x, y, z axis, rotates around an arbitrary axis, translates -in the x, y, z directions and translates along a vector. the initial -parameters can be specified as creation arguments, i.e.: - -[3dp_view rota 1 1 1 90] rotates by 90 degrees around axis (1,1,1). - - -* some simple objects can be drawn using the pdp_draw object. the -first argument is the object: square, cube, sphere, torus, cone, -teapot, dodeca, icosa, octa, tetra. prepending the names with a w -draws the wireframe version. (i.e. wcube is a wireframe cube). the -first inlet of the object is a texture inlet. not all objects support -this, but cube, square and sphere do. other inlets set some parameters -like size, nb of segments for sphere, etc.. they can be specified -by creation arguments too. - - -* saving a (matrix) state can be accomplished by the 3dp_push object. -the default matrix is the modelview matrix. it works as follows: both -the right and the left outlet propagate the same matrix state as the -input. so in short you can use 3dp_push to split your rendering tree -into parallel branches. the matrix types that can be pushed are: -modelview, texture, color, projection. - -* setting a current matrix can be done using the 3dp_mode object. -i.e. [3dp_mode texture] will map all geometric transforms to the -texture matrix, for texture coordinate animation. the left outlet -restores the current matrix back to the modelview matrix. - -* it is possible to send a render context trough a drawing/view -transforming object multiple times. the easy way is to use 3dp_for, -but other ways are legal too. this can be done to draw different -versions of the same object. have a look at example01 how this can -be done. - -it is also possible to send multiple render contexts trought the same -rendering tree (i.e. multiple windows). if you use different viewing -transformations on the top of the rendering chain, you can view a scene -trough different angles. - - -* light sources can be introduces using 3dp_light. they can be moved -with oridinary 3dp_view objects. - - -* 3dp_color changes the current color. right outlet is new color, -left outlet is the previous color. - -* 3dp_toggle toggles a boolean opengl switch. enabled now are: -depth_test, blend_add, blend_mix. more to come later. - - - -* 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. - - -* textures can have any dimensions, but only those which have -dimensions that are integral powers of two will be tiled correctly. -i.e. by using pdp_mode to change to texture mode and doing some -coordinate transforms using pdp_view (see example06: this -uses a tilable animated cellular automata texture) - - -* multipass rendering is supported trough the objects -3dp_subcontext, "3dp_draw clear" and "3dp_view reset". the idea -is as follows: before rendering the final scene, you use -(a part of) the drawing buffer to render some things and store -them in a texture to be used in your final drawing pass. have -a look at examples 11, 12 and 13. in theory you could build a -"texture processing" framework on top of 3dp, by using the window -buffer as an accumulator and using textures as auxilary registers, -and drawing your final texture result using i.e. -3dp_display_texture. while this can be much faster than ordinary -pdp image processing, it also requires you to do more bookkeping -yourself, since you can only use a "serial" approach because -you can't modify textures directly, only trough the use of the -render buffer. - - -* 3dp has it's own thread, which is enabled by default. you -can enable/disable this by sending a "3dthread 0/1" message -to pdp_control. in most cases there's no reason to disable -the thread processing, except when you are doing a lot of -pdp<->3dp conversions. in that case the delay introduced by -the thread processing might become problematic. (the same -goes for pdp btw. feedback and threads don't mix too well). -it's a tradeoff. thread processing gives priority to the audio, -so you can obtain low latency, and you don't have to care -about locking up pd by doing too much processing. (instead -frames will be dropped). the drawback is of course that video -timing becomes unpredictable because it is governed by the system -scheduler. so sometimes it can be useful to disable threads -and increase the audio latency, so you can have snappy audio -and video at the same time. getting this to work well usually -requires some experimenting. - - -enjoy, - -tom - - - - ---- -some political ranting: gem vs. pdp/3dp - -first a disclaimer. i'm not into dissing people. i respect and appreciate -all the work that has gone into gem, but at the same time i'm not too happy -with what gem has become. not so much the functionality, but the way it is -built. the original design as a 3d processing extension is not flexible enough -to incorporate what's in there now and what could be added in the future.. - -instead of complaining about it, i decided to be pragmatic and write something -from scratch. i think, sometimes this has to be done. for me writing pdp/3dp -has been an extremely interesting learning experience. i think i understand -the trade-offs better now, and maybe these remarks can be useful. - -opengl is not a pure dataflow language. it operates on a global machine -state next to the obvious drawing buffer that is passed around. -representing opengl code with a graphic tree view has some advantages, -though it has a different "feel" than normal pd patches. the fact that -opengl transforms object coordinates to screen coordinates, and not vice -versa, gives graphicly represented opengl code an "upside down" feel. - -one of the things i don't like about gem is that it has both the opengl -"upside down drawing and coordinate transformation tree" and the pix -"data flow image processing tree" in the same network, which i find -counterintuitive. it is too monolytic to be truly flexible. in pdp/3dp -i try to separate the two explicitly: dataflow where possible (image -processing), and serial context based processing where needed (opengl). - -another disadvantage of gem is its window centric context. by building -3dp around explicit context passing, with explicit context creation objects, -i try to avoid this. an advantage of this is the possibility to send -multiple contexts trough a rendering tree, i.e. to have 2 different views -of the same scene. - -pdp has implicit fanout for all packets. i think that is its great -strength. it enables you to use any kind of media packet like you would -use floats. it is very intuitive. however, 3d rendering does not fit -this shoe. at least not when you just wrap opengl in the most straightforward -way. 3dp is a test case for pdp's "accumulation packets", which is a formal -abstraction of a context. pdp processors are noting more than serial programs -working on a context, so in fact it's nothing special. in fact, i'm still -in doubt if it is useful besides being able to support opengl.. - -so, the idea was to improve upon gem a bit, from different angles. i did -not succeed in my primary goal: making 3dp more intuitive than gem. it seems -this is only possible if you limit some of the flexibility. just wrapping -opengl keeps a lot of flexibility, but get's infected with the opengl -paradigm. by separating pdp (image processing) and 3dp (drawing and geometry -processing) as much as possible i think i've solved some intuition problems, -but 3dp itself is still basicly gem, with imho a better overall design, -but due to its more low level approach, maybe harder to understand. it seems -to me that knowing how opengl works is rather necessary to use 3dp. the same -is true for gem. - -one last philo remark: to me it seems the biggest drawback of gem's design is -the processor centric aproach: the only objects are processors, the data is -implicit and seemingly global. in pdp/3dp processors and objects are 2 separate -entities. i tried to unify them in one object model, but to me it seems the two -should really be treated as different complementary entities, to stay close to -the dataflow paradigm which makes pd such an intuitive tool. - |