[GSoC 2013 - accepted] Ogre 2.0

Threads related to Google Summer of Code
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3496
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 72
Contact:

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by dark_sylinc » Thu Oct 24, 2013 5:04 pm

scrawl wrote:I realize that with the improvements already made to shadow mapping in 2.0, most users will be happy with the default algorithms, but don't see any reason to take away freedom here.
And I don't think that "just modify upstream code" is an adequate answer here. It's awful having to maintain a private copy of something as big as Ogre.
Having to modify upstream code usually indicates a design flaw.
I kept thinking about this, and I was just discussing it with Murat. Something very important to stand out is that OGRE 2.X IS NOT SET IN STONE.

It's a work in progress that's already very stable and we'd like people to try it out. We also want to release an (alpha?) package as soon as possible so that people can compile and try it (I don't want to give a time frame estimate to avoid building expectations, but we do have an internal dead line we'd like to meet).

We're prioritizing. If demand for customizable shadow camera setups grows, or an user offers (or even myself) to do it, this could be improved perhaps in Ogre 2.1, 2.2; or in Ogre 2.0 r2.
We have a lot of work and shadows are working very well now, so I'm focusing my efforts on other areas that need more attention to get a more robust Ogre 2.0 ready for production.
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3496
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 72
Contact:

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by dark_sylinc » Thu Oct 24, 2013 8:01 pm

I've just updated the wiki to show what is broken and what needs to be fixed.

Some people seem to be that Ogre 2.0 is "unstable" because a lot of samples aren't even compiling.
Actually, most samples require quick fixes or just rely on deprecated stuff (i.e. SkeletalAnimation sample used stencil shadows, we should disable it) or rely on something that needs to be ported (i.e. many samples use NodeAnimationTrack)
There's just only a few samples that actually require more work.

And then there's the BSP & Octree scene manager which are just deprecated and scheduled for removal. Some people may be under the false impression they will be fixed.
0 x

User avatar
scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
Location: Germany
x 1

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by scrawl » Thu Oct 24, 2013 8:19 pm

We're prioritizing. If demand for customizable shadow camera setups grows, or an user offers (or even myself) to do it, this could be improved perhaps in Ogre 2.1, 2.2; or in Ogre 2.0 r2.
We have a lot of work and shadows are working very well now, so I'm focusing my efforts on other areas that need more attention to get a more robust Ogre 2.0 ready for production.
Makes sense. I was just going to write that it's not a priority and can be fixed later, but you beat me to it :)

Have you done any performance testing on linux yet? I noticed that Ogre 2.0 seems to be really slow here. Instancing is broken, but with "No Instancing" and 50x50 instances I get 26 fps, where I had 100 fps in 1.9.
The baseline seems to be different too. "Bezier patch" (which is just 1 entity) had 1300 fps in 1.9, and 300 fps in 2.0.
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3496
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 72
Contact:

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by dark_sylinc » Thu Oct 24, 2013 9:41 pm

scrawl wrote: Have you done any performance testing on linux yet? I noticed that Ogre 2.0 seems to be really slow here. Instancing is broken, but with "No Instancing" and 50x50 instances I get 26 fps, where I had 100 fps in 1.9.
Tick the animation check box for comparisons.
The problem is that due to architectural changes we're being forced to update all animations, even if they haven't changed; and this is very slow (the reason I started OgreAnimation).
If you animate those entities, 1.9 goes down to ~26fps too.

By the way, instancing was broken because a recent commit broke it. A couple of hours ago I spotted the bug and David and I found the culprit. Pull changes again and recompile.
scrawl wrote:The baseline seems to be different too. "Bezier patch" (which is just 1 entity) had 1300 fps in 1.9, and 300 fps in 2.0.
That may need investigation.
What about CelShading or SphereMapping? They're as simple as they can get.
0 x

User avatar
scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
Location: Germany
x 1

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by scrawl » Thu Oct 24, 2013 10:11 pm

Here's another change you forgot with regards to the media that was removed (Sample browser won't start otherwise)

Code: Select all

diff -r 17aabc1b9456 CMake/Templates/resources.cfg.in
--- a/CMake/Templates/resources.cfg.in	Thu Oct 24 15:41:56 2013 -0500
+++ b/CMake/Templates/resources.cfg.in	Thu Oct 24 23:04:40 2013 +0200
@@ -25,7 +25,6 @@
 Zip=@OGRE_MEDIA_DIR_REL@/packs/cubemapsJS.zip
 Zip=@OGRE_MEDIA_DIR_REL@/packs/dragon.zip
 Zip=@OGRE_MEDIA_DIR_REL@/packs/fresneldemo.zip
-Zip=@OGRE_MEDIA_DIR_REL@/packs/ogretestmap.zip
 Zip=@OGRE_MEDIA_DIR_REL@/packs/ogredance.zip
 Zip=@OGRE_MEDIA_DIR_REL@/packs/Sinbad.zip
 Zip=@OGRE_MEDIA_DIR_REL@/packs/skybox.zip
diff -r 17aabc1b9456 CMake/Templates/resources_d.cfg.in
--- a/CMake/Templates/resources_d.cfg.in	Thu Oct 24 15:41:56 2013 -0500
+++ b/CMake/Templates/resources_d.cfg.in	Thu Oct 24 23:04:40 2013 +0200
@@ -25,7 +25,6 @@
 Zip=@OGRE_MEDIA_DIR_DBG@/packs/cubemapsJS.zip
 Zip=@OGRE_MEDIA_DIR_DBG@/packs/dragon.zip
 Zip=@OGRE_MEDIA_DIR_DBG@/packs/fresneldemo.zip
-Zip=@OGRE_MEDIA_DIR_DBG@/packs/ogretestmap.zip
 Zip=@OGRE_MEDIA_DIR_DBG@/packs/ogredance.zip
 Zip=@OGRE_MEDIA_DIR_DBG@/packs/Sinbad.zip
 Zip=@OGRE_MEDIA_DIR_DBG@/packs/skybox.zip
I really need to fork your repo so I can start doing pull requests.. I'll do it the next time something like this happens :D
Tick the animation check box for comparisons.
The animation checkbox was off in both cases.

Just pulled the changes, instancing is better now.
Performance still sucks :(

2.0
Image

1.9
Image

What about CelShading or SphereMapping? They're as simple as they can get.
Same result for those, ~1300 vs ~300
0 x

User avatar
scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
Location: Germany
x 1

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by scrawl » Thu Oct 24, 2013 10:18 pm

Tick the animation check box for comparisons.
The problem is that due to architectural changes we're being forced to update all animations, even if they haven't changed; and this is very slow (the reason I started OgreAnimation).
I see what you mean now. With the animation checkbox enabled, I now get 47 fps in 1.9, 15 in 2.0.

I'll try to make a sample where I'm just using non-skinned entities, just to make sure it's still slower then.
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3496
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 72
Contact:

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by dark_sylinc » Fri Oct 25, 2013 2:06 am

I'm getting very bad performance too and the resources.cfg bug appeared out of nowhere (note that Murat & David have been doing a few changes) affecting Windows too. Will investigate over the weekend.
0 x

cord
Halfling
Posts: 59
Joined: Tue Oct 22, 2013 10:22 am

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by cord » Fri Oct 25, 2013 4:34 am

I am attempting to build on Linux as well, and might get lucky and find something to fix! :)

@dark_sylinc: you saw that I forked your ogre2-gsoc, I tried merging with your repo today and bitbucket failed badly! I had to delete my fork and start from yours again.
0 x

Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by Transporter » Fri Oct 25, 2013 8:24 am

I would like to use Ogre 2.0 + Instancing because I have huge performence problems with 1.9 (see http://www.ogre3d.org/forums/viewtopic.php?f=2&t=79170) but I need a bugfixed version on monday. I made my onw tests like scrawl and get more Frames with 1.9, too.
0 x

cord
Halfling
Posts: 59
Joined: Tue Oct 22, 2013 10:22 am

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by cord » Fri Oct 25, 2013 9:12 am

Transporter wrote:I would like to use Ogre 2.0 + Instancing because I have huge performence problems with 1.9 (see http://www.ogre3d.org/forums/viewtopic.php?f=2&t=79170) but I need a bugfixed version on monday. I made my onw tests like scrawl and get more Frames with 1.9, too.
I think the bugs are fixed as of right now.

But I think you should not expect Ogre 2.0 + Instancing to work for you on Monday. It has not even reached an Alpha release yet! A use case of one process for 6 fullscreen viewports is very cool but not as likely to achieve high frame rates.
0 x

Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by Transporter » Fri Oct 25, 2013 11:17 am

First, dark_sylinc you've done some awesome work! :D :D :D
cord wrote:
Transporter wrote:I would like to use Ogre 2.0 + Instancing because I have huge performence problems with 1.9 (see http://www.ogre3d.org/forums/viewtopic.php?f=2&t=79170) but I need a bugfixed version on monday. I made my onw tests like scrawl and get more Frames with 1.9, too.
I think the bugs are fixed as of right now.

But I think you should not expect Ogre 2.0 + Instancing to work for you on Monday. It has not even reached an Alpha release yet! A use case of one process for 6 fullscreen viewports is very cool but not as likely to achieve high frame rates.
Second, I did a few tests - without instancing - and receive between 50 and 100 fps in our city for all 6 outputs :D It would be nice to have instancing because we have to insert vehicles and pedestrians in the scene which would decrease the frame rate aggain.
Last edited by Transporter on Fri Oct 25, 2013 11:25 am, edited 1 time in total.
0 x

al2950
OGRE Expert User
OGRE Expert User
Posts: 1073
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 33

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by al2950 » Fri Oct 25, 2013 11:22 am

Transporter wrote:First, dark_sylinc you've done some awsome work! :D :D :D
Second, I did a few tests - without instancing - and receive between 50 and 100 fps in our city for all 6 outputs :D It would be nice to have instancing because we have to insert vehicles and pedestrians in the scene which would decrease the frame rate aggain.
Out of interest what FPS were you getting with 1.9?
0 x

Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by Transporter » Fri Oct 25, 2013 11:25 am

al2950 wrote:Out of interest what FPS were you getting with 1.9?
Between 4 and 20 fps. Because of the single-threaded design.
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3496
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 72
Contact:

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by dark_sylinc » Fri Oct 25, 2013 2:41 pm

Apparently the slowdown bug is in the SampleBrowser when RTSS shader sys. is compiled. It wouldn't be directly an OgreCore bug.
Remove this line from SampleBrowser.h (lines 361~370):

Code: Select all

#ifdef INCLUDE_RTSHADER_SYSTEM
                    /* vv Start remove */
                    if(mRoot->getRenderSystem()->getCapabilities()->hasCapability(Ogre::RSC_FIXED_FUNCTION))
                    {
                        createDummyScene();
                    }
                    /* ^^ end remove */

					s->setShaderGenerator(mShaderGenerator); //Don't remove this
#endif
It is creating an additional Workspace, causing to draw twice to the same RenderWindow; hence 2x slowdown.
Last edited by dark_sylinc on Fri Oct 25, 2013 2:50 pm, edited 1 time in total.
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3496
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 72
Contact:

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by dark_sylinc » Fri Oct 25, 2013 2:50 pm

Transporter wrote:Second, I did a few tests - without instancing - and receive between 50 and 100 fps in our city for all 6 outputs :D It would be nice to have instancing because we have to insert vehicles and pedestrians in the scene which would decrease the frame rate aggain.
Instancing is working again since yesterday ;) (except for SW VTF, which nobody uses anyway; HW VTF works)
There was a bug that caused FrustumCulling to accept all entities (even those who should be culled) and instances to have a NaN bounding box. But this has been fixed in latest commit.

And, niiiiice framerate! Now we all need you to do is to put you on stage and say "before, I had 4 fps; but when I tried Ogre 2.0; I had 100fps my brothers! Embrace the update and feel the speed up"
Or something like that :)

If the city buildings are static (won't move or rotate for a long time), use SCENE_STATIC for an even greater performance improvement.

Edit: About the pedestrians+vehicles: I assume they're instanced and skeletally animated. If many of them don't have their animations update every frame, it's quite likely 1.9 will get greater performance than 2.0; If you were updating almost all (or all) of their animations every frame; then 2.0 should be slightly above 1.9 (it depends on the amount of animated objects you have on the scene; which can quickly become the main bottleneck)
The only solution is to wait for OgreAnimation; which I highly doubt will be ready for Monday. Unless you're willing to hire me to finish it sooner (I already have a contract for the next week so I'm not available for next week), you'll have to wait.
0 x

Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by Transporter » Fri Oct 25, 2013 4:18 pm

dark_sylinc wrote:Instancing is working again since yesterday ;) (except for SW VTF, which nobody uses anyway; HW VTF works)
There was a bug that caused FrustumCulling to accept all entities (even those who should be culled) and instances to have a NaN bounding box. But this has been fixed in latest commit.
I'm glad to hear that, I'll check it tomorrow. Btw, your repository needs to be merged, because there are two tips for branch v2-0.
dark_sylinc wrote:And, niiiiice framerate! Now we all need you to do is to put you on stage and say "before, I had 4 fps; but when I tried Ogre 2.0; I had 100fps my brothers! Embrace the update and feel the speed up"
Or something like that :)
I did something like that in my office ;) And I will write a showcase post if the project is finished.
dark_sylinc wrote:If the city buildings are static (won't move or rotate for a long time), use SCENE_STATIC for an even greater performance improvement.
I already set them to be static.
dark_sylinc wrote:The only solution is to wait for OgreAnimation; which I highly doubt will be ready for Monday. Unless you're willing to hire me to finish it sooner (I already have a contract for the next week so I'm not available for next week), you'll have to wait.
Congratulation to your contract! The vehicles are dynamic object without any animations at the moment, because our 3d artist has to fix the main scene first. The pedestrians have skeletal animations but if it's nessecary we can switch it off and just put them on the scene without walking. Of course I'll try your OgreAnimation library if it's available. Also I'll start building and distributing your Ogre code in my thread.

Thanks for your help and work! Now I can sleep better without getting a headache because of the 4 FPS. :D :D :D
0 x

User avatar
scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
Location: Germany
x 1

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by scrawl » Sat Oct 26, 2013 5:51 am

Your fix didn't help with perf problems here, because I already had RTShader disabled in cmake the entire time.
I then tried enabling RTShader, just to see what happens. NewInstancing and a few other samples segfault now.

There also seems to be something wrong with the repo. There are multiple heads on 2.0 and I had to checkout the correct revision explicitely.

Did you notice there's a pull request?
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3496
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 72
Contact:

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by dark_sylinc » Sat Oct 26, 2013 2:34 pm

scrawl wrote:Your fix didn't help with perf problems here, because I already had RTShader disabled in cmake the entire time.
I then tried enabling RTShader, just to see what happens. NewInstancing and a few other samples segfault now.
New changes came in, and I'm in the process of a pull request to the main repo.
The segfault should be fixed now.
However I'm sad about the perf problems. I should investigate more. I'm excited to finish OgreAnimation first, but I'll look into that when there's a window to do it.
scrawl wrote: There also seems to be something wrong with the repo. There are multiple heads on 2.0 and I had to checkout the correct revision explicitely.
Fixed, fixed, fixed! I wish I had more time. Or multiply myself. Or just be a billionaire so I can just dedicate to what I love.
0 x

Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by Transporter » Sat Oct 26, 2013 7:45 pm

I've pushed another bugfix. Should I update the Missing broken stuff section of the wiki page or do you want to do this by yourself? The components paging, terrain and volume are also broken. The samples of the remaining components CameraTrack, Character, CubeMapping, DeferredShading, DynTex, Fresnel, ParticleGS, ShaderSystem, ShaderSystemMultiLight, ShaderSystemTexturedFog, Shadows, SkeletalAnimation, SSAO, VolumeTex and Water are broken, too.
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3496
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 72
Contact:

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by dark_sylinc » Sat Oct 26, 2013 9:44 pm

Transporter wrote:Should I update the Missing broken stuff section of the wiki page or do you want to do this by yourself? The components paging, terrain and volume are also broken. The samples of the remaining components CameraTrack, Character, CubeMapping, DeferredShading, DynTex, Fresnel, ParticleGS, ShaderSystem, ShaderSystemMultiLight, ShaderSystemTexturedFog, Shadows, SkeletalAnimation, SSAO, VolumeTex and Water are broken, too.
Yeah, but don't update the stuff regarding samples, generates a lot of unnecessary noise.
0 x

Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by Transporter » Thu Oct 31, 2013 9:46 am

I could not create multiple windows:

Code: Select all

OGRE EXCEPTION(3:RenderingAPIException): Failed to DrawPrimitive : Invalid call in D3D9RenderSystem::_render at ..\..\..\RenderSystems\Direct3D9\src\OgreD3D9RenderSystem.cpp (line 3522)
Attachments
MultiScreen.zip
(6.46 KiB) Downloaded 111 times
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3496
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 72
Contact:

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by dark_sylinc » Thu Oct 31, 2013 9:24 pm

Fixed. Thanks for the bug report. Your sample was useful in determining the cause of it.
Actually they were 2 bugs in one.
0 x

Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by Transporter » Thu Oct 31, 2013 9:45 pm

dark_sylinc wrote:Fixed. Thanks for the bug report. Your sample was useful in determining the cause of it.
Actually they were 2 bugs in one.
Thanks for the fix! :D I don't know if there is a better way to create and control multiple windows with multiple cams, this is just a quick & dirty solution.
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3496
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 72
Contact:

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by dark_sylinc » Thu Oct 31, 2013 10:41 pm

Transporter wrote:Thanks for the fix! :D I don't know if there is a better way to create and control multiple windows with multiple cams, this is just a quick & dirty solution.
The way you treat the Compositor Workspaces to manage multiple RenderWindows is exactly how it was intended.
Except for one thing: you're creating one CompositorWorkspaceDef per RenderWindow (the calls to createBasicWorkspaceDef). You can share all your workspace instances with the same CompositorWorkspaceDef (unless you want to apply different compositor effects for each window; i.e. enable Bloom in one window and disable it for the other one; or render render queues 0 to 10 in one window, and 5 to 8 in the other window)

You can share the cameras if you like to. If you want multiple cams though, you're doing it the way it was intended ;)

Edit: PS
Transporter wrote:this is just a quick & dirty solution.
If you think this is "quick"; I've done my job. Also, if you think it's "dirty"; well umm... let's forget you said that!
0 x

User avatar
scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
Location: Germany
x 1

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by scrawl » Thu Oct 31, 2013 11:39 pm

2f2422e sample browser crashing on start :(

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff79fb0ec in lock (options=Ogre::HardwareBuffer::HBL_DISCARD, this=0x7ffff01eae38) at /home/scrawl/Dev/ogre/OgreMain/include/OgreHardwareBuffer.h:222
222	                return this->lock(0, mSizeInBytes, options);
(gdb) bt
#0  0x00007ffff79fb0ec in lock (options=Ogre::HardwareBuffer::HBL_DISCARD, this=0x7ffff01eae38) at /home/scrawl/Dev/ogre/OgreMain/include/OgreHardwareBuffer.h:222
#1  Ogre::Rectangle2D::initRectangle2D (this=this@entry=0x7ffff7edb648) at /home/scrawl/Dev/ogre/OgreMain/src/OgreRectangle2D.cpp:155
#2  0x00007ffff79fb4e3 in Ogre::Rectangle2D::Rectangle2D (this=0x7ffff7edb648, bQuad=<optimized out>) at /home/scrawl/Dev/ogre/OgreMain/src/OgreRectangle2D.cpp:42
#3  0x00007ffff7a6ecdd in Ogre::CompositorManager2::CompositorManager2 (this=0x7ffff7edb438, renderSystem=<optimized out>)
    at /home/scrawl/Dev/ogre/OgreMain/src/Compositor/OgreCompositorManager2.cpp:78
#4  0x00007ffff7877e2f in Ogre::Root::initialiseCompositor (this=0x7ffff7ec45f8) at /home/scrawl/Dev/ogre/OgreMain/src/OgreRoot.cpp:728
#5  0x000000000041a0b9 in OgreBites::SampleBrowser::setup (this=0x7fffffffe3a0) at /home/scrawl/Dev/ogre/Samples/Browser/include/SampleBrowser.h:1077
#6  0x000000000040a7c7 in OgreBites::SampleContext::initApp (this=0x7fffffffe3a0, initialSample=0x0) at /home/scrawl/Dev/ogre/Samples/Common/include/SampleContext.h:251
#7  0x000000000040a618 in OgreBites::SampleContext::go (this=this@entry=0x7fffffffe3a0, initialSample=initialSample@entry=0x0) at /home/scrawl/Dev/ogre/Samples/Common/include/SampleContext.h:308
#8  0x0000000000408eac in main (argc=<optimized out>, argv=0x7fffffffe688) at /home/scrawl/Dev/ogre/Samples/Browser/src/SampleBrowser.cpp:116
I also had to apply some changes to get it to build (again), made a pull request.
0 x

Post Reply