Sign in to follow this  
Expandable

OpenGL Portal based visibility checks

Recommended Posts

Hello everybody, I need your help. I've been working on this problem for two days now and I still didn't even get closer to a solution. I use portals for visibility determination (very similar to DOOM 3's system). So I have an area, where the camera is in. I draw that area. I extract the 3d view frustum from the OpenGL matrices. If a portal of the current area is within the frustum, I also draw the portal's other area. That works fine. My problem is: In that other area, I have to check if any other portals are visible. Now how do I do that? I can't use the OpenGL matrices for that, but I have to recalculate the frustum. Now the near clipping plane is the portal itself. I thought it would'nt be too difficult to geometrically construct the frustum, but I never got that working. So I searched for some tutorials, and I read that it would be easier to transform the portal's vertices into 2D coordinates on the screen. I came up with my own solution do to this, after that I found out that gluProject() would've done the same thing for me. But oddly enough, my own solution as well as gluProject() produce the same output - which can't be right, though. Or did I missunderstand what gluProject does? I thought that a vertex, let's say it's positioned at (22, 11, -33) and drawn as a point, has specific 2D coordinates, let's say (443, 222). So if I let gluProject() calculate the 2D coordinates of (22, 11, -33), shouldn't the output be (443, 222)? Meaning that, if I draw the vertex (22, 11, -33) in 3D first, and after that I draw the vertex (443, 222) in 2D, only the 2D vertex should be visible as it overdraws the 3D vertex? I really need some help here, so thanks a lot in advance!

Share this post


Link to post
Share on other sites
This is not gonna to do the trick,since the vertexes might be outside the frustum while some part of,containing no vertexes might be inside and not obscured by any occluder.
I do portal checking by combined frustum test(for Bounding box of the portal) and Occlusion Queries.Works like silk.

Share this post


Link to post
Share on other sites
Quote:
Original post by DarkMessiaH
This is not gonna to do the trick,since the vertexes might be outside the frustum while some part of,containing no vertexes might be inside and not obscured by any occluder.
I do portal checking by combined frustum test(for Bounding box of the portal) and Occlusion Queries.Works like silk.


Edit: Nonsense... I thought about occlusion queries. But the problem is that I do NOT want to draw the portal itself... and I'm already drawing my geometry while still performing portal visiblity checks... how do you do that?

Furthermore, if you use frustum culling, how do you calculate the frustum? I mean, the current view frustum can easily be extracted from the OpenGL matrices, but all other frustums, where the near plane is the portal itself, have to be geometrically constructed. I had the problem that I didn't know how to verify that all normals are facing inwards... but anyway, I'm more into the 2d approach now, I think I might get it to work correctly... but any help would still be appreciated!

[Edited by - Expandable on March 7, 2006 7:29:20 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by DarkMessiaH
I do portal checking by combined frustum test(for Bounding box of the portal) and Occlusion Queries.Works like silk.


You're right.

I just implemented the portal visibility checking by using occulsion queries . The code is extremly elegant and it works perfectly. In fact, it works by far better than I expected, because if you draw the area you're currently in and then
check the visibility of the portals of that area with occlusion queries you also don't draw the portal if it's behind your geometry... and that check is basically for free if you use occlusion queries anyways... If you repeat these steps for every visible area/portal you have an extremly good culling mechanism!

So thanks for your help!

The only problem I have now is that when you are too close to a portal, the portal seems to be outside the view frustum (between the camera and the near clipping plane), so the next area is not rendered. Hmm... any ideas?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Partner Spotlight

  • Forum Statistics

    • Total Topics
      627638
    • Total Posts
      2978327
  • Similar Content

    • By xhcao
      Before using void glBindImageTexture(    GLuint unit, GLuint texture, GLint level, GLboolean layered, GLint layer, GLenum access, GLenum format), does need to make sure that texture is completeness. 
    • By cebugdev
      hi guys, 
      are there any books, link online or any other resources that discusses on how to build special effects such as magic, lightning, etc. in OpenGL? i mean, yeah most of them are using particles but im looking for resources specifically on how to manipulate the particles to look like an effect that can be use for games,. i did fire particle before, and I want to learn how to do the other 'magic' as well.
      Like are there one book or link(cant find in google) that atleast featured how to make different particle effects in OpenGL (or DirectX)? If there is no one stop shop for it, maybe ill just look for some tips on how to make a particle engine that is flexible enough to enable me to design different effects/magic 
      let me know if you guys have recommendations.
      Thank you in advance!
    • By dud3
      How do we rotate the camera around x axis 360 degrees, without having the strange effect as in my video below? 
      Mine behaves exactly the same way spherical coordinates would, I'm using euler angles.
      Tried googling, but couldn't find a proper answer, guessing I don't know what exactly to google for, googled 'rotate 360 around x axis', got no proper answers.
       
      References:
      Code: https://pastebin.com/Hcshj3FQ
      The video shows the difference between blender and my rotation:
       
    • By Defend
      I've had a Google around for this but haven't yet found some solid advice. There is a lot of "it depends", but I'm not sure on what.
      My question is what's a good rule of thumb to follow when it comes to creating/using VBOs & VAOs? As in, when should I use multiple or when should I not? My understanding so far is that if I need a new VBO, then I need a new VAO. So when it comes to rendering multiple objects I can either:
      * make lots of VAO/VBO pairs and flip through them to render different objects, or
      * make one big VBO and jump around its memory to render different objects. 
      I also understand that if I need to render objects with different vertex attributes, then a new VAO is necessary in this case.
      If that "it depends" really is quite variable, what's best for a beginner with OpenGL, assuming that better approaches can be learnt later with better understanding?
       
    • By test opty
      Hello all,
       
      On my Windows 7 x64 machine I wrote the code below on VS 2017 and ran it.
      #include <glad/glad.h>  #include <GLFW/glfw3.h> #include <std_lib_facilities_4.h> using namespace std; void framebuffer_size_callback(GLFWwindow* window , int width, int height) {     glViewport(0, 0, width, height); } //****************************** void processInput(GLFWwindow* window) {     if (glfwGetKey(window, GLFW_KEY_ESCAPE) == GLFW_PRESS)         glfwSetWindowShouldClose(window, true); } //********************************* int main() {     glfwInit();     glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);     glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);     glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);     //glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE);     GLFWwindow* window = glfwCreateWindow(800, 600, "LearnOpenGL", nullptr, nullptr);     if (window == nullptr)     {         cout << "Failed to create GLFW window" << endl;         glfwTerminate();         return -1;     }     glfwMakeContextCurrent(window);     if (!gladLoadGLLoader((GLADloadproc)glfwGetProcAddress))     {         cout << "Failed to initialize GLAD" << endl;         return -1;     }     glViewport(0, 0, 600, 480);     glfwSetFramebufferSizeCallback(window, framebuffer_size_callback);     glClearColor(0.2f, 0.3f, 0.3f, 1.0f);     glClear(GL_COLOR_BUFFER_BIT);     while (!glfwWindowShouldClose(window))     {         processInput(window);         glfwSwapBuffers(window);         glfwPollEvents();     }     glfwTerminate();     return 0; }  
      The result should be a fixed dark green-blueish color as the end of here. But the color of my window turns from black to green-blueish repeatedly in high speed! I thought it might be a problem with my Graphics card driver but I've updated it and it's: NVIDIA GeForce GTX 750 Ti.
      What is the problem and how to solve it please?
  • Popular Now