Menu
▾
▴
shallows-devel — Shallows development discussion
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(10) |
Oct
(2) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Christopher D. <er...@if...> - 2006-09-12 22:11:08
|
Hi
I've begun adding support for rendering to a specific mipmap level in shallows
(see shallows/src RenderTexture2D.cpp,1.10,1.11 and
shallows/include/shallows Program.hpp, 1.23, 1.24).
It works, but it one has to create a OffScreenBuffer and
RenderTexture2D for each mipmap level. It would be useful IMHO to
switch the mipmap level to output to directly without messing with a
lot of buffers and targets.
For this to work, glFramebufferTexture2DEXT must be called with the
new mipmap level. However, it looks like there is some caching
involved, and attachToCurrentFrameBuffer isn't called (the texture
hasn't changed, only the mipmap level). Thus, it would be useful to
have some sort of taint() function to denote that a target has to be
re-attached.
Suggestions?
Here's some example code that works with the current implementation:
--- To initialize:
m_hreduce_targets.resize( m_tri_mipmaps+1 );
m_hreduce_buffers.resize( m_tri_mipmaps+1 );
for(int i=0; i<=m_tri_mipmaps; i++) {
m_hreduce_buffers[i].reset( new OffScreenBuffer(
m_tri_lev->getWidth(), m_tri_lev->getHeight() ));
m_hreduce_targets[i].reset( new RenderTexture2D( m_tri_lev ) );
m_hreduce_targets[i]->setMipmapLevel(i);
}
--- and for rendering:
glPushAttrib( GL_VIEWPORT_BIT );
for(int l=1; l <= m_tri_mipmaps; l++) {
m_tri_level_target->setMipmapLevel( l );
m_hreduce_shader->setFrameBuffer( m_hreduce_buffers[l] );
m_hreduce_shader->setOutputTarget( 0, m_hreduce_targets[l] );
m_hreduce_shader->setParam1f( "delta", 0.5/(1<<(m_tri_mipmaps-l+1)) );
m_hreduce_shader->activate();
m_tri_lev->bind();
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, l-1 );
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, l-1 );
glViewport(0,0,1<<(m_tri_mipmaps-l), 1<<(m_tri_mipmaps-l) );
m_hreduce_shader->renderQuad();
}
glPopAttrib();
--
Chris
|
|
From: Johan S. <jo...@if...> - 2006-08-07 06:41:49
|
---------- Forwarded message ---------- From: John Maddock <jo...@jo...> Date: Aug 1, 2006 11:11 AM Subject: [Boost-announce] [regex] Thread safety patch. To: boost-users <boo...@li...>, boost-announce <boo...@li...> With apologies to all concerned, and thanks to Aleksey Sanin for tracking down the problem, there is a const-correctness bug in Boost.Regex-1.33.x that strikes only in multithreaded programs on Unix platforms, if: * Multiple threads construct regexes concurrently, or * Multiple threads perform search and replace operations concurrently. There are two possible fixes: * Apply the attached patch (this has just gone into cvs along with an updated test case that detects the issue). Or, * define BOOST_REGEX_USE_C_LOCALE in boost/user.hpp and rebuild everything. Regards, John Maddock. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce -- Regards Johan Seland PhD Student Center of Mathematics for Applications, University of Oslo |
|
From: Christopher D. <er...@if...> - 2006-01-27 08:38:09
|
On 1/27/06, Hannes Mueller <han...@em...> wrote: > Hi, > I'm currently researching, which library to use for a project involving > computations on a CPU, especially doing parallelized computing. Before I > download/compile/buy-a-new-graphics-card, could anyone please tell me if > this library is good for doing such stuff? I am not interested in > drawing anything on the screen, I only want to compute, mainly matrices > and linear algebra stuff. Hi Hannes, I'm not a developer on shallows, but I've used it for some projects and have some experience using it. Unless you're after something which actually does the linear algebra operations for you on the GPU (i.e. BLAS on GPU), but want to formulate the computations yourself, I think shallows cut the mustard. Basicly, shallows is a wrapper layer around OpenGL which handles a lot of tedious tasks involved in low-level GPU programming. I've used it for classical GPGPU-applications which doesn't produce anything on the screen, various esoteric mesh-computations, and for classical computer graphics shading, and shallows have been well suited for all areas. To summarize; if you want to formulate the computations yourself (which is more or less where the fun is), I think shallows is a good choice. Best regards Christopher Dyken. |
|
From: Hannes M. <han...@em...> - 2006-01-27 08:09:40
|
Hi, I'm currently researching, which library to use for a project involving computations on a CPU, especially doing parallelized computing. Before I download/compile/buy-a-new-graphics-card, could anyone please tell me if this library is good for doing such stuff? I am not interested in drawing anything on the screen, I only want to compute, mainly matrices and linear algebra stuff. Thanks, Hannes |
|
From: Jon H. <jon...@gm...> - 2005-10-10 10:00:45
|
Hi, my main concern is how to disable the client state. Therefore I do not think that activate() should set the pointer and enable the client state. What we can do is to add a drawArrays function that enables the client states, draws the arrays (indexed or not) and then either disables the client state or pops the previous state. The next question is what to do with the pointer itself. If the pointer is kept and glVertexAttribPointer is called every time the drawArrays are called then the pointers are read and the data are transferred into graphic= s memory each time the draw function is called. This may not be the behaviour expected from the user. If we decide to start implementing such functionality we should probably also implement support for VBO and render (copy) to vertex array as well... Jon On 10/6/05, Johan Seland <jo...@if...> wrote: > > Hello! > > I am currently developing a program where we are using vertex > attributes, and in order to get my attributes read correctly from an > array I have to to the following: > > shader.setAttribPointer( "VerLod", 1, GL_FLOAT, 1, &attribs[0], false ); > shader.enableClientState( "VerLod" ); > shader.activate(); > > Should not glProgram::run/activate enable this by itself? The user has > clearly stated that he intends to use a vertex attributes from a > pointer, why must he say so one more time. > > > -- > Help a man with his math problems and you get him off your back for a day= . > Teach a man math, and you scare him off for the rest of your life. > > Regards Johan Seland > PhD Student > Center of Mathematics for Applications > University of Oslo > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Shallows-devel mailing list > Sha...@li... > https://lists.sourceforge.net/lists/listinfo/shallows-devel > |
|
From: Johan S. <jo...@if...> - 2005-10-06 14:48:40
|
Hello! I am currently developing a program where we are using vertex attributes, and in order to get my attributes read correctly from an array I have to to the following: shader.setAttribPointer( "VerLod", 1, GL_FLOAT, 1, &attribs[0], false );=09= =09 shader.enableClientState( "VerLod" ); shader.activate(); Should not glProgram::run/activate enable this by itself? The user has clearly stated that he intends to use a vertex attributes from a pointer, why must he say so one more time. -- Help a man with his math problems and you get him off your back for a day. Teach a man math, and you scare him off for the rest of your life. Regards Johan Seland PhD Student Center of Mathematics for Applications University of Oslo |
|
From: Johan S. <jo...@if...> - 2005-09-19 09:25:43
|
As you might have seen, I have checked in a rather bit patch with this code= =20 pollution.=20 I do think it is nice for shallows to be a proper DLL, and I do think not= =20 the code pollution is that much of a problem.=20 I think it also is possible to avoid the code pollution by have a separate= =20 header (possibly automatically generated?) defining the __declspec(=20 DllExport ) thingy. I will look into this this evening. On 9/19/05, Jon Hjelmervik <jon...@gm...> wrote: >=20 > Hi >=20 > since the dllExport thing must be written in front of every function, > it pollutes the code rather much. So the question is do we really need > to make dll files at all or can we just create a static library? > Personally I would prefer to avoid the pollution more than having > dlls, what do you think? >=20 > On 9/16/05, Johan Seland <jo...@if...> wrote: > > Hi. > > > > I have now discovered how we must rig shallows to actually generate a > > proper DLL out of it. With this setup scons creates both a shallows.dll= and > > shallows.lib file. > > > > See http://www.flounder.com/ultimateheaderfile.htm for a > > bit of background. > > > > Basically, every class and function declaration needs the following > > prepended to its declaration when we are building shallows: > > > > class __declspec( dllexport ) Texture { ... } > > > > When we are using shallows, they need the following declaration: > > > > class __declspec( dllimport ) Texture { ... } > > > > The trick is of course some macro magic in config.h: > > > > #ifdef COMPILING_SHALLOWS > > #define DllExport __declspec( dllexport ) > > #else > > #define DllExport __declspec( dllimport ) > > #endif > > > > And then add DllExport in front of every class and function declaration= . > > > > class DllExport Texture { ... } > > > > I have a working copy of shallows with this enabled, but since it is a > > rather large change, I would like to hear your opinions on this. > > (On Linux we of course always make the DllExport macro to be=20 > whitespace.) > > > > Is this okay for all of you? > > > > -- > > Help a man with his math problems and you get him off your back for a= =20 > day. > > Teach a man math, and you scare him off for the rest of your life. > > > > Regards Johan Seland > > PhD Student > > Center of Mathematics for Applications > > University of Oslo >=20 >=20 > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server.=20 > Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Shallows-devel mailing list > Sha...@li... > https://lists.sourceforge.net/lists/listinfo/shallows-devel >=20 --=20 Help a man with his math problems and you get him off your back for a day. Teach a man math, and you scare him off for the rest of your life. Regards Johan Seland PhD Student Center of Mathematics for Applications University of Oslo |
|
From: Jon H. <jon...@gm...> - 2005-09-19 09:08:23
|
Hi since the dllExport thing must be written in front of every function, it pollutes the code rather much. So the question is do we really need to make dll files at all or can we just create a static library? Personally I would prefer to avoid the pollution more than having dlls, what do you think? On 9/16/05, Johan Seland <jo...@if...> wrote: > Hi. > =20 > I have now discovered how we must rig shallows to actually generate a > proper DLL out of it. With this setup scons creates both a shallows.dll a= nd > shallows.lib file. > =20 > See http://www.flounder.com/ultimateheaderfile.htm for a > bit of background. > =20 > Basically, every class and function declaration needs the following > prepended to its declaration when we are building shallows: > =20 > class __declspec( dllexport ) Texture { ... }=20 > =20 > When we are using shallows, they need the following declaration: > =20 > class __declspec( dllimport ) Texture { ... } > =20 > The trick is of course some macro magic in config.h: > =20 > #ifdef COMPILING_SHALLOWS > #define DllExport __declspec( dllexport ) > #else > #define DllExport __declspec( dllimport ) > #endif > =20 > And then add DllExport in front of every class and function declaration. > =20 > class DllExport Texture { ... } > =20 > I have a working copy of shallows with this enabled, but since it is a > rather large change, I would like to hear your opinions on this. > (On Linux we of course always make the DllExport macro to be whitespace.= ) > =20 > Is this okay for all of you? > =20 > --=20 > Help a man with his math problems and you get him off your back for a day= . > Teach a man math, and you scare him off for the rest of your life. >=20 > Regards Johan Seland > PhD Student > Center of Mathematics for Applications=20 > University of Oslo |
|
From: Johan S. <jo...@if...> - 2005-09-16 18:15:33
|
Hi. I have now discovered how we must rig shallows to actually generate a prope= r=20 DLL out of it. With this setup scons creates both a shallows.dll and=20 shallows.lib file. See http://www.flounder.com/ultimateheaderfile.htm for a bit of background. Basically, every class and function declaration needs the following=20 prepended to its declaration when we are building shallows: class __declspec( dllexport ) Texture { ... }=20 When we are using shallows, they need the following declaration: class __declspec( dllimport ) Texture { ... } The trick is of course some macro magic in config.h: #ifdef COMPILING_SHALLOWS #define DllExport __declspec( dllexport ) #else #define DllExport __declspec( dllimport ) #endif And then add DllExport in front of every class and function declaration. class DllExport Texture { ... } I have a working copy of shallows with this enabled, but since it is a=20 rather large change, I would like to hear your opinions on this. (On Linux we of course always make the DllExport macro to be whitespace.) Is this okay for all of you? --=20 Help a man with his math problems and you get him off your back for a day. Teach a man math, and you scare him off for the rest of your life. Regards Johan Seland PhD Student Center of Mathematics for Applications University of Oslo |
|
From: Johan S. <jo...@if...> - 2005-09-15 07:34:23
|
Hello. It is now possible to register new accounts at the shallows.sf.net<http://shallows.sf.net>homepage. Mostly intersting for administrators who wish to add content. --=20 Help a man with his math problems and you get him off your back for a day. Teach a man math, and you scare him off for the rest of your life. Regards Johan Seland PhD Student Center of Mathematics for Applications University of Oslo |
|
From: Christopher D. <e.c...@cm...> - 2005-09-07 09:45:41
|
Johan Seland <joh...@gm...> writes:
| On 9/6/05, Christopher Dyken <e.c...@cm...> wrote:
>
[...]
| Ish. This is indeed a bug. Could you send me the offending shader?
Sure,
---< begin glshader >---
[Vertex shader]
uniform vec3 b[9];
void main ()
{
vec3 m = (3.0/12.0)*(b[1]+b[2]+b[4]+b[5]+b[7]+b[8]) - (1.0/6.0)*(b[0]+b[3]+b[6]);
float x = gl_Vertex.x;
float y = gl_Vertex.y;
float z = gl_Vertex.z;
float bez300 = x*x*x;
float bez201 = 3*x*x*z;
float bez102 = 3*x*z*z;
float bez030 = y*y*y;
float bez120 = 3*x*y*y;
float bez210 = 3*x*x*y;
float bez003 = z*z*z;
float bez012 = 3*y*z*z;
float bez021 = 3*y*y*z;
float bez111 = 6*x*y*z;
vec3 p = bez300*b[0] +
bez210*b[1] +
bez120*b[2] +
bez030*b[3] +
bez021*b[4] +
bez012*b[5] +
bez003*b[6] +
bez102*b[7] +
bez201*b[8] +
bez111*m;
gl_Position = gl_ModelViewProjectionMatrix * vec4(p, 1.0);
gl_FrontColor = gl_Color;
}
[Fragment shader]
void main ()
{
gl_FragColor = gl_Color;
}
---< end glshader >---
which is initialized with
---< begin init code >---
m_shader.reset(new GLProgram);
m_shader->readFile("shaders/CurvedFaceRender.glshader");
m_shader->setFrameBuffer(
shared_ptr<OnScreenBuffer>(new OnScreenBuffer));
m_shader->setOutputTarget(0,
shared_ptr<OnScreenRenderTarget>(new OnScreenRenderTarget(GL_BACK_LEFT)));
---< end init code >---
and the following
---< begin offending code >---
m_shader->activate();
for(size_t i=0; i<m_tri_vertices.size(); i++) {
if(tri_classification[i]) {
m_shader->setParam3fv("b", 9, &m_tri_data[i].b[0]);
glBegin();
[...]
glEnd();
}
}
---< end offending code >---
produces
sview: src/GLProgram.cpp:528: GLint shallows::GLProgram::validate_uniform(const char*) const: Assertion `it != uniformsNameToType_.end() && "Internal Shallows error. The uniform map does not correspond with OpenGL."' failed.
Aborted
--
Chris
|
|
From: Johan S. <joh...@gm...> - 2005-09-07 06:15:19
|
On 9/6/05, Christopher Dyken <e.c...@cm...> wrote:
>=20
>=20
> I tried updating an uniform attribute from within Renderable::render with
> the mechanisms of shallows, but
>=20
> void Foo::render() const
> {
> ...
> for(size_t i=3D0; i<m_Nt; i++) {
> m_shader->setParam3fv("b", 9, &m_tri_data[i].b[0]);
> ...
> }
> }
>=20
> fails with:
>=20
> sview: src/GLProgram.cpp:432: GLint
> shallows::GLProgram::validate_uniform(const char*) const:
> Assertion `it !=3D uniformsNameToType_.end() && "Internal
> Shallows error. The uniform map does not correspond with
> OpenGL."' failed.
> Aborted
Ish. This is indeed a bug. Could you send me the offending shader?=20
However, if I circumvent a little bit by adding
>=20
> unsigned int getProgramHandle() const { return programHandle_; }
>=20
> in GLProgram, the following
>=20
> void Foo::render() const
> {
> GLint location =3D glGetUniformLocation(m_shader->getProgramHandle(), "b"=
);
> if(location =3D=3D -1)
> throw std::runtime_error("fuuuu");
>=20
> for(size_t i=3D0; i<m_Nt; i++) {
> glUniform3fv(location, 9, &m_tri_data[i].b[0]);
> ...
> }
> }
>=20
> works like a charm.
>=20
> Could it be possible to add a back-door to do stuff like this, or does
> it completely break with the philosophy? The location index, or at
> least the program handle, is also needed for throwing uniform shader
> variables into buffer objects.
It does indeed break with the philosophy, but at the same time we must allo=
w=20
for different scenarios. I do think the getProgramHandle() is a good idea.=
=20
--=20
Help a man with his math problems and you get him off your back for a day.
Teach a man math, and you scare him off for the rest of your life.
Regards Johan Seland
PhD Student
Center of Mathematics for Applications
University of Oslo
|
|
From: Johan S. <joh...@gm...> - 2005-09-06 16:43:12
|
---------- Forwarded message ---------- From: nv...@nv... <nv...@nv...> Date: Sep 6, 2005 6:41 PM Subject: NVIDIA Updated Your Incident Report (187626) To: jo...@st... Please do not reply to this message ------------------------------------------------------------------- The following items have been modified for this Bug: - A new Comment has been added ------------------------------------------------------------------- Bug Information ------------------------------------------------------------------- Requester: Johan Simon Seland Bug ID: 187626 Date: 9/6/2005 5:42:55 AM Company/Division: Researcher Severity: High Synopsis: Programmer question: calling glReadBuffer(GL_NONE) without FBO. Description: Calling glReadBuffer(GL_NONE) causes a gl error,=20 GL_INVALID_ENUM, when no framebuffer object is used. The same statement called when a framebuffer object is attached causes no= =20 error. As far as I have understood the spec (EXT_framebuffer_object) this i= s=20 not the correct behaviour of the driver. -------------------- Additional Information ------------------------ Computer Type: PC System Model Type: System Model Number: CPU Type: Video Memory Type: Chipset Mfg: Chipset Type: Sound Card: CPU Speed: Network: Modem: North Bridge: South Bridge: TV Encoder: Bus Type: AGP OS Language: Application: Shallows (www.sf.net/projects/shallows(<http://www.sf.net/projects/shallows(> Driver Version: 1.0-7676 System BIOS Version: Video BIOS Mfg: Video BIOS Version: Direct X Version: Monitor Type: Monitor 1: Monitor 2: Monitor 3: Video 1: Video 2: Video 3: Resolution: Color Depth: Products: GeForce 6800 GT Application Version: Pre-release Application Setting: Multithreaded Application: no Other open applications: Release: Beta OS Details: Suse 9.2 Problem Category: Other How often does problem occur: Video Memory Size: CPUs (single or multi): RAM (amount & type): AGP Aperture Size: ------------------------------------------------------------------- Latest Comment update from NVIDIA (9/6/2005 9:41:38 AM): Johan, After review by development, we do not believe that this is a bug, as the= =20 behavior that you are reporting is correct per the specification. The=20 following is cited from version #114 of EXT_framebuffer_object. (the latest= =20 published version at the moment): "The command: void ReadBuffer( enum src ); takes a symbolic constant as argument. <src> must be one of the .. Further, the acceptable values for <src> depend on whether the GL is using the default window-system-provided framebuffer (i.e., FRAMEBUFFER_BINDING_EXT is zero), or an application-created framebuffer object (i.e., FRAMEBUFFER_BINDING_EXT is non-zero). .. When the GL is using the default window-system-provided framebuffer, <src> must be one of the values listed in table 4.4. ... Here is table 4.4. Note that NONE is not listed in table 4.4. symbolic front front back back aux constant left right left right i NONE FRONT_LEFT X FRONT_RIGHT X BACK_LEFT X BACK_RIGHT X FRONT X X BACK X X LEFT X X RIGHT X X FRONT_AND_BACK X X X X AUXi X Table 4.4: Arguments to DrawBuffer and the buffers that they indicate. Please let me know if you have any further questions. Thanks, Lonni --=20 Help a man with his math problems and you get him off your back for a day. Teach a man math, and you scare him off for the rest of your life. Regards Johan Seland PhD Student Center of Mathematics for Applications University of Oslo |
|
From: Christopher D. <e.c...@cm...> - 2005-09-06 11:26:17
|
I tried updating an uniform attribute from within Renderable::render with
the mechanisms of shallows, but
void Foo::render() const
{
...
for(size_t i=0; i<m_Nt; i++) {
m_shader->setParam3fv("b", 9, &m_tri_data[i].b[0]);
...
}
}
fails with:
sview: src/GLProgram.cpp:432: GLint
shallows::GLProgram::validate_uniform(const char*) const:
Assertion `it != uniformsNameToType_.end() && "Internal
Shallows error. The uniform map does not correspond with
OpenGL."' failed.
Aborted
However, if I circumvent a little bit by adding
unsigned int getProgramHandle() const { return programHandle_; }
in GLProgram, the following
void Foo::render() const
{
GLint location = glGetUniformLocation(m_shader->getProgramHandle(), "b");
if(location == -1)
throw std::runtime_error("fuuuu");
for(size_t i=0; i<m_Nt; i++) {
glUniform3fv(location, 9, &m_tri_data[i].b[0]);
...
}
}
works like a charm.
Could it be possible to add a back-door to do stuff like this, or does
it completely break with the philosophy? The location index, or at
least the program handle, is also needed for throwing uniform shader
variables into buffer objects.
--
Chris
|
|
From: Jon H. <jon...@gm...> - 2005-09-05 13:53:30
|
Unfortunately there are no single component red buffers, and neither any red and green two components buffer buffers. (The nVidia extension do have red and red+green formats, but not the ATI or ARB extension). I am not sure what the best solution is. Jon On 9/5/05, Johan Seland <joh...@gm...> wrote: > What should really be the format for 1 and 2 component readFloatBuffer > calls? > Today we use alpha and luminance_alpha, this leads to counter intuitive > output in the shader. (ie. write to .a or .w channel, while .r or .x feel= s > more right for singular outputs.) > =20 > Any thoughts on this? This _must_ also be thoroughly documented. > =20 > --=20 > Help a man with his math problems and you get him off your back for a day= . > Teach a man math, and you scare him off for the rest of your life. >=20 > Regards Johan Seland > PhD Student > Center of Mathematics for Applications=20 > University of Oslo |
|
From: Johan S. <joh...@gm...> - 2005-09-05 13:28:44
|
What should really be the format for 1 and 2 component readFloatBuffer=20 calls? Today we use alpha and luminance_alpha, this leads to counter intuitive=20 output in the shader. (ie. write to .a or .w channel, while .r or .x feels= =20 more right for singular outputs.) Any thoughts on this? This _must_ also be thoroughly documented. --=20 Help a man with his math problems and you get him off your back for a day. Teach a man math, and you scare him off for the rest of your life. Regards Johan Seland PhD Student Center of Mathematics for Applications University of Oslo |
|
From: Johan S. <joh...@gm...> - 2005-08-25 19:51:30
|
---------- Forwarded message ----------
From: Christopher Dyken <e.c...@cm...>
Date: Aug 25, 2005 7:36 PM
Subject: silhouette-ting
To: jo...@st...
N=E5 funker silhouette-testen p=E5 gpu, st=F8rste differanse mellom
referansen og gpu-utregning er 0.00044924.
Fant f=F8lgende bugs:
readFloatBuffer:
height/width er byttet om p=E5 glReadPixels-kallet. Rekkef=F8lgen
p=E5 funksjonsignaturen b=F8r v=E6re widht/height ogs=E5.
createFloatTextureRectangle:
pixels m=E5 v=E6re p=E5 RGBA-format uansett antallet
komponenter. Dette var grunnet til at programmet core-dumpet
rett som det var. Denne g=E5r igjen noen andre steder.
--
Chris
--=20
Help a man with his math problems and you get him off your back for a day.
Teach a man math, and you scare him off for the rest of your life.
Regards Johan Seland
PhD Student
Center of Mathematics for Applications
University of Oslo
|
|
From: Jon H. <jon...@gm...> - 2005-08-25 10:04:20
|
Hi, Readback seems to be working fine now, and I have added a test in GLProgramTest. However I had some problems when I used the default texture parameters, even with GL_RGBA8 textures.=20 Jon |