Advertisement Jump to content
  • Advertisement

#Include Graphics

  • Content Count

  • Joined

  • Last visited

Community Reputation

1046 Excellent

About #Include Graphics

  • Rank

Personal Information

  • Role
    Technical Director
  • Interests
  1. #Include Graphics

    BRE Engine Architecture

    So great Nicolas. You are great by sharing this with everyone! Hope your dreams come true. Being like this something nice is happening to you for sure. :wub:
  2. Hi Everyone,   I just have this doubt because I dont want to make it too fancy... its there a common/known way of exporting a model with different effect files and each file with its own preprocessor directives(macros)? Maybe it is better doing this on a post export step?   Thanks in advance.
  3. #Include Graphics

    Present method is taking for too long...

    Thanks a lot for the info Jesse you were so helpful.
  4. #Include Graphics

    Present method is taking for too long...

    No sorry, I think Hodgman and me were right. If you have one backbuffer then you have your current buffer and that one, so you are using two render buffers(double buffer). If you have two backbuffer then you have your current buffer and that two, so you are using three render buffers(triple buffer). Here there is an old topic that clarifies about:
  5. #Include Graphics

    Present method is taking for too long...

    Yes, I realized with Hodgman wise share that I were meassuring cpu time. Now I need to know howto make the CPU not stall more than the needed on the Present. So it can process the next frame until arrives to the next Present and then stall. I use a BackBufferCount = 2 (I think its triple buffer, isnt it? ) am I wrong if supposing this will do the trick? or should I have to use some special flags on the behaviourFlags? Recently saw D3DPRESENT_DONOTWAIT but really seems to be quite tricky and buggy.
  6. Hi everyone! Just wanted to check out if those times are common or not. Actually in the render loop the time consumption is shared by this processes(high level view): - World ( 0.000482142845 sc ) - Shadows ( 0.000348214293 sc ) - Post processing ( 0.000352678559 sc ) - UI ( 0.000214285712 sc ) - Present ( 0.0351071432 sc )   As we can see the Present method which is the direct call to the directX API in the way d3dDevice->Present( NULL, NULL, NULL, NULL ) is geting huge time compared with any other process. - I am actually using vsync off. - SwapEffect       = D3DSWAPEFFECT_FLIP or D3DSWAPEFFECT_DISCARD So my question now is... is that normal? am I be doing something wrong? is there a common fast way to prepare everything for a faster Present? May someone please enlight me? :D Please share ideas...maybe I am wrong but intuitively think that there is something more behind.   Thanks so much in advance.
  7. #Include Graphics

    Moire' patterns

    Splatting is what you are looking for mate. Build up a nice mask weight each texture visibility properly so you get a consistent blend between them. I used three very different textures (obviously each of them separatedly had a  lot of patterns when tiled lonely). As an addition you can also add a random occlusion factor via a noise texture(blurred in my case worked so nice).     That didnt work to me due to the high identity lose of the textures. Although it contributes reducing the patterns, its true, It produces chaotic results if you are trying to get well defined faithful results.   Hope it helps to you!
  8. #Include Graphics

    Rendering Water as a Post-process Effect

  9. #Include Graphics

    Retrieving World Position in Deferred Rendering

    I think eveybody is in vacations. I will try to give you a  hand mate.   Here is a document from the great MJP, it helped me a  lot once:   Explained there is a nice optimization also too based on the screen aligned vertex positions. Very cool indeed.   Hope it helps you as did it to me. :)
  10. #Include Graphics

    Shadow Map Silhouette Revectorization (SMSR)

    I were about to say what Laury did, so I think you really should have to apply it to your color buffer also too! That will will you a lot less global aliasing.   By the way, nice article. Congrats and many thanks! :)
  11. #Include Graphics

    A phenomenological scattering model

    Does any of those Transparency methods(stocastic, weighted) work on Dx9?
  12. #Include Graphics

    supersampling implementation

    I have always done this by rendering a screen quad and then applying a linear filter to the sampler. The idea may not look very good but it is possibly the best way you can do it since StretchRect is not more on the graphics api.   For more info about take a look at this link:   Hope it helps
  13. #Include Graphics

    HLSL SM3 Loop into a 1280x720 sampler texture

    Oh, If I offended anyone my apologizies from the heart. Wasnt my intention.
  14. #Include Graphics

    HLSL SM3 Loop into a 1280x720 sampler texture

    Thx a lot for your support here anyway Hodgman and mhagain.   What kind of indirect lighting algorithm requires you to sample every pixel on the framebuffer?     I am experimenting... what more can I tell you :D   Just did it this way and wanted to test with more samples for contrastation purposes. But the hardware industry seems to not be on my side this time? well, hahaha   Is there any way of doing indirect ilumination on real time now without prebaked probes?
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!