ShaderList property on orxOBJECT

edited November 2009 in Help request
Hi,

I'm kinda stuck trying to understand how ShaderList set on the object is supposed to work. My first guess was that shader on the orxVIEWPORT will provide a post-processing for the entire viewport. Analogous to that ShaderList on the orxOBJECT would execute fragment shader for this object alone. Unfortunately what I see based on my tests is that in both cases we get a fullscreen post-processing.

I looked at the ORX source and what I see is that orxDisplay_RenderShader is being called from the orxShader.c and since only SFML provides OGL support, corresponding call in orxDisplay from orxDisplay_SFML project is being triggered (orxDisplay_SFML_RenderShader).

What SFML implementation does is calling Draw with appropriate PostFX parameter on sstDisplay.poRenderWindow. I'm not familiar with SFML internals (and didn't have time to dig into it yet) but based on skimming the docs I'm guessing that sstDisplay.poRenderWindow is pretty much a representation of a viewport (or entire window). This would jive with what I see (ShaderList works "fullscreen", regardless of where it's set).

So my questions are:
- is ShaderList on orxOBJECT supposed to excecute fragment shader for this object alone?
- if no, why?
- if yes, am I doing something wrong or am I right that this feature needs some code changes in ORX?

Thanks in advance,
Dom

Comments

  • edited November 2009
    Ryan wrote:
    Hi,

    Hi Ryan and welcome!
    I'm kinda stuck trying to understand how ShaderList set on the object is supposed to work. My first guess was that shader on the orxVIEWPORT will provide a post-processing for the entire viewport. Analogous to that ShaderList on the orxOBJECT would execute fragment shader for this object alone. Unfortunately what I see based on my tests is that in both cases we get a fullscreen post-processing.

    The intent was indeed to have a shader on a orxVIEWPORT or a orxOBJECT do post-processing on them, respectfully. However, the way fragment shaders are implemented in SFML doesn't allow that.

    Actually, SFML does only allow very simple fragment shaders (one function shaders) that can have different textures as inputs but only the screen as output. In the same way, rendering can only be done on the screen and not on other textures. Orx was created with the idea of supporting rendering on non-screen textures, but if you use this feature with the SFML plugin you'll get error messages telling you it's not feasible with that plugin.

    Both these limitations (plus a couple of other motivations) make me want to develop SDL/OpenGL plugins for orx and use them as primary plugins. That is my current task but I'm lacking of free time lately, so a task that would take a couple of days might end up taking a couple of weeks or even months.
    I looked at the ORX source and what I see is that orxDisplay_RenderShader is being called from the orxShader.c and since only SFML provides OGL support, corresponding call in orxDisplay from orxDisplay_SFML project is being triggered (orxDisplay_SFML_RenderShader).

    What SFML implementation does is calling Draw with appropriate PostFX parameter on sstDisplay.poRenderWindow. I'm not familiar with SFML internals (and didn't have time to dig into it yet) but based on skimming the docs I'm guessing that sstDisplay.poRenderWindow is pretty much a representation of a viewport (or entire window). This would jive with what I see (ShaderList works "fullscreen", regardless of where it's set).

    A faster approach in the short term would be to patch orx's version of SFML in order to obtain a proper behavior. That's what I began when I fixed shader parsing issues in SFML and the one-function limitation. However, as I never wrote any shader-related code before that, I wasn't feeling comfortable enough to change SFML's implementation and I went on other tasks (also orx's users base was small enough I was comfident no-one would use the ShaderList before I figure out a proper solution, but it turns out I was wrong :)).
    So my questions are:
    - is ShaderList on orxOBJECT supposed to excecute fragment shader for this object alone?
    - if no, why?

    It is meant to do so, but the SFML plugin for orx doesn't comply with that yet. However, it still makes sure the shader list is applied right after your object and/or viewport has been rendered.
    - if yes, am I doing something wrong or am I right that this feature needs some code changes in ORX?

    Due to the SFML implementation of it. It could be fixed with not too much trouble I presume, but I'm no expert in the shader field. I foresee no direct change in orx though, except maybe a direct named reference to the output texture.

    The SDL/OpenGL plugin should fix both these limitations and the rendering on non-screen texture (it's already working, but not with OpenGL).
    However, the biggest task for the SDL/OpenGL plugin will be the font handling/rendering.

    That being said, I'm currently looking for the most suitable image loadind/saving library to use with that plugin. Candidates are libraries such as DevIL, SOIL, etc... I haven't used any of them so if you have any recommandations, I'd be happy to hear them! SDL_Image looks too limited in the number of supported formats.
    Thanks in advance,
    Dom

    You're welcome, hope my reply confirmed your analysis and expectations of the code. If you'd like to help in any way (SFML and/or SDL/OpenGL plugin), I'd be happy to have some support.

    I now have a question for you: would you mind telling us for how long you've been looking into orx, what do you like/dislike about and any other feedback you'd have? User feedbacks is precious and I'm afraid we don't get enough of them. One place do to so would maybe be the introduction post in the forum, but it is, of course, not mandatory.

    Hope this helped.

    - iarwain
  • edited November 2009
    Thanks for the quick response. :)

    I'm glad this is SFML limiation, as I expected, as this should be fairly easy to remedy. I'm looking at possible substitution for SFML (and additional display library) - I'll let you know if I manage to make per object shaders work with proper code changes.

    As for the image library - I don't see how limited set of formats supported by SDL_Image would be of any problem. Larger, commercial projects need proper art pipeline where at the end you get data in a small set of formats suitable for your projects. For small projects it's not that inconvenient to, say, convert everything to png/jpg (assuming these would be the only formats supported). I get the "it's better if it just works" argument, but I don't think this should be the most important criteria for the library. Just my 2 cents. :)

    I'll answer your question in the "New people!" thread in a bit.

    Cheers!
  • edited November 2009
    No problem for the quick response, lately I haven't much time to code so at least I can try to give as much support as I can on the forum! :)

    It's good to see new motivated people on the forum lately, keeps me motivated too. So if I can help in anyway, please let me know! :)

    As for the image library, I never actually used SDL_Image (I was an Allegro user back then, never used SDL much beside orx's plugin), but as it says on their site:
    Description: SDL_image is an image file loading library.

    My issue is that I need to have save support too. :)
    DevIL really looks nice, open source, and works well natively with SDL and openGL. If I don't find any other serious candidate I'll probably go with it. :)

    Going to check the "New people!" thread right now!
  • edited November 2009
    ORX uses save for the screenshot feature or something more? It's possible to implement BMP od TIFF save "by hand" really easily. I understand this would simplify ORX' functionality (right now it's possible to choose from a pretty wide range of format) but again in my view it's not a big deal. :) IMO saving to e.g. JPG is much worse (after all it causes loss in image quality).
  • edited November 2009
    Ah well, having a one liner to save in multiple format might be the dark side of the force, but I kind of like it. ;) Saves me time to do something else!
  • edited November 2009
    LOL, very true. The best code is the one you don't have to write. ;)
  • edited May 2010
    Hey Ryan,

    Not sure you're still around but I wanted to let you know that the SDL plugins for orx are almost ready.

    More specifically, the shaders can now be applied to only one object, a viewport or fullscreen as it was intended since the beginning. The performance have also been improved compared to the SFML plugin.

    This is only available on the svn right now (and not activated by default as the SFML plugins are still the default ones till I'm done with the audio SDL plugin) but will be part of the next release if everything goes well. :)
Sign In or Register to comment.