• Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • By racarate
      Hey everybody!
      I am trying to replicate all these cool on-screen debug visuals I see in all the SIGGRAPH and GDC talks, but I really don't know where to start.  The only resource I know of is almost 16 years old:
      http://number-none.com/product/Interactive Profiling, Part 1/index.html
      Does anybody have a more up-to-date reference?  Do people use minimal UI libraries like Dear ImgGui?  Also, If I am profiling OpenGL ES 3.0 (which doesn't have timer queries) is there really anything I can do to measure performance GPU-wise?  Or should I just chart CPU-side frame time?  I feel like this is something people re-invent for every game there has gotta be a tutorial out there... right?
       
       
    • By Achivai
      Hey, I am semi-new to 3d-programming and I've hit a snag. I have one object, let's call it Object A. This object has a long int array of 3d xyz-positions stored in it's vbo as an instanced attribute. I am using these numbers to instance object A a couple of thousand times. So far so good. 
      Now I've hit a point where I want to remove one of these instances of object A while the game is running, but I'm not quite sure how to go about it. At first my thought was to update the instanced attribute of Object A and change the positions to some dummy number that I could catch in the vertex shader and then decide there whether to draw the instance of Object A or not, but I think that would be expensive to do while the game is running, considering that it might have to be done several times every frame in some cases. 
      I'm not sure how to proceed, anyone have any tips?
    • By fleissi
      Hey guys!

      I'm new here and I recently started developing my own rendering engine. It's open source, based on OpenGL/DirectX and C++.
      The full source code is hosted on github:
      https://github.com/fleissna/flyEngine

      I would appreciate if people with experience in game development / engine desgin could take a look at my source code. I'm looking for honest, constructive criticism on how to improve the engine.
      I'm currently writing my master's thesis in computer science and in the recent year I've gone through all the basics about graphics programming, learned DirectX and OpenGL, read some articles on Nvidia GPU Gems, read books and integrated some of this stuff step by step into the engine.

      I know about the basics, but I feel like there is some missing link that I didn't get yet to merge all those little pieces together.

      Features I have so far:
      - Dynamic shader generation based on material properties
      - Dynamic sorting of meshes to be renderd based on shader and material
      - Rendering large amounts of static meshes
      - Hierarchical culling (detail + view frustum)
      - Limited support for dynamic (i.e. moving) meshes
      - Normal, Parallax and Relief Mapping implementations
      - Wind animations based on vertex displacement
      - A very basic integration of the Bullet physics engine
      - Procedural Grass generation
      - Some post processing effects (Depth of Field, Light Volumes, Screen Space Reflections, God Rays)
      - Caching mechanisms for textures, shaders, materials and meshes

      Features I would like to have:
      - Global illumination methods
      - Scalable physics
      - Occlusion culling
      - A nice procedural terrain generator
      - Scripting
      - Level Editing
      - Sound system
      - Optimization techniques

      Books I have so far:
      - Real-Time Rendering Third Edition
      - 3D Game Programming with DirectX 11
      - Vulkan Cookbook (not started yet)

      I hope you guys can take a look at my source code and if you're really motivated, feel free to contribute :-)
      There are some videos on youtube that demonstrate some of the features:
      Procedural grass on the GPU
      Procedural Terrain Engine
      Quadtree detail and view frustum culling

      The long term goal is to turn this into a commercial game engine. I'm aware that this is a very ambitious goal, but I'm sure it's possible if you work hard for it.

      Bye,

      Phil
    • By tj8146
      I have attached my project in a .zip file if you wish to run it for yourself.
      I am making a simple 2d top-down game and I am trying to run my code to see if my window creation is working and to see if my timer is also working with it. Every time I run it though I get errors. And when I fix those errors, more come, then the same errors keep appearing. I end up just going round in circles.  Is there anyone who could help with this? 
       
      Errors when I build my code:
      1>Renderer.cpp 1>c:\users\documents\opengl\game\game\renderer.h(15): error C2039: 'string': is not a member of 'std' 1>c:\program files (x86)\windows kits\10\include\10.0.16299.0\ucrt\stddef.h(18): note: see declaration of 'std' 1>c:\users\documents\opengl\game\game\renderer.h(15): error C2061: syntax error: identifier 'string' 1>c:\users\documents\opengl\game\game\renderer.cpp(28): error C2511: 'bool Game::Rendering::initialize(int,int,bool,std::string)': overloaded member function not found in 'Game::Rendering' 1>c:\users\documents\opengl\game\game\renderer.h(9): note: see declaration of 'Game::Rendering' 1>c:\users\documents\opengl\game\game\renderer.cpp(35): error C2597: illegal reference to non-static member 'Game::Rendering::window' 1>c:\users\documents\opengl\game\game\renderer.cpp(36): error C2597: illegal reference to non-static member 'Game::Rendering::window' 1>c:\users\documents\opengl\game\game\renderer.cpp(43): error C2597: illegal reference to non-static member 'Game::Rendering::window' 1>Done building project "Game.vcxproj" -- FAILED. ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========  
       
      Renderer.cpp
      #include <GL/glew.h> #include <GLFW/glfw3.h> #include "Renderer.h" #include "Timer.h" #include <iostream> namespace Game { GLFWwindow* window; /* Initialize the library */ Rendering::Rendering() { mClock = new Clock; } Rendering::~Rendering() { shutdown(); } bool Rendering::initialize(uint width, uint height, bool fullscreen, std::string window_title) { if (!glfwInit()) { return -1; } /* Create a windowed mode window and its OpenGL context */ window = glfwCreateWindow(640, 480, "Hello World", NULL, NULL); if (!window) { glfwTerminate(); return -1; } /* Make the window's context current */ glfwMakeContextCurrent(window); glViewport(0, 0, (GLsizei)width, (GLsizei)height); glOrtho(0, (GLsizei)width, (GLsizei)height, 0, 1, -1); glMatrixMode(GL_PROJECTION); glLoadIdentity(); glfwSwapInterval(1); glEnable(GL_SMOOTH); glEnable(GL_DEPTH_TEST); glEnable(GL_BLEND); glDepthFunc(GL_LEQUAL); glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST); glEnable(GL_TEXTURE_2D); glLoadIdentity(); return true; } bool Rendering::render() { /* Loop until the user closes the window */ if (!glfwWindowShouldClose(window)) return false; /* Render here */ mClock->reset(); glfwPollEvents(); if (mClock->step()) { glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); glfwSwapBuffers(window); mClock->update(); } return true; } void Rendering::shutdown() { glfwDestroyWindow(window); glfwTerminate(); } GLFWwindow* Rendering::getCurrentWindow() { return window; } } Renderer.h
      #pragma once namespace Game { class Clock; class Rendering { public: Rendering(); ~Rendering(); bool initialize(uint width, uint height, bool fullscreen, std::string window_title = "Rendering window"); void shutdown(); bool render(); GLFWwindow* getCurrentWindow(); private: GLFWwindow * window; Clock* mClock; }; } Timer.cpp
      #include <GL/glew.h> #include <GLFW/glfw3.h> #include <time.h> #include "Timer.h" namespace Game { Clock::Clock() : mTicksPerSecond(50), mSkipTics(1000 / mTicksPerSecond), mMaxFrameSkip(10), mLoops(0) { mLastTick = tick(); } Clock::~Clock() { } bool Clock::step() { if (tick() > mLastTick && mLoops < mMaxFrameSkip) return true; return false; } void Clock::reset() { mLoops = 0; } void Clock::update() { mLastTick += mSkipTics; mLoops++; } clock_t Clock::tick() { return clock(); } } TImer.h
      #pragma once #include "Common.h" namespace Game { class Clock { public: Clock(); ~Clock(); void update(); bool step(); void reset(); clock_t tick(); private: uint mTicksPerSecond; ufloat mSkipTics; uint mMaxFrameSkip; uint mLoops; uint mLastTick; }; } Common.h
      #pragma once #include <cstdio> #include <cstdlib> #include <ctime> #include <cstring> #include <cmath> #include <iostream> namespace Game { typedef unsigned char uchar; typedef unsigned short ushort; typedef unsigned int uint; typedef unsigned long ulong; typedef float ufloat; }  
      Game.zip
    • 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
  • Advertisement
  • Advertisement
Sign in to follow this  

OpenGL Questions about Deferred Shading

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello I'm thinking about implementing deferred shading in my 3D renderer to speed things up when rendering a scene with multiple light sources. With Deferred Shading, the scene needs to be rendered only once per frame from camera's PoV, storing the geometric attributes like normal and position for each pixel in a texture render target. Then we just need to render one fullscreen quad per each light source, using the texture we rendered to in first pass. Currently, I render as many times per frame as there are light sources and it tends to get really slow as scene complexity increases. Using OpenGL for rendering, BTW. Before I go about implementing this feature, however, I'd like to know if it incurs any serious restrictions. I've heard that doing transparency and alpha blending is really difficult. How about reflective/refractive surfaces? Does it well work with the PCF-filtered soft shadow mapping method?

Share this post


Link to post
Share on other sites
Advertisement
Hi,

I can't answer your questions, but i've got one to ask you : you're rendering once for each light ? Means that if you have 2 lights, you render your scene twice ?
If I didn't understood what you meant, then sorry. But if I understood well, then you should know that you can render a scene with up to 8 simultaneous lights in only 1 pass with almost any card.

Share this post


Link to post
Share on other sites
Yes. If I have 3 lights for example, the scene is rendered 3 times from camera's PoV and the contributions of each light source are accumulated in the framebuffer using additive (GL_ONE, GL_ONE) blending.

Unfortunately, rendering multiple lights per pass will probably cause the shader to exceed the maximum instruction count, as certain instructions need to be duplicated for each light source. The 10-sample PCF filtering feature already generates quite a lot of fragment shader instructions.

Share this post


Link to post
Share on other sites
Quote:
Original post by paic
Hi,

I can't answer your questions, but i've got one to ask you : you're rendering once for each light ? Means that if you have 2 lights, you render your scene twice ?
If I didn't understood what you meant, then sorry. But if I understood well, then you should know that you can render a scene with up to 8 simultaneous lights in only 1 pass with almost any card.


Paic, he's including shadows which basically forces an instant 1:1 light:scenepass ratio. Even Doom3 has 1:1 (in the best of times! GF4 is 2:1 and GF3 is 3:1). Btw, even for shadow maps, while it is in theory possible to do multiple lights in a pass, generally it's a bad idea to do so because storing multiple omni SMs will just chew through your memory like nothing, something that already becomes an issue when you have deferred rendering.

Anyways, to do alpha blending I believe you have to render that on top of the added lights in order to get proper results, I'm not sure though because I haven't done alpha in my deferred rendering demo yet.

Shadow maps work EXCELLENTLY with a deferred renderer, since (I'm guessing) you're doing the SMs in a pixel shader already.

Reflective surfaces I haven't thought much on, but I imagine you could either apply those in the G-Buffer pass while doing the ambient light at the same time (if you can spare the MRT) or just composite the reflective objects onto the final image like you would alpha blending.

Refractive surfaces should be a fairly trivial extension beyond adding alpha geometry, since it behaves in a similar way, just with an extra shader to do a screenspace texture lookup.

Share this post


Link to post
Share on other sites
Well you need a traditional forward renderer for translucent objects. Deferred rendering just doesnt lend itself to multi-layering, and the alternatives (like depth-peeling, and shading layers independently) just aren't fast enough to be useful.

If you also intend to occassionally alpha fade-out otherwise opaque objects, then be prepared for the pain and suffering of tuning your traditional rendering to match the deferred output perfectly, otherwise you'll get popping when the object switches from 100% opaque to 99% alpha.

Antialiasing is also a problem with the deferred model.

Share this post


Link to post
Share on other sites
Thanks everyone for your input! Alpha blending and deferred shading obviously don't work hand in hand, but I think I can manage without it. I think effects such as glass can be implemented using environment maps and refraction, thus rendering polygons in correct order shoudln't be a concern.

Am I right saying that alpha testing, on the other hand, does work? I mean textures that have either 100% opaque or fully transparent pixels - no actual blending taking place.

Share this post


Link to post
Share on other sites
Quote:
Original post by ZiM
Thanks everyone for your input! Alpha blending and deferred shading obviously don't work hand in hand, but I think I can manage without it. Am I right saying that alpha testing, on the other hand, should work? I mean textures that have either 100% opaque or fully transparent pixels - no blending between fragments taking place.


Alpha testing works with deferred shading without a problem.

Share this post


Link to post
Share on other sites
Deferred Shading Pros:
- geometry is processed only 1-2 times regardless of lighting complexity (for G-buffer material property rendering and for z-pass)
- only pixels inside light volumes are processed (use light geometry instead of fullscreen quad)

Deferred Shading Cons:
- huge bandwidth requirements (uncompressed G-buffer data is fetched for each light that illuminates the pixel)
- you have to use one homogenous material everywhere, e.g. if you plan to add specular masking you must render it for every material
- like others already mentioned alpha blending and antialiasing doesn't work

You can figure out workarounds for some of the cons, e.g. use dynamic branching to execute different shading model for a pixel or pack the G-buffer material properties to less bits or use indexed material textures in G-buffer or use stippling instead of alpha blending, but those are still fundamental problems in Deferred Shading.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement