Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Pavel Rojtberg
    @paroj
    works fine here
    SNiLD
    @SNiLD
    ok our version used setMaterialName() for entity instead of setMaterial() which was the problem for some reason
    nevermind that didn't solve the problem
    SNiLD
    @SNiLD
    yeah it was my mistake, the update() wasn't called
    Louis Vanhaelewyn
    @Swarthon
    Hi, I'm facing this error : malloc_consolidate(): invalid chunk size while running the Example 11 in https://github.com/OGRECave/ogre-pagedgeometry
    Have someone already faced it ? (I'm running GNU/Linux with Ogre 1.11.2 compiled from the github repository)
    Pavel Rojtberg
    @paroj
    do you have the Cg Plugin available? pagegeometry requires it w/o correctly checking
    Louis Vanhaelewyn
    @Swarthon
    Okay thank you. I didn't know. I will install it and try again
    Louis Vanhaelewyn
    @Swarthon
    I recompiled Ogre with Cg enabled and PagedGeometry does not work. The log file is here : https://framabin.org/p/?cd4025c453d18b28#NWvmAmZrY1nQrmOA68xkkjioO5b7jq+PaaVUv9IixS4=
    Pavel Rojtberg
    @paroj
    ah.. and you must use the legacy GL rendersystem as well (not Gl3+)
    Louis Vanhaelewyn
    @Swarthon
    thank you very much, now it runs but there is still one problem
    image.png
    as you can see the Terrain is flat
    I've tried to run the Samples using the OpenGL Render System and it seems that the Terrain is broken with the render system
    image.png
    Louis Vanhaelewyn
    @Swarthon
    as this integration of this Component leads to many changes for my project, I have one question : does it worth it to use the GLRenderSystem instead of the GL3+ RenderSystem ? (as PagedGeometry optimizes the creation of many objects but the GLRenderSystem is slower as the GL3+)
    Pavel Rojtberg
    @paroj
    as you can see the Terrain is flat
    is this an Intel GPU? I observed that once when running on intel. Will need to investigate more. Probably the terrain shaders are not properly generated. Do you have any shader related erros in the log?
    does it worth it to use the GLRenderSystem instead of the GL3+ RenderSystem
    depends on your use case. For many objects actually GL is faster OGRECave/ogre#662
    however GL3+ gives you compute & geometry shaders
    also our focus is on pushing GL3+, so we likely will compromise on FFP (GL) performance
    Louis Vanhaelewyn
    @Swarthon
    thank you very much, this community is very kind
    SNiLD
    @SNiLD
    how am i supposed to get WM_CLOSE etc. events handled with the WindowEventUtilities that was moved to the OgreBites? this commit has removed the _WndProc in windows: https://github.com/OGRECave/ogre/commit/aa90530a586d1c484abdf8be316838afe27c7bd1#diff-2f45f41ee2fce43e546363a9a697175f
    so now it doesn't matter that if i manually _addRenderWindow and addWindowEventListener since the renderwindow state will not change as there is no WndProc to handle the events and change the render window state
    is there a way to later add the WndProc now that OgreWin32Window has created WNDCLASS with NULL as the WndProc?
    xuke
    @825126369
    Xcode10.0, Mac 10.14 CMake Build XCode Project Fail by Default Config
    xuke
    @825126369
    I spend two weeks Time ,But not slove the problem
    Pavel Rojtberg
    @paroj
    I've tried to run the Samples using the OpenGL Render System and it seems that the Terrain is broken with the render system
    I could reproduce this using the GL rendersystem on Intel - however there are no warnings/ errors and the same shaders work on GL3+
    will need some time to investigate this
    Pavel Rojtberg
    @paroj
    how am i supposed to get WM_CLOSE etc. events handled with the WindowEventUtilities that was moved to the OgreBites?
    the main purpose was to decouple OgreMain from the WIN32 API and _WndProc was not portable, so things probably are broken now.
    you could maybe bring the functionality back by checking (*win)->getCustomAttribute("WINDOW",.. in the message loop similar to GLX
    alternatively create the window yourself and pass in "externalWindowHandle" like ApplicationContext does
    Xcode10.0, Mac 10.14 CMake Build XCode Project Fail by Default Config
    try downgrading to Xcode 9
    SNiLD
    @SNiLD
    so i could re-add the _WndProc to OgreBites::WindowEventUtilities now that it's in the bites component?
    Pavel Rojtberg
    @paroj
    it would be of no use as you could not reference it from OgreWin32Window
    SNiLD
    @SNiLD
    oh yeah damnit :(
    Pavel Rojtberg
    @paroj
    and with getCustomAttribute("WINDOW" you should be able to associate them with the right Ogre::Window
    SNiLD
    @SNiLD
    don't understand how, but i'll look into it tomorrow... right now RenderWindow->isClosed() etc is in desynch with the actual state of the window because it doens't get those events
    Pavel Rojtberg
    @paroj
    @Swarthon OGRECave/ogre#910
    Louis Vanhaelewyn
    @Swarthon
    Thank you
    xuke
    @825126369
    Thank you
    SNiLD
    @SNiLD
    the DefWindowProc assigned at OgreWin32Window.cpp will eat the WM_CLOSE event and it won't ever come to the messagePump loop... https://docs.microsoft.com/en-us/windows/desktop/winmsg/wm-close
    SNiLD
    @SNiLD
    maybe the WndProc pointer could be passed to Win32Window::create as miscParams
    Pavel Rojtberg
    @paroj
    sounds like a viable solution