• 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 Perspective Projection Matrix Confusion!

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

## Recommended Posts

Hello all!! :) All this time, I was using functions like gluPerspective() and D3DXMatrixPerspectiveFovLH() to create my Perspective projection matrix for my camera. Currently I am working on a 3D Engine that is going to support both 3D APIs (D3D10 and OpenGL, Currently only D3D10 Renderer is working). I want to create a "cross-3DAPI" camera and I want to create the perspective projection matrix manually. The thing is that I am very confused, I have looked the source code of various Open Source 3D Engines and each one calculates the Perspective projection matrix differently!
Lets say this is the matrix structure:

A       0       0       0
0       B       0       0
0       0       C       D
0       0       E       0

These is the different matrices I found:

A = cot(fovy / 2) / Aspect Ratio
B = cot(fovy / 2)
C = (zFar + zNear) / (zNear - zFar)
D = (2 * zFar * zNear) / (zNear - zFar)
E = -1

A = cot(fovy / 2)
B = cot(fovy / 2) * Aspect Ratio
C = (zFar + zNear) / (zFar - zNear)
D = -(2 * zFar * zNear) / (zFar - zNear)
E = 1

A = cot(fovy / 2) / Aspect Ratio
B = cot(fovy / 2)
C = zFar / (zFar - zNear)
D = -(zFar * zNear) / (zFar - zNear)
E = 1

If I keep searching I am sure I will find more perspective projection matrices calculations that are different from these three! Which of these is correct? What are the differences between a D3D10 perspective projection matrix and an OpenGL perspective Projection matrix? What I need to do to convert from one to the other? I am really confused! :/ Thanks for your time!!!

##### Share on other sites
Considering that you are planning to design an API-agnostic library, there are several issues to consider. These can be the source of your confusion:

1) Matrix memory layout: Row major vs. Column major
How are matrix elements stored in memory? Are they stored row by row or column by column? You can find more information here.

The moral of the story: choose one and stick with it!

2) Order of matrix multiplications:
Are matrices pre-multiplied (i.e. the OpenGL way) or post-multiplied(i.e. the Direct3D way) by vectors/matrices. Please note that the order of matrix multiplications has nothing to do with its memory layout! It's possible to write a matrix class that stores matrices in column major order but enforces a post-multiplication ordering. For instance, Wild Magic and Ogre both store matrices in row major order but enforce a pre-multiplication ordering.

The moral of the story: choose one and stick with it!

3) Coordinate system handedness: Right handed vs. Left handed coordinate systems

The moral of the story: choose on and stick with it!

4) OpenGL expects the camera to look down the negative Z-axis. Direct3D expects the camera to look down the positive Z-axis.

The moral of the story: choose one and stick with it!

5) OpenGL maps the view frustum into a unit cube ([-1,1] x [-1,1] x [-1,1]) centered at the origin. Direct3D maps the view frustum to [-1,1]x[-1,1]x[0,1].

The moral of the story: choose one and stick with it!

The moral of this post: It's all about conventions :)