GEM-dev

gem-dev@lists.iem.at

2417 discussions

Vertex Shader Objects
by r.leboite.pm＠birdsinplane.com 22 Sep '04

22 Sep '04

Hello, I have recoded parts of the Shader Objects i posted last Week. This is not yet a very good solution but there are now some fixes like error reporting on dynamic compilation that could help to trace eventual "non" bugs. I actualy work on a bi-opteron + Geforce6800-256Mo. I have no ATI card at my disposal to do some tests. If anyone then could send me feedback on how it handles on such cards, that would be very nice. Any comment about these functionnalities or discussions about how to integrate Shaders the best way are very welcomed. When the Cg wrapper will be done, i hope i'll have a sufficient knowledge of Shaders and Gem to reforge something stronger and also a GLSL version of the objects. Source and dll are avaiable at the folowing adress: http://www.birdsinplane.com/Gem/ Objects Updated - Added: GEMcgVertexProgram GEMcgGLSetParameter1f GEMcgGLSetParameter2f GEMcgGLSetParameter3f GEMcgGLSetParameter4f I have also added some nice sample patches. Specifically the cgVertexProgram3.pd Greetings Ronan ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/

1 0

some new code
by cyrille henry 17 Sep '04

17 Sep '04

hello, here are some code I made for gem : http://drpichon.free.fr/gem/ as usual, it's only proposition submited to your critisism. description : gemlist_info : --------------- this object get a gemlist and decompose the transformation matrix in basic transformations : translation, rotation, scale and shear. very usful for video -> audio interaction while using iterative process in the gem render chain (this object was made using cut/past from Iohannes code and Chris sugestion) ShearXY, shearXZ ... ------------------ a collection of transformation objects that shear the deformation matrix. shear can be created with rotation and scale, but it's easier to use this specifics objects. this objects are also usefull to create a specific transformation matrix using gemlist_info output. newWave : --------- newWave has a big problem : it is sensitive to denormal bug. (newWave deformation can become very small after some time, and denormal can apear in both position and forces.) adding some very low ampliture (about 1e-20) random noise to a node fix the problem : the noise does propagate in the all structure avoiding denormal. maybe some ifdef could be add for this procedure, but it is fast enough to leave it like this. I just copy the random() procedure from randF object. maybee someone can tell me how to use the original one (sorry, it's a newbee question, but I never had time to learn C++ !) I also found that newWave share it's dimension on all instances of this object : it was not possible to have a "newWave 5" and a "newWave 23" in the same time. While fixing this I made the X/Y dimention independant to be able to create rectangular newWave. I fixed also a X/Y texturing inversion and I limited Z position of points to prevent instability of the system. tube : ------ just a small modification in order to be able to change the number of faces used to draw the shape. You'll find gem help file for all of this. Hope you'll like them. Cyrille

7 11

gem & 3dp
by Tom Schouten 17 Sep '04

17 Sep '04

hi all, to let you know i fixed 3dp, and declared the 'api' stable. currently, there's no direct link to gem (gemstate) but, in principle 3dp objects should be able to render to the buffer. at least, the current context, assuming gem leaves its context current. the protocol is just a '3dp' message, which will render some things or changes gl state and passes a '3dp' message on its left outlet. maybe we could do some hacking in graz to link in libpdp in gem and run it natively, with access to gemstate. i didn't have time yet to dive deeper in gem code. cheers tom

1 0

lighting problem
by cyrille henry 17 Sep '04

17 Sep '04

hello, I try to change the rendering order of light. If I clearly rebember, a "gemhead 1" is nead for light to allow them to be render befor all objects. I tied with official 0.90 : light are rendered befor everything whatever the gemhead number. is it a bug in my memory or in the last gem version? what should I do to render some object without light and some other with light? thanks cyrille

1 0

offscreen rendering
by r.leboite.pm＠birdsinplane.com 17 Sep '04

17 Sep '04

Hello, I have read a lot of papers about offscreen rendering using pBuffers. Those all lead to the use of the extension WGL_ARB_render_texture. Which is supported by most of the graphics cards. I can remember that someone told that this extension was not supported by Apple drivers. Well it hasn't the same name but it works. The replacement extension name is: AGLSurfaceTexture. And it work pretty well. For those who are interested here is the sample use page: http://developer.apple.com/samplecode/AGLSurfaceTexture/AGLSurfaceTexture.h… Greetings Ronan ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/

2 3

Fwd: Cg runtime and fragment programs
by James Tittle II 17 Sep '04

17 Sep '04

hey ronan, ...here's the specifics of a discussion I had with some guys about the Cg/ATI/ARB problems...I know it's a little long, but I think there's some good info here for all of us to consider regarding the issues... l8r, jamie Begin forwarded message: > From: Chris Bentley <chrisb(a)ati.com> > Date: June 28, 2004 10:32:01 AM EDT > To: mac-opengl(a)lists.apple.com > Cc: mgix(a)apple.com > Subject: Re: Cg runtime and fragment programs > > Hi, > > Here are Dan Gessel's comments: > > Our initial ARB FP implementation was designed with the assumption > that programs would be written to the parse, or non-native, limits. > These were set to be close to, or, in some cases, less than the native > limits (as we would hold back exporting resources that might be > required to implement some ARB FP instructions which are not native to > our HW). > > Because of this, instruction re-ordering and merging of dependent > phases (or indirections) was not a primary concern. > > Specifically, we understand that Cg, focuses on minimizing > temporaries, as it is apparently an important issue for Nvidia > hardware; in contrast, "indirections" are limited on ATI HW. > > Another aspect on our hardware is that fetches from texture rectangles > require ALU ops to scale texture coordinates before the texture > instruction can be issued, which, if the first instruction is a > texture rect fetch, will introduce another "indirection". > > Because Cg trades "indirections" for fewer temporaries, Cg generated > code with fetches from texture rectangles will often fail on our early > ARB FP compilers. > > The 10.3.4 compiler is much improved from 10.3.3 and earlier, but is > still designed for ARB FP programmers writing in "assembler", with an > understanding of the HW limitations. > > However, additional work on the compilers for upcoming hardware (with > instruction space for significantly longer programs), has also come > with much more aggressive optimization (including indirection > aggregation). > > Because the optimizers are more capable, we have enlarged the parse > limits so that we have the best opportunity to execute any given > program. > > In particular, the program below can be executed on ATI HW using the > latest beta drivers. > > > chrisb > > > > > > On Jun 24, 2004, at 7:11 PM, Chris Bentley wrote: > >> >> >> -----Original Message----- >> From: mgix(a)apple.com [mailto:mgix@apple.com] >> Sent: Thursday, June 24, 2004 6:47 PM >> To: macopengl List >> Subject: Re: Cg runtime and fragment programs >> >> >> Le 24 juin 04, ` 14:44, Pete Warden a icrit : >> >>> One other thing to note is that whilst the limits are tighter than >>> NVidia's, the fragment programs we use run two to three times faster >>> on ATI R3xx systems than the NV34. >>> >>>> Yes, on the R300 chips the limit is 64 alu instructions, and then >>>> there are also 32 texture instructions. >>> >>> By the way Chris, when you mention '32 texture instructions', is >>> there >>> anyway to actually use that many TEX's without hitting the other >>> limitations? We've managed to use 8 texture reads in a single program >>> by using glMultiTexCoords() or other ways of generating the texture >>> coordinates that don't trigger the indirection count, but doing any >>> more than that fails. >>> >>> Pete >>> >>> On Thursday, June 24, 2004, at 01:53 PM, Chris Bentley wrote: >>> >>>> Hi, >>>> >>>>> If you're running on an ATI board, there are severe limitations to >>>>> what you can actually execute on it: >>>> >>>> Whether "severe" or not, yes there are indeed limitations... To >>>> inject a little actual data into this discussion, here are the >>>> limits: >>>> >>>> >> >> I guess 'severe' was probably a bad choice of words :) There >> is indeed plenty of cool stuff you can do within the existing limits. >> >> However, I'd like to add my 2 cents to Pete's comment : I am kind of >> surprised by the 32 texture instruction limit you mention: every time >> I write a pixel shader that uses more than about 8 taps, it either >> does not load or fails silently (black images). >> >> I confess I did not explore the issue in depth, and I'm not sure what >> actual limit the shader hit (# of TEX instruction, ordering or >> other), but I do hit these limits real, real fast, especially with >> raw CG output. >> >> To inject a little more data in the discussion, below is a specific >> example of an ARB shader that fails for me (I run on an R350, on OSX >> 10.3.4): >> >> It has 7 texture taps, 14 ARB instructions, and seems to be within >> constraints, but fails to load : >> gl->getProgramivARB(GL_PROGRAM_UNDER_NATIVE_LIMITS_ARB) returns 0 >> >> One frustrating thing is that it is very hard to figure why the >> shader fails, and you end up having to spend lots of time just trying >> to move things about in the ARB instruction list just to get the >> driver to accept it. >> >> It looks like it does fail simply because the instructions do not >> come in the order the driver expects. >> >> If so, it would indeed be very nice if the driver could reorder them >> on the fly to fit the requirement of the chip rather than having the >> programmer do it by hand. >> >> Especially if the HW constraint change with each chip generation. >> >> >> !!ARBfp1.0 >> # ARB_fragment_program generated by NVIDIA Cg compiler >> # cgc version 1.2.0001, build date Feb 19 2004 10:51:06 >> # command line args: -I. -profile arbfp1 >> #vendor NVIDIA Corporation >> #version 1.0.02 >> #profile arbfp1 >> #program main >> #semantic main.tex0 : TEXUNIT0 >> #semantic main.w0 : C0 >> #semantic main.w1 : C1 >> #var samplerRECT tex0 : TEXUNIT0 : texunit 0 : 1 : 1 >> #var float4 w0 : C0 : c[0] : 6 : 1 >> #var float3 w1 : C1 : c[1] : 7 : 1 >> #var float4 color : $vout.COLOR : COL : 0 : 1 >> #var float4 tc0 : $vin.TEXCOORD0 : TEX0 : 2 : 1 >> #var float4 tc1 : $vin.TEXCOORD1 : TEX1 : 3 : 1 >> #var float4 tc2 : $vin.TEXCOORD2 : TEX2 : 4 : 1 >> #var float2 tc3 : $vin.TEXCOORD3 : TEX3 : 5 : 1 >> PARAM u0 = program.local[0]; >> PARAM u1 = program.local[1]; >> TEMP R0; >> TEMP R1; >> TEMP R2; >> TEX R0, fragment.texcoord[0].zwzz, texture[0], RECT; >> TEX R1, fragment.texcoord[0], texture[0], RECT; >> MUL R0, R0, u0.y; >> MAD R0, R1, u0.x, R0; >> TEX R1, fragment.texcoord[1], texture[0], RECT; >> TEX R2, fragment.texcoord[1].zwzz, texture[0], RECT; >> MAD R0, R1, u0.z, R0; >> MAD R0, R2, u0.w, R0; >> TEX R1, fragment.texcoord[2], texture[0], RECT; >> TEX R2, fragment.texcoord[2].zwzz, texture[0], RECT; >> MAD R0, R1, u1.x, R0; >> MAD R0, R2, u1.y, R0; >> TEX R1, fragment.texcoord[3], texture[0], RECT; >> MAD result.color, R1, u1.z, R0; >> END >> _______________________________________________ >> mac-opengl mailing list | mac-opengl(a)lists.apple.com >> Help/Unsubscribe/Archives: >> http://www.lists.apple.com/mailman/listinfo/mac-opengl >> Do not post admin requests to the list. They will be ignored. > _______________________________________________ > mac-opengl mailing list | mac-opengl(a)lists.apple.com > Help/Unsubscribe/Archives: > http://www.lists.apple.com/mailman/listinfo/mac-opengl > Do not post admin requests to the list. They will be ignored. >

1 0

off to new shores...
by IOhannes m zmoelnig 17 Sep '04

17 Sep '04

hi all. now that the gem-0.90 release is out for some weeks, i think it is time to start some traffic on this list again. (but of course: what to talk about now ? we used to discuss the release for years...) some points: ------- stable: i have branched v0_90 for bug-fixes on the latest stable release -------------------- further development: wini has done some research on opensource-development and has found out that os-dev can be organized effectively in (surprise:) several ways to achieve an optimum development/stability-ratio: (the following is a translation from german and it is already some weeks ago, so i might use the wrong termini) a) pope: one person revises all code and decides which parts of the development should go into the next release b) committee: a small team off people does like the pope. c) branching: each new feature is branched off the main CVS-trunk. as soon as it has become stable the branch is merged with the main trunk. i don't think that a) would be a very good idea (as it has proven to lead to major quarrels and misunderstanding) as for b) it seems like a bit of an overhead, as the core-development team is so small, that all of us would be in the committee. so i favour c) (with some b)): each development should be forked into a separate branch in the CVS; the core-developpers of this branch work on the code until they consider it stable and then make a call for testing via the list. after it has proven to run stable on all platforms this tree is merged back in. i would suggest that the releasing should be done on each merge of a development-branch to the main-trunk that adds new functionality. (this can be discussed; it is just fundamentally different from the last release) the main-trunk can be used for bug-fixing... ------------- new features: i'm looking forward to vertex-manipulation, pixel-shaders, multiple gemwins, MMX/SSE2, new pixel-effects, pixel-analysis and tons of other things. cheers, comments ? and happy coding mfg.as.dr IOhannes

7 14

Re: your dll
by Ronan Puce Muse 16 Sep '04

16 Sep '04

Hello Wolfgang > i am not so much in this texture rendering stuff... could you maybe give me > a little hint what > could be realised (or even one or two more example patches). i thought of > something like > rendering a tree on the texture of another trees objects (... or am i too > wrong?) well, the renderTexture object has 3 outlets, from the right to the left they are: - the pBuffer has been bound. Rendering context have been set to its own one, all the things you will draw from this inlet will be drawn to the pBuffer. - the pBuffer has been bound as a texture: in order to see your drawing you need to set a primitive (whatever you want) on which the texture will be applied - the process is over, we can continue to render on the main display I currently only use the Gem opengl wrapper commands to draw and set my primitive, i dont know yet if other Gem objects can be applied to this. I personally use that to have different objects with different feedback (this feedback is actually simulated from within the object via the alpha message...). As you can see in the demo patch, there is 2 objects like this applied to 2 different quads. you can play with the quads size and Blend parameters to have an idea of what can be achieved. This is for sure a very simple first approach but this is currently the fastest way to render something on a texture. > and... > in the cgvertexprogramm i get cg error messages that it cant read your > files... (wave2... and so on) you folder must look like this in order to work: - (your folder) | RenderTexture.pd | cgVertexProgram.pd | - Cg | Wave2.cg | Wave.cg Does it solve the problem ? I'm also curious about one thing: What kind of graphic card are you running ? Thanks Ronan

1 0

Re: [GEM-dev] some new code
by r.leboite.pm＠birdsinplane.com 16 Sep '04

16 Sep '04

Selon Gregor Tobeitz <gtobeitz(a)gen-control.com>: > hi, > > first of all - thanx for the effort and the sharing of your work. but i > seems to have a problem with your compiled Gem.dll. - when i try to > start pd with your .dll the command line tells me that it can't load > the Gem library. i checked the path and everything seems ok - wenn i > replace your Gem.dll with the old one then everthing is back normal. any > idea ??!! Well, you should have a message during the PD launch that may say that it cant find the cg.dll or somewhat. please, tell me more about this error, is that just a message saying that it cant load the Gem library ? no information about a dll ? If that's related to the Cg dll, you probably dont have the Cg compiler installed. It is required for the application so it can dynamicaly compile Shaders. You can find it at the nvidia developer site: http://developer.nvidia.com/object/cg_toolkit.html Hope this solves Ronan ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/

1 0

Re:[GEM-dev] some new code
by r.leboite.pm＠birdsinplane.com 16 Sep '04

16 Sep '04

> > Please post them somewhere, and I'm sure we will all want to have a > > look. Hello, I've posted what i did here: http://www.birdsinplane.com/Gem/ This code is neither well commented, neither final but this can give an idea Ronan ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev