• 10
• 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 OpenGL legacy to shader mapping

## Recommended Posts

I'm trying to get some legacy OpenGL code to run with a shader pipeline,

The legacy code uses glVertexPointer(), glColorPointer(), glNormalPointer() and glTexCoordPointer() to supply the vertex information.
I know that it should be using setVertexAttribPointer() etc to clearly define the layout but that is not an option right now since the legacy code can't be modified to that extent.

I've got a version 330 vertex shader to somewhat work:

#version 330

uniform mat4 osg_ModelViewProjectionMatrix;
uniform mat4 osg_ModelViewMatrix;

layout(location = 0) in vec4 Vertex;
layout(location = 2) in vec4 Normal; // Velocity
layout(location = 3) in vec3 TexCoord; // TODO: is this the right layout location?

out VertexData {
vec4 color;
vec3 velocity;
float size;
} VertexOut;

void main(void)
{
vec4 p0 = Vertex;
vec4 p1 = Vertex + vec4(Normal.x, Normal.y, Normal.z, 0.0f);
vec3 velocity = (osg_ModelViewProjectionMatrix * p1 - osg_ModelViewProjectionMatrix * p0).xyz;

VertexOut.velocity = velocity;
VertexOut.size = TexCoord.y;
gl_Position = osg_ModelViewMatrix * Vertex;
}

What works is the Vertex and Normal information that the legacy C++ OpenGL code seem to provide in layout location 0 and 2. This is fine.

What I'm not getting to work is the TexCoord information that is supplied by a glTexCoordPointer() call in C++.

Question:

What layout location is the old standard pipeline using for glTexCoordPointer()? Or is this undefined?

Side note: I'm trying to get an OpenSceneGraph 3.4.0 particle system to use custom vertex, geometry and fragment shaders for rendering the particles.

##### Share on other sites

The only well-defined standard location is 0 for the vertex position attribute. The use of location 2 for normals and similarly for other attributes is a NVIDIA-specific thing, and will most probably break you hard on other vendors.

Please see this discussion on SO: https://stackoverflow.com/a/528824/87969

If you only care about those devices and are happy to rely on vendor-specific behaviour, the mapping should then be that gl_MultiTexCoord0 is at location 8, according to the docs.

##### Share on other sites

Thank you Zao, you saved my day! You gave the exact answer I was looking for.

I had my doubts about interoperability between legacy and modern OpenGL, and you confirmed it. It is however as you say, the texture coordinate was to be found at position 8 when I tested it, but since this may be NVIDIA specific I have to find a way around it.