How are you trying to read the framebuffer content?

If you have a multisample buffer (either renderbuffer or texture) as color attachment, glReadPixels or other pixel transfer operations won't...

Hello,

Your question is not really related to OpenGL.
If you mean you want to load 3DS models then display them using OpenGL, you should look at it as 2 separate subproblems:
1. load 3DS file to...

I found a workaround.

In vertex shader:


in ivec3 aGBufferCoord;
out ivec2 iGBufferCoord; // used to be ivec3
out int iSampleIndex; // new

main() {

Hello,

I'm encoutering a strange bug on an nVidia card while trying to make an input-dependent texelFetch from a multisample texture in a geometry shader.
The shader has the following input:
...

I was not referring to an actual CPU-side memcpy but to a memory copy on the GPU, which could be parallel as well and certainly make better use of texture caches than a shader making random...

At any given time, there is only one active OpenGL context in a thread.
On Windows, you have to call wglMakeCurrent to switch contexts for the calling thread.
The X equivalent is glxMakeCurrent.
...

Well, depending on the memory layout of the multisample buffer, it could have been just a memory copy in the driver instead of width*height*numsamples calls to texelFetch...
Also that means I'll...

Hello,

Is there a direct way of copying the contents of a multisample texture or renderbuffer to a buffer object?
I mean every sample, because glReadPixels would average the samples at each...

Yup, you're certainly getting 4x SUPERsampling (and no useful multisampling).
On nVidia cards, at least up to GT200 series, so-called 16x multisampling is achieved by cumulating 4x multisampling...

Hello again and thank you very much for your reply.

That just makes sense, I forgot that the order in which primitives are rasteriezd in the next stages does matter in many cases (blending, etc.)....

Thanks for your reply.

Is that part of the specifications of ARB_geometry_shader4?
I couldn't find anything regarding the order of primitives in EXT_transform_feedback*.

By the way, the...

Hello,

For some GPGPU application, I'm throwing the content of a VBO as GL_POINTS at a geometry shader with transform feedback enabled in order to filter out data in the captured VBO. To discard a...

Cards that accelerate 3px-wide lines that I know of also accelerate GL_LINE_SMOOTH so there's really no need for a home-made shader here.

I mean, that's fun reinventing the wheel with shaders and...

My bad! I got the stride wrong too: it's the number of bytes between vertices, so you'll have to multiply by sizeof(GLfloat).

Still, if data is tightly packed, 0 would be prefered.

That's implementation-dependent. Use glGet* with GL_LINE_WIDTH_RANGE to query for minimum and maximum widths on your particular hardware, and GL_LINE_WIDTH_GRANULARITY to get the granularity (not...

Hello,

Did you look at plain-old fixed pipeline AA? (e.g. glEnable(GL_LINE_SMOOTH); + glLineWidth)
This is likely to be the closest thing to what your software renderer is doing.

Every other...

Halik,

I think you got the stride wrong in the gl*Pointer function calls. It's the spacing between vertices or tex coords in your float array, in case you want to interleave data (vertices,...

Sorry, it seems I did not read your post till the end.


So, what is the actual data type, content and layout of m.vertexCoords, and the value of m.numberOfVertexCoords?
Does vertexCoords...

The second arg is the number of triangles, so unless struct/class members were named in a misleading way, it should be m.numberOfVertexCoords/3. The rest is right.

The last arg is a pointer to the...

That seems to be exactly what Godlike is trying to do.

Godlike, you properly removed/commented the glGenerateMipmap call from your code in your manual mipmap loading attempt, right?

For question #2, I've been using the same FBO to render to different textures for some time and it works just fine. In my experience, it was faster to re-bind a texture with same geometry and format...

Should the actual memory range be reallocated by a call to BufferData, the buffer OBJECT itself remains, so there is no orphaning here: the buffer handles in both threads will still refer to the same...

You missed the point. What I was telling you is that the rendering code is inefficient, so it comes as no big surprises that the app is slow when changing the point of view.

First of all, you are...

After some seach, it seems you should be using some fences for synchronization (better than glFinish): http://www.opengl.org/wiki/Sync_Object

There's some information about that on OpenCSG's website: http://www.opencsg.org/