Farfadet

Right, there are arguments against their marketing approach. But what about the technology ?

Polygons are great for rendering something between big surfaces or flat faces, and extremely detailed and irregular shapes (like vegetation, rocks, clouds...). For the latter, you eventually get to render polygons that are smaller than a pixel. In that case, voxels/point clouds used in conjunction with a sparse voxel octree data structure (I regroup these under the term "voxels" in what follows) are better, at least in theory, for a few reasons :

1) the sparse voxel octree is very efficient for rendering. This explains how they could obtain that frame rate without GPU acceleration

2) the sparse voxel octree is in itself a compressed data structure

3) you get rid of the real burden of polygons : UV-maps/textures/displacement mapping - especially heavy if you consider highly irregular surfaces, clouds, vegetation... Instead, you just store colour information with the voxel.

The real limitation is that animation is virtually impossible with that technology. So the question is not : which is better ? but rather : which is better for what application ?

Maybe this can help :

http://www.equalizergraphics.com/documentation/parallelOpenGLFAQ.html

In short, it says you can't manage one rendering context from multiple threads in openGL. I believe ths is what you're trying to do.

Well, I followed your idea and noticed that the offset is related to the windows settings (such as border margin), and even to the window size. The further the window dimensions are from the texture's (1024*1024), the bigger the offset. This means that the copy of the texture attached to the FBO takes place as if the window framebuffer's dimensions were considered, not the FBO's. However, it is the FBO/texture image that's copied. I tried about every possible combination of glViewPort, but nothing changes (and that's logical, since glViewPort involves the rendering pipeline, and here I use glCopyTexImage). The strange thing is that after copying, I use the same FBO to render on the texture, with the proper glViewPort, and there it works perfectly well. This might simply be a bug in the ATI driver.

Next I'll try copying the texture by rendering it to the destination texture.

Thanks a lot

First, sorry it took me so long to answer.

Well, I'm using openGL and GLSL, and I render to texture. Putting aside the render to texture technology (I guess there's not much difference btw HLSL and GLSL), I still have a problem with the standard blending formula Cs*aS + Cd (1 - ad).

Consider the case :
Cs = 1  0  0  0.5
Cd = 0  0  1  0
i.e. the source is partly transparent, and the destination is fully transparent at that pixel.
The standard formula gives :
C = 0.5  0  0.5  0.25    (a = as*as + ad*(1-as) = 0.5*0.5 + 0*(1-0.5) = 0.25)

The resulting alpha is already strange. I can go around this by using :
glBlendFuncSeparate(GL_SRC_ALPHA,GL_ONE_MINUS_SRC_ALPHA,GL_ONE, GL_ONE). This will add up the alphas, which makes sense for a brush adding paint to a layer. But there is another problem : the resulting color I get is a dark purple because of the blue contribution. But there should be NO blue contribution, since the destination layer is fully transparent. My conclusion : standard blending is valid only for a fully opaque back layer. It assumes an alpha of 1 in the destination layer. Proof of that is that the destination alpha doesn't appear at all in the formula. Dividing by alpha will still not give me a good result : the blue will always be there.

My merging formula is alright to merge two layers without changing the visible result, but I'm still not sure it's OK for painting with a brush with an alpha component.