by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    SNiLD
    @SNiLD
    anyway i added the techniques for GBuffer scheme manually to hydrax and skyx
    currently after long battle i finally get the skyx rendered, but hydrax still refuses to render
    the SSAO sample doesn't show how the compositors have to be put into a chain so that the final screen is rendered
    but the deferred shading sample shows that to some degree
    SNiLD
    @SNiLD
    currently the chain must be in this order: SSAO/GBuffer -> SSAO/CreaseShading -> CustomCompositor that references SSAO/GBuffer mrt and has new pass clear {} and pass render_scene {}
    the ultimate goal is to get SSAO in texture that can be passed to filament and used there
    so i guess it's the output from SSAO/CreaseShading that would be used there
    SNiLD
    @SNiLD
    yeah, that alone produces only black screen (except for overlays, they can be enabled)
    SNiLD
    @SNiLD
    the way scene is rendered in the SSAO example is not translatable to the way SSAO is used in filament because in the sample SSAO is "post process effect" but in filament the SSAO must be passed as texture and the scene must be rendered normally
    so as i understand what should be done is first render the scene once with GBuffer scheme, then run the SSAO compositor to get SSAO, then clear the depth buffer (possible others as well?) and render the scene normally with the default scheme
    however it's still unclear to me how to do this in ogre
    SNiLD
    @SNiLD
    currently enabling the compositor in correct order and having custom compositor as last one that renders the scene again almost works (skyx is rendered, but hydrax is not)
    oh! but it was because i was clearing to depth_value 0.0
    i though i needed to do that when using reverse z-buffer
    sbuckner50
    @sbuckner50
    Hello y'all, I am working on a simulation development project using Ogre 1.9.0 for graphics. Many capabilities currently work, however I am running into issues trying to set up textures on geometries. Specifically, using Ogre::Image::load("image.png" , "valid_path...") is yielding an error for me: "SystemError: OGRE EXCEPTION(7:InternalErrorException): Error decoding image in FreeImageCodec::decode at .../OgreFreeImageCodec.cpp". Any help figuring out this problem and what could be causing it would be greatly appreciated!
    Also, I tried sending an email from the website however it seems "webmaster@REMOVESPAMogre3d.org" is not a valid address.
    If it helps, I am trying to use Ogre 1.9.0 on RHEL 6, which is not listed as a supported OS for Ogre (although Fedora is). I am not sure if this could be causing issues or not, because the issue I stated above is only one of many I am having.
    SNiLD
    @SNiLD
    you need freeimage codec and with that old version of ogre you probably need sufficiently old version of freeimage as well
    sbuckner50
    @sbuckner50
    Hmm, is FreeImage a separate FOSS?
    SNiLD
    @SNiLD
    it's a separate library
    but probably red hat has some separate package
    and most likely you need a specific version of the library that is compatible with ogre 1.9
    sbuckner50
    @sbuckner50
    So speaking more broadly, because I am running into a lot of issues with different functionalities of Ogre
    The libraries are not backwards-compatible?
    SNiLD
    @SNiLD
    well you can't assume backwards compatibility
    it's up to every library developer to make sure that backwards compatibility is maintained or not
    ogre is a library as well, and ogre 1.x series has made guarantee that when "major" version is upgraded the compatibility might break, so for example ogre 1.12 is not guaranteed to be backwards compatible with 1.11 although it mostly is
    sbuckner50
    @sbuckner50
    Hmm, I will look into this further, thank you
    sbuckner50
    @sbuckner50
    @SNiLD I am using FreeImage 3.15.4 with Ogre 1.9.0, would these be compatible? Also, what are some issues I might run into due to using an RHEL 6 build rather than a Fedora build? The RHEL 6 build had to be community-sourced so I assume it will naturally have problems, but I am trying to narrow down how I can identify and solve those problems.
    SNiLD
    @SNiLD
    hard to say
    also notice that freeimage itself has many dependencies, for example you're trying to open png and for that freeimage needs libpng
    it's hard to imagine that there would be so massive differences between linux distros that ogre wouldn't run correctly
    SNiLD
    @SNiLD
    is there a way to inherit high-level programs like materials can be inherited? currently only things that change between programs are mostly preprocessor defines but i find that i have to copy-paste most of the program definition and only change the preprocessor_defines
    Pavel Rojtberg
    @paroj
    SNiLD
    @SNiLD
    i can't figure out the syntax for inheritance of fragment_programs. it always results in nullptr as fragment program and thus it crashes
    fragment_program PBR_filament_base_fs_glsl glsl { }
    fragment_program PBR_filament_fs_glsl : PBR_filament_base_fs_glsl glsl { }
    i have tried all combinations of glsl at the end
    ah and just as i say it i found it:
    fragment_program PBR_filament_base_fs_glsl glsl { }
    fragment_program PBR_filament_fs_glsl glsl : PBR_filament_base_fs_glsl { }
    SNiLD
    @SNiLD
    i guess there's no way to reference script variable inside a script variable? i.e so that i could have variable that has most preprocessor_defines and i could just append to that
    Pavel Rojtberg
    @paroj
    no, but you could implement something like "append $all_defines MY_DEFINE"
    urza57
    @urza57
    Hi everyone ! I have a weird bug on Ogre (Windows 10 Pro x64 / Directx rendering) when I'm trying rendering text. Some fonts (MS PMincho, MS PGothic, Calibra, ...) have strange rendering on size < 15
    errors.PNG
    The font resolution is 96 (as specified in the documentation)
    urza57
    @urza57
    (Ogre version 1.12.4)
    bugproof
    @bugproof
    how hard will it be to integrate ogre in existing engine?
    I mean engine with custom renderer abstraction
    can I wrap ogre3d renderSystem easily in my own abstraction?
    This message was deleted