johnchapman

Members
  • Content count

    84
  • Joined

  • Last visited

Community Reputation

601 Good

About johnchapman

  • Rank
    Member

Personal Information

  1.   He's written his name into history with that silly voice!
  2.   Ah, thanks for clearing that up. I was thinking that you were skipping the sort in this case.
  3. This is interesting, although I'm a little confused about how the scheme outlined by L Spiro works, specifically:   Is it not possible that the total could be the same between two frames, but that items in the render queue (after culling) are different? In this case the indices won't necessarily point to the same items as in the previous frame, and the queue would need to be re-sorted.
  4. Here's a tech demo I "completed" (i.e. stopped working on) a couple of years back, which has a couple of nice features although it's quite dated now:   http://youtu.be/dNn1wYWaL6w   Same software, with a more organic-looking scene:   http://youtu.be/5NTSk6fJCJ4  
  5. http://oglplus.org/   Writing your own wrapper can be quite a good way to explore the API, but be warned that it's easy to get bogged down trying to 'redesign' OpenGL. Personally I just use some simple object-oriented wrappers that handle things like creating textures/framebuffers/shaders, plus some logging/debugging stuff.
  6. Do you extend GLSL?

    Like Promit, I have a somewhat hacky preprocessor which manages #includes but not much else. For experimental and small scale projects you don't really need anything more. A serious renderer would probably require a more complete system for things like generating shader permutations. External #defines are a good mechanism for that sort of thing. 
  7. There's an adaptive supersampling approach outlined here which may also be of interest.
  8. #pragma optimize isn't in the spec, so probably isn't supported on your implementation.   I think the best solution will be to make your application code more robust, e.g. check to see if glGetAttribLocation() returns -1 to avoid enabling attributes that have been optimized out, etc.
  9. [quote name='ic0de' timestamp='1352517176' post='4999522'] I really don't like the way motion blur looks [/quote] There are a number of different approaches to motion blur and a number of variables that can be tweaked which will change the overall 'look'; for smoother camera motion you can use a simple camera-only motion blur post process and adjust the blur kernel size to balance smooth motion against a blurry image (tutorial [url="http://www.john-chapman.net/content.php?id=11"]here[/url]). I find that at around 60Hz the effect isn't noticeable beyond making the camera motion look more fluid. [quote name='LorenzoGatti' timestamp='1352709485' post='5000159'] But what do you have against motion blur, apart from its terrible computational burden [/quote] Depending on the implementation it's really not very computationally expensive.
  10. Deferred shading - light accumulation issue

    Typically when accumulating lights you'll need to enable blending, so that the result of the fragment shader gets combined with what's already in the buffer (i.e. the result from previous lights): glClear(GL_COLOR_BUFFER_BIT); // clear light accumulation buffer to black here glEnable(GL_BLEND); glBlendFunc(GL_ONE, GL_ONE); // additive blending // render lights glDisable(GL_BLEND);
  11. [D3D11]Raindrop effect

    I seem to recall reading about this in one of the GPU Pro series, using sun shadows to determine where raindrops can/can't fall. It's a nice idea! Could also be used to apply 'wetting' to the scene in screen space.
  12. SSAO artifacts

    It looks to me as though your sample kernel's radius is quite small, such that it's causing some erroneous occlusion on the floor where the triangles intersect. Try increasing the sample kernel radius to see if that alleviates the problem.
  13. There's a short overview here: http://developer.amd.com/documentation/presentations/legacy/Chapter8-Mittring-Finding_NextGen_CryEngine2.pdf
  14. Assembly Programming

    If you're aiming at OS dev, here's a pretty good resource: [url="http://www.osdever.net/"]http://www.osdever.net/[/url] This tutorial in particular: [url="http://www.osdever.net/tutorials/view/brans-kernel-development-tutorial"]http://www.osdever.n...opment-tutorial[/url] There's a free book, "Art of Assembly Language Programming". I've never really looked at it but it seems quite comprehensive: [url="http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/index.html"]http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/index.html[/url] There are Intel system programmer manuals and things like that on the Intel website which is a good source once you get going with the x86.
  15. [quote name='mg_mchenry' timestamp='1339792572' post='4949650'] there is no point in per-pixel lighting with a directional light. You need point lighting. [/quote] There should be a difference if you've implemented it correctly. Remember to renormalize the incoming interpolated normals in the fragment shader.