• 11
• 9
• 10
• 9
• 10
• ### Similar Content

• By lxjk
Hi guys,
There are many ways to do light culling in tile-based shading. I've been playing with this idea for a while, and just want to throw it out there.
Because tile frustums are general small compared to light radius, I tried using cone test to reduce false positives introduced by commonly used sphere-frustum test.
On top of that, I use distance to camera rather than depth for near/far test (aka. sliced by spheres).
This method can be naturally extended to clustered light culling as well.
The following image shows the general ideas

Performance-wise I get around 15% improvement over sphere-frustum test. You can also see how a single light performs as the following: from left to right (1) standard rendering of a point light; then tiles passed the test of (2) sphere-frustum test; (3) cone test; (4) spherical-sliced cone test

I put the details in my blog post (https://lxjk.github.io/2018/03/25/Improve-Tile-based-Light-Culling-with-Spherical-sliced-Cone.html), GLSL source code included!

Eric

• Good evening everyone!

I was wondering if there is something equivalent of  GL_NV_blend_equation_advanced for AMD?
Basically I'm trying to find more compatible version of it.

Thank you!

• Hello guys,

How do I know? Why does wavefront not show for me?
I already checked I have non errors yet.

And my download (mega.nz) should it is original but I tried no success...
- Add blend source and png file here I have tried tried,.....

PS: Why is our community not active? I wait very longer. Stop to lie me!
Thanks !

• I wasn't sure if this would be the right place for a topic like this so sorry if it isn't.
I'm currently working on a project for Uni using FreeGLUT to make a simple solar system simulation. I've got to the point where I've implemented all the planets and have used a Scene Graph to link them all together. The issue I'm having with now though is basically the planets and moons orbit correctly at their own orbit speeds.
I'm not really experienced with using matrices for stuff like this so It's likely why I can't figure out how exactly to get it working. This is where I'm applying the transformation matrices, as well as pushing and popping them. This is within the Render function that every planet including the sun and moons will have and run.
if (tag != "Sun") { glRotatef(orbitAngle, orbitRotation.X, orbitRotation.Y, orbitRotation.Z); } glPushMatrix(); glTranslatef(position.X, position.Y, position.Z); glRotatef(rotationAngle, rotation.X, rotation.Y, rotation.Z); glScalef(scale.X, scale.Y, scale.Z); glDrawElements(GL_TRIANGLES, mesh->indiceCount, GL_UNSIGNED_SHORT, mesh->indices); if (tag != "Sun") { glPopMatrix(); } The "If(tag != "Sun")" parts are my attempts are getting the planets to orbit correctly though it likely isn't the way I'm meant to be doing it. So I was wondering if someone would be able to help me? As I really don't have an idea on what I would do to get it working. Using the if statement is truthfully the closest I've got to it working but there are still weird effects like the planets orbiting faster then they should depending on the number of planets actually be updated/rendered.

• Hello everyone,
I have problem with texture

This topic is 973 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

i am working on the Light at my Android OpenGL-ES 2D-Application. I have a problem with calculating the distance between Lightsource and pixel.
precision mediump float;
varying vec4 v_Color;
varying vec2 v_texCoord;
uniform vec3 uLightPos; //xy = 2dPos, z = radius
uniform sampler2D s_texture;
void main() {
float d = distance(uLightPos.xy, gl_FragCoord.xy); //calculate distance
float att = 1.0/(0.05 + (0.001 * d) + (0.0001 * d * d)); //attunation
gl_FragColor = texture2D( s_texture, v_texCoord ) * v_Color * vec4(att, att, att, 1.0); //LightColor = diffuseColor
}else
gl_FragColor = vec4(0.0, 0.0, 0.0, 1.0);
}


If the radius is 250.0f everything works! I can see the Light and the Light "is cutted off" at 250 pixel away from the Lightsource.

Now my Problem: if the radius is set to 300.0f the Light gets never "cutted off". I tested it with dynamic values.. between 250.0f and 300.0f is a point, where it stops working. In conclusion: The distance never increases to a higher value than this point. This also affects the light attunation! It never gets completly dark... there is a constant light after this point. Am i calculating the distance wrong?

Here are the two states:

Edited by lolxdfly

##### Share on other sites

can you be more specific ?

gl_FragCoord.xy returns not the thing you want you should get distance in WORLD SPACE instead of screen space. so when you pass vertex position in vertex shader you pass the same value to fragment data.

then tell me if you really do that thing with the pixel radius.

anyway it looks like you are doing it whole wrong since when you pass vertex in vertex shader you do multiple by MVP matrix then you pass that result to fragment shader.

lets say its:

varying vec4 uVertexPosition;

uniform float SCREEN_WIDTH;

uniform float SCREEN_HEIGHT;

//now that will work for perspective projection and i assume you use perespective calculation:

so then you should do:

uVertexPosition = uVertexPosition / uVertexPosition.w;

uVertexPosition = uVertexPosition * 0.5 + 0.5;

float vec2 vertex_pos = vec2( uVertexPosition.x * SCREEN_WIDTH, uVertexPosition.y * SCREEN_HEIGHT );

then you can actually check for distance (assuming light is in screen space)

the att factor still seems wrong

try

	float dst = distance(uLightPosition.xy, vertex_pos);
float intensity = clamp(1.0 - dst / uLightPosition.z, 0.0, 1.0);
vec4 color = vec4(LDIFF.x, LDIFF.y, LDIFF.z, 1.0)*intensity;
LDIFF is light diffuse color - last 1.0 alpha value depends on blending you want to use
gl_FragColor = color;

Edited by WiredCat

##### Share on other sites

Sounds like a precision issue to me. Your math is being done at mediump which could have a maximum range of -16384 to 16384, which is quite a lot more than your 250-300 but do bear in mind that the distance function is almost certainly having to square. In fact, maybe the compiler is smart enough to remove the square root from the 'distance' function and compare with your radius squared (which can be calculated per draw call) instead of using radius.

First up, if you have a device that supports highp in the pixel shader try just changing 'precision mediump float;' to 'precision highp float;'. If that fixes it then we're on the right track.

But I wouldn't stop there because lots of Android devices don't support that. Try doing your lighting math in normalized screen coordinates instead of pixel coordinates maybe? (i.e. divide both the pixel pos and the light pos by the screen height or the screen width)

##### Share on other sites

First up, if you have a device that supports highp in the pixel shader try just changing 'precision mediump float;' to 'precision highp float;'. If that fixes it then we're on the right track.

That fixed it... thanks
I changed the distance calulation into:

float d = distance((gl_FragCoord.xy - vec2(0.5, 0.5)) / 1080.0, LightPos.xy / 1080.0) * 1080.0;


can you be more specific ?

gl_FragCoord.xy returns not the thing you want you should get distance in WORLD SPACE instead of screen space. so when you pass vertex position in vertex shader you pass the same value to fragment data.

then tell me if you really do that thing with the pixel radius.

anyway it looks like you are doing it whole wrong since when you pass vertex in vertex shader you do multiple by MVP matrix then you pass that result to fragment shader.

lets say its:
varying vec4 uVertexPosition;

uniform float SCREEN_WIDTH;
uniform float SCREEN_HEIGHT;

//now that will work for perspective projection and i assume you use perespective calculation:

so then you should do:

uVertexPosition = uVertexPosition / uVertexPosition.w;
uVertexPosition = uVertexPosition * 0.5 + 0.5;

float vec2 vertex_pos = vec2( uVertexPosition.x * SCREEN_WIDTH, uVertexPosition.y * SCREEN_HEIGHT );

then you can actually check for distance (assuming light is in screen space)

the att factor still seems wrong

try

	float dst = distance(uLightPosition.xy, vertex_pos);
float intensity = clamp(1.0 - dst / uLightPosition.z, 0.0, 1.0);
vec4 color = vec4(LDIFF.x, LDIFF.y, LDIFF.z, 1.0)*intensity;
LDIFF is light diffuse color - last 1.0 alpha value depends on blending you want to use
gl_FragColor = color;


My World Coords are the same like the Pixel Coords so i.e. the bottomleft(1920, 1080) of my screen is the world coord (1920, 1080).

uniform mat4 uMVPMatrix;
attribute vec4 vPosition;
attribute vec4 a_Color;
attribute vec2 a_texCoord;
varying vec4 v_Color;
varying vec2 v_texCoord;
void main() {
gl_Position = uMVPMatrix * vPosition;
v_texCoord = a_texCoord;
v_Color = a_Color;
}


This was my first attenuation formula: clamp(1.0 - dst / uLightPosition.z, 0.0, 1.0);. That is partly better, because it gets 0. The "Constant-Linear-Quadratic" attenuation never gets 0, but it has 3 factors to form the light. Note that the explanation from the link does not fit exactly to my formula! My complete Lightshader is not finished (LightColor, Ambient missing)!

Edited by lolxdfly