Problem with cloud-svg: only fg_color is drawn

[almarklein]

All shapes are grey. cloud.py does work (white disks with a black border)

[almarklein]

I do have float textures btw.

[almarklein]

Ubuntu Linux with OPenGL 4.3.0 NVIDIA GT420M

[almarklein]

The result is better if change:

    if (r > 0.0)
        gl_FragColor = vec4(v_fg_color.rgb, alpha*v_fg_color.a);
    else
        gl_FragColor = mix(v_bg_color, v_fg_color, alpha);

to:

    if (r > 0.0) // edge
        gl_FragColor = mix(v_bg_color, v_fg_color, alpha);
    else
        gl_FragColor = vec4(v_bg_color.rgb, alpha*v_fg_color.a);

But the aliasing seems incorrect. @rougier Are you sure you are not mixing up fg_color and bg_color somewhere?
fg_color is the edge color right, and bg_color the fill, right?

[rougier]

Made lot of change, could you test again ?

[almarklein]

Nope, still the same ... I can probably have a look later. Any ideas on what I can try?

[rougier]

Yep, uncomment lines 134-138 and comment lines 140-141.

Also, for debugging, use this for initialisation:

Create vetices

n = 1
v_position = 0 * np.random.randn(n, 3).astype(np.float32)
v_color = np.random.uniform(.75,1,(n,3)).astype(np.float32)
v_size = np.random.uniform(500,500,(n,1)).astype(np.float32)

Optionally, you light want to set v_linewidth to 10 in the shader

On Aug 13, 2013, at 1:56 PM, Almar Klein notifications@github.com wrote:

Nope, still the same ... I can probably have a look later. Any ideas on what I can try?

---

Reply to this email directly or view it on GitHub:
#19 (comment)

[almarklein]

Found it!

You should not pass data with negative values to a texture. Normal values for samplers are between 0.0 and 1.0. Apparently some implementations allow negative values, but not mine.

So I add 0.5 to the data before it is uploaded to OpenGL, and in the shader I do:

float r = v_size*(texture2D(u_texture, gl_PointCoord.xy).a-0.5); 

[rougier]

Cool ! Thanks and weird. Since you're supposed to have float texture, you should be able to get neg value.
Maybe we need to check clamping and scaling when passign texture.

Do you have a reference on that ?

Did you pushed you change, shoudl I close the issue ?

On Aug 13, 2013, at 2:56 PM, Almar Klein notifications@github.com wrote:

Found it!

You should not pass data with negative values to a texture. Normal values for samplers are between 0.0 and 1.0. Apparently some implementations allow negative values, but not mine.

So I add 0.5 to the data before it is uploaded to OpenGL, and in the shader I do:

float r = v_size*(texture2D(u_texture, gl_PointCoord.xy).a-0.5);

---

Reply to this email directly or view it on GitHub:
#19 (comment)

[almarklein]

I guess the FLOAT texture says more about precision than about range.

The set_data() method does have a clim parameter to set the min and max value that should be mapped to [0..1].

I do not have a reference (cannot find anything in the Gold book at least), but my guess is that the behaviour outside the range [0..1] is undefined, since it does not make sense when talking about colours. I have run into this issue before with visvis.

I did not push the change yet ...

[rougier]

Ok, I checked the texture.py class and I think we're not using float textures

From http://compgroups.net/comp.graphics.api.opengl/floating-point-texture-values-clampe/75517

You should specify the bit depth of the internal format. GL_RGBA usually means 8 bit per channel, mapped to [0,1]. GL_RGBA32F_ARB gives you the full range of float values. Have a look at http://www.opengl.org/registry/specs/ARB/texture_float.txt for the details.

Having the data in float does not mean we have a float texture but only tells OpenGL how to read the texture. What I don't quite get is why it is working on my machine and others. Anyway, we should have the GL_RGBA32F (if available on GL ES).

On Aug 13, 2013, at 6:19 PM, Almar Klein notifications@github.com wrote:

I guess the FLOAT texture says more about precision than about range.

The set_data() method does have a clim parameter to set the min and max value that should be mapped to [0..1].

I do not have a reference, but my guess is that the behaviour outside the range [0..1] is undefined, since it does not make sense when talking about colours. I have run into this issue before with visvis.

I did not push the change yet ...

---

Reply to this email directly or view it on GitHub:
#19 (comment)

[campagnola]

On Tue, Aug 13, 2013 at 12:37 PM, Nicolas Rougier
notifications@github.comwrote:

Ok, I checked the texture.py class and I think we're not using float
textures

From
http://compgroups.net/comp.graphics.api.opengl/floating-point-texture-values-clampe/75517

You should specify the bit depth of the internal format. GL_RGBA usually
means 8 bit per channel, mapped to [0,1]. GL_RGBA32F_ARB gives you the full
range of float values. Have a look at
http://www.opengl.org/registry/specs/ARB/texture_float.txt for the
details.

Having the data in float does not mean we have a float texture but only
tells OpenGL how to read the texture. What I don't quite get is why it is
working on my machine and others. Anyway, we should have the GL_RGBA32F (if
available on GL ES).

From the ES2.0 docs (
http://www.khronos.org/opengles/sdk/docs/man/xhtml/glTexImage2D.xml ) it
looks like there is no guarantee of precision or range; the driver is free
to determine internally how it will represent the data:

. . . type may be used as a hint to specify how much precision is desired,
but a GL implementation may choose to store the texture array at any
internal resolution it chooses.

On my machine, they appear to be stored with 8-bit resolution. I have a
potential solution for this in the current line-visual code. It packs a
32-bit float as 8-bit RGBA values, then uses intBitsToFloat to unpack the
correct values on the other side. I don't know if this is ultimately a good
solution, but it seems to work on my machine.

Luke

[almarklein]

Of precision it says "The GL converts it to floating point". Or do they mean the client-side does this before it is send to the server-side, where it can be whatever. I always thought texture data was 8 bit fixed point or something.

About range it says that values are clamped to [0..1]. The OpenGL 4 docs say that as well btw: http://www.opengl.org/sdk/docs/man/xhtml/glTexImage2D.xml

Packing 32 bit floats only works for scalar textures, or we'd have to make the texture 4x wider or something :) I would not make that our default texturing approach. But its good to know the limitations and how these can be overcome in case that's needed.

[almarklein]

I made a fix now --- forgot to mention in the commit message, so here goes:
0f3d46d

I guess this fixes this issue, right?

[rougier]

It closed this issue but not the texture float. I'll open a new issue.

On Aug 13, 2013, at 9:59 PM, Almar Klein notifications@github.com wrote:

I made a fix now --- forgot to mention in the commit message, so here goes:
0f3d46d

I guess this fixes this issue, right?

---

Reply to this email directly or view it on GitHub:
#19 (comment)