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
    except was there an issue setting shared_param_ref value as struct parameter?
    Pavel Rojtberg
    @paroj
    if your shaders do not contain an UBO, ogre will just copy the shared_params contents to the normal params and they will behave as such
    SNiLD
    @SNiLD
    ok nice then it's exactly what i needed
    Pavel Rojtberg
    @paroj
    besides there was an important bugfix, which should also fix UBO usage: OGRECave/ogre#1476
    SNiLD
    @SNiLD
    this was really good read regarding tangent space btw. https://medium.com/@bgolus/generating-perfect-normal-maps-for-unity-f929e673fc57
    steelfax
    @steelfax_gitlab
    Does anyone know a good Q1 or Q3 map loader for Ogre?
    Pavel Rojtberg
    @paroj
    SNiLD
    @SNiLD
    why don't some material trigger Ogre::MaterialManager::Listener::handleSchemeNotFound even though they don't have technique with that scheme?
    for example hydrax and skyx do this
    (i'm trying to implement SSAO according to the SSAO samples and generate the GBuffer via RTSS like done in the samples)
    Pavel Rojtberg
    @paroj
    the current scheme may be changed by the viewport or by the compositor, so probably one of these is done
    SNiLD
    @SNiLD
    well the same function is called for my own materials for example, don't know what's special about hydrax or skyx
    looking at the code it would mean that the shader is not compiled (ie. not in the supported techniques list)
    Pavel Rojtberg
    @paroj
    the RTSS ignores materials that have shaders attached by default
    so probably handleSchemeNotFound is called, but ignored by the RTSS
    SNiLD
    @SNiLD
    i put debug point in that function and it's not called for hydrax and skyx
    but it's called for my own materials, which use custom shaders as well
    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
    SNiLD
    @SNiLD
    but the deferred shading sample shows that to some degree
    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
    SNiLD
    @SNiLD
    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