• 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

# OpenGL GLSL v1.3 - normals incorrect when not using gl_Normal

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

## Recommended Posts

I recently bought the third edition of the orange OpenGL Shader Language and found that a lot had changed since the OpenGL Superbible was last updated. One of the biggest changes was that global uniforms such as gl_Vertex and gl_Normal were deprecated, and instead we were to use the 'in' keyword to show we are expecting input. One problem: the Vertices seem fine, but the normals given to me seem incorrect. If i use gl_Normal my shader works fine, but if i use the following line: "in vec3 MCnormal;", the normal never seems to change. I'm rendering a glutSolidTorus, so the normals should be correct, and as I said before, if i just reference "gl_Normal" i get results. Any idea why this is? I'm still learning the changes surrounding OpenGL 3.2, so perhaps I'm missing something in my code? Besides passing in the ModelViewMatrix, ModelViewProjectionMatrix and NormalMatrix, everything else seems to be basically the same. Vertex Shader:
#version 130

in vec4 MCvertex;
in vec3 MCnormal;

uniform mat4 MVMatrix;
uniform mat4 MVPMatrix;
uniform mat4 NormalMatrix;

out float LightIntensity;

void main()
{
float diffuse = 0.7;
vec3 lightPos = vec3(0,10,0);
mat3 NMat = mat3(NormalMatrix);

vec3 position = vec3(MCvertex * MVMatrix);

vec3 L = normalize(lightPos - position);

vec3 N = normalize(NMat * normalize(MCnormal));

LightIntensity = diffuse * max(dot(N, L), 0.0);

gl_Position = MCvertex * MVMatrix * MVPMatrix;
}

#version 130

in float LightIntensity;

out vec4 FragColor;

void main()
{
FragColor = vec4(LightIntensity, LightIntensity, LightIntensity, 1.0);
}


##### Share on other sites
First of all, gl_Vertex and gl_Normal are not uniforms. You have to make a distinction between uniforms and attributes.

A think that you have a problem with passing values to that attribute. Check if you have passed correct parameters to glVertexAttribPointer() corresponding to MCnormal, and if you have enabled it by glEnableVertexAttribArray().

##### Share on other sites
Sorry, I meant attributes. I was thinking of all of the matrices (ModelView, ModelViewProjection etc...)

I looked more into this issue, and found many people are sending the vertex and normal data in through buffers, however I am using the glutSolidTorus() function, which renders the object for me. I don't have access to its normals or vertices, so I don't think I can use glVertexAttribPointer().

Any suggestions? Do functions like glutSolidTorus and glutSolidSphere no longer operate the way they are supposed to because of this new way of passing information to the shaders?

##### Share on other sites
Why didn't say that you are using glut? Take a look at the release date of the library! [smile]

Let's be serious. Using attribute like in vec3 MCnormal does not mean anything to OpenGL. Only you know that it is a normal, but nobody else. So, you have to fill some buffer with appropriate values and send it to the shaders. The only advice I can give you is to try to implement all objects by yourself. It is not hard and you will get full control over them.

Not using deprecated functionality means demolishing the whole mountains of functionality, unfortunately... [depressed]

##### Share on other sites
glutSolid* uses the deprecated/removed default attributes, you can't use them with custom attributes.

##### Share on other sites
So the standards for glsl 130 more or less disallow the use of glutSolid* calls. Does that mean that we no longer have access to simple primitives? I feel this significantly complicates things.

Does this mean that all glNormal calls are now deprecated? Can we no longer use glBegin and glEnd with simple vertex, normal, and color calls to define simple polygons?

##### Share on other sites
Quote:
 Original post by PirosanDoes this mean that all glNormal calls are now deprecated? Can we no longer use glBegin and glEnd with simple vertex, normal, and color calls to define simple polygons?

Deprecated means that will be removed in next GL versions, but all drivers still supports them, and will support them for a very long time.

They were moved to the compatibility profile in OpenGL 3.2, and they aren't present in the core profile. Just choose whatever fits to you.

##### Share on other sites
That is understandable. Any idea if the glut libraries will ever be updated to follow this new standard?

Also, through all of this I have found a profound lack of clear tutorials or documentation on glsl 130 or higher. most of my problems stemmed from the book i was referencing (OpenGL Shading Language, 3rd Edition,) which doesn't have ANY source code beyond the vertex and fragment shaders to clear things up. It then took a lot of work to find out how to bring my code into the 'core' profile.

I would just like to see how other people are handling the new standards. Much of my work has been touch and go so far.

##### Share on other sites
Quote:
 Original post by PirosanAny idea if the glut libraries will ever be updated to follow this new standard?
Freeglut, maybe. GLUT itself was abandoned 12 years ago.

In general, however, basic primitives are not useful for anything other than brief tests - and those are simple enough to handle with a model loaded from OBJ/similar format.