[GLES3] Progress update: Some good news!

Design / architecture / roadmap discussions related to future of Ogre3D (version 2.0 and above)

[GLES3] Progress update: Some good news!

Postby Hotshot5000 » Tue Dec 13, 2016 12:14 pm

The GLES3 backend is finally working for some basic rendering. There are optimizations to be done, gamma correction to be added, code to be cleaned up and the outstanding bugs to be fixed, merges with the 2.1 branch to be done etc. but I just wanted to let you know that the first milestone has been hit. Hopefully before Christmas (or as a Christmas present :) ) I will add GLES3 build in Cmake so that everybody can test the thing on their machines and send me the bugs to fix :). After it becomes more or less stable I will go on to making Ogre work on Android.

For those curious, The GLES3 branch is following the GL3Plus branch pretty closely, and when I'll add support for 3.1 and 3.2 it will be more or less the same as the GL3Plus branch. The performance will never be as good since there is no persistent mapping, no multiple meshes in the same vertex buffer and no indirect draw calls. Another difference is the use of the state cache object so that you don't usually call a gl* set state function directly but through the state cache, in order to minimize gl* calls. I also had to use a 2D texture instead of a texture buffer, I don't know how much will this impact performance. These problems will diminish and might get eliminated when I'll get to ES 3.2 since that allows for a lot of stuff that I had to find ways around for now.

I also want to talk about nVidia NSight tool that integrates with Visual Studio. I've been using RenderDoc for debugging a frame and I've noticed that some buffers were all filled with 0xDDDDDDDD which means that the memory has been freed. Also some buffers weren't bound according to RenderDoc. That sent me into a month long quest to find the reason why there wasn't anything rendering on the screen thinking that it was a buffer issue. And while there was a bug there, that wasn't the reason things weren't working. RenderDoc still said things weren't OK with the buffers.

So, basically angered that I was getting nowhere, I installed NSight given that I have an nVidia card, hoping I will get more information. And oh boy the thing helped. The problem was in completely another part...

Its nice thing is that it has an event window where it tells you if there are any issues with the GL commands issued, for example if a texture isn't complete, or if an GL call is redundant. Also it has an API inspector that is basically the pipeline state from RenderDoc but shows you all the settings for a textures, buffers etc. so you can see at a glance if something is amiss. And you can edit shaders live. Integration with Visual Studio is also good. The rest is pretty much on par with RenderDoc so they can be used interchangeably.

What I learned from this experience is that these debugging tools for the GPU aren't that solid. For example, even though NSight helped, it still takes 4-5 tries before I get it to debug a frame. Most of the time the application freezes and NSight dies. The reason for this it seems is the Windows 10 Hybrid Graphics (basically Optimus tech) that doesn't seem to work right with NSight. The situation is acknowledged by the green team and they say it's on their TODO list.

The situation is pretty awful from what I see in the GPU debugging land, especially for the mobile GLES stuff. My solution right now if you try to debug OpenGL ES 3 is to use everything you have: GPUPerf, RenderDoc and NSight. They all have things that other miss and in the case of OpenGL ES they show sometimes different things and using just one tool might lead you on the wrong path. ANGLE from Google has also helped immensely since it's open source and you can go see how ES is translated to plain desktop GL calls. I recommend ANGLE as the usual lib to link against but also keep at hand PowerVR SDK and Mali tools. Again, it might work on one and crash on another.

For this message the author Hotshot5000 has received 6 kudos
Hotshot5000
Greenskin
 
Posts: 111
Kudos: 23
Joined: 14 Oct 2010

Re: [GLES3] Progress update: Some good news!

Postby dark_sylinc » Tue Dec 13, 2016 4:41 pm

Woot!!! Congratulations!

That's excellent news. Keep up the good work :D

Hotshot5000 wrote:Another difference is the use of the state cache object so that you don't usually call a gl* set state function directly but through the state cache, in order to minimize gl* calls. I also had to use a 2D texture instead of a texture buffer, I don't know how much will this impact performance. These problems will diminish and might get eliminated when I'll get to ES 3.2 since that allows for a lot of stuff that I had to find ways around for now.

You can get rid of the state cache since it made sense in Ogre 1.x which had a lot of redundant calls. Ogre 2.1 is designed to minimize these redundant calls at a higher level, so it doesn't make sense here and may actually make performance slower.

As for performance comparison: Comparing against desktop GL/D3D is futile because as you said there's a whole world of difference in features that hold perf back. However comparing performance against GLES from Ogre 1.x is valid (and maybe against other engines? heh! I'm being ambitious :) ).

What I learned from this experience is that these debugging tools for the GPU aren't that solid.

Yup.

About RenderDoc, if you find bugs and have small repros you can submit them to baldur. He's really responsive about them.
Two years ago RenderDoc wasn't even working with Ogre (crashes everywhere), until I started sending him small exes that did as little as possible showcasing the problems, working closely together.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 3080
Kudos: 469
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: [GLES3] Progress update: Some good news!

Postby N0vember » Thu Dec 29, 2016 4:29 am

This is very good news !
What would be the theoretical amount of work to be done between a working GLES3 renderer and a working web/emscripten build of Ogre 2.1 ?
Ogre 2.1 on the web would really kick ass
N0vember
Gremlin
 
Posts: 190
Kudos: 23
Joined: 27 Jan 2009

Re: [GLES3] Progress update: Some good news!

Postby dark_sylinc » Thu Dec 29, 2016 2:53 pm

N0vember wrote:This is very good news !
What would be the theoretical amount of work to be done between a working GLES3 renderer and a working web/emscripten build of Ogre 2.1 ?
Ogre 2.1 on the web would really kick ass

WebGL is much more like GLES2. So while this is still a significant step forward, there would be still left work to do (i.e. wouldn't work straight away). Biggest problem is GLES2 does not support const buffers.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 3080
Kudos: 469
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: [GLES3] Progress update: Some good news!

Postby rujialiu » Mon Jan 02, 2017 10:06 am

dark_sylinc wrote:WebGL is much more like GLES2. So while this is still a significant step forward, there would be still left work to do (i.e. wouldn't work straight away). Biggest problem is GLES2 does not support const buffers.

What is the status of WebGL 2.0? It has been released as a draft in late 2013, but it seems that it's not officially supported by any mainstream browsers...
rujialiu
Halfling
 
Posts: 76
Kudos: 1
Joined: 09 May 2016

Re: [GLES3] Progress update: Some good news!

Postby dark_sylinc » Mon Jan 02, 2017 4:44 pm

WebGL 2.0 is more like GLES3, thus it would be much easier for us to support. Like you said, no browser officially supports it. The Khronos Wiki shows how to enable the experimental support.

TBH the web is overly optimistic about WebGL 2.0 coming to browsers. There are several issues that are difficult for browsers to overcome:
  • Access to UBO means javascript will be directly manipulating memory. This is a security nightmare. Memory manipulation can be encapsulated (i.e. an array with out of bounds checking), but of course this decreases performance. Also browsers need to deal with mapping driver buffers.
  • There's still the issue of what happens when malicious code calls glBindBufferRange with the wrong settings. The browser has to go to great lengths to ensure the shader-drawcall combination fails to execute if the wrong range is sent.
  • The shader can do myUbo[i]. What happens when i is out of bounds? Securing this is several orders of magnitude harder because it involves a shader compiler, and securing GPU code, not CPU.
  • Likewise, dynamic control flow allows a shader to easily get stuck in an infinite (or near infinite) loop. Either the browser inspects the shader for every branch and loop and insert an upper bound (and has to do this perfectly, without missing any case or breaking glsl syntax); or it relies on the OS and driver to correctly handle this situation. Windows handles this well, although it may mean the browser loses all graphics contexts in all of its tabs, but is recoverable. On Linux and macOS, an infinite loop sparks a colossal disaster: we're talking about full system-level crash or complete loss of control of the display.
  • Combine all of the above (maliciously accessing out of bounds UBOs, maliciously calling glBindBufferRange, maliciously accessing out of bounds in shader, using infinite loops in complex syntax scenarios) and best case scenario a system crash is guaranteed. Worst case the attacker steals information from the screen (i.e. gaining full access to GPU's RAM is easy) or gains ring 0 privileges.

TL;DR WebGL 2.0 is a security nightmare and browsers are in a very difficult position to fix; unless they use their own software rasterizer. I'd imagine WebGL 2.0 may be supported soon but stay disabled by default for a very, very, very long time.
It would've been much easier if WebGL 2.0 had used SPIR-V instead of GLSL, thus browsers would have a much easier time inserting security checks to buffer accesses and upper bounds to dynamic control flow.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 3080
Kudos: 469
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: [GLES3] Progress update: Some good news!

Postby rujialiu » Tue Jan 03, 2017 4:40 am

dark_sylinc wrote:TL;DR WebGL 2.0 is a security nightmare and browsers are in a very difficult position to fix; unless they use their own software rasterizer. I'd imagine WebGL 2.0 may be supported soon but stay disabled by default for a very, very, very long time.
It would've been much easier if WebGL 2.0 had used SPIR-V instead of GLSL, thus browsers would have a much easier time inserting security checks to buffer accesses and upper bounds to dynamic control flow.


Ah... that makes sense. Thanks!
rujialiu
Halfling
 
Posts: 76
Kudos: 1
Joined: 09 May 2016

Re: [GLES3] Progress update: Some good news!

Postby N0vember » Wed Feb 01, 2017 12:31 am

dark_sylinc wrote:TL;DR WebGL 2.0 is a security nightmare and browsers are in a very difficult position to fix; unless they use their own software rasterizer. I'd imagine WebGL 2.0 may be supported soon but stay disabled by default for a very, very, very long time.
It would've been much easier if WebGL 2.0 had used SPIR-V instead of GLSL, thus browsers would have a much easier time inserting security checks to buffer accesses and upper bounds to dynamic control flow.


Okay, I understand WebGL 2.0 is not ready to be delivered to customers yet, but it is shipped in browsers, and it is ready to start developping for it.
So the question is, once the GLES3 renderer is working, what next steps would be needed to get Ogre to compile and render on the web ?
Since Ogre 2.1 is a very great engine that cannot render on the web, and this is a very big drawback for some, and an incentive to use other engines. (And don't get me started about branching the code to use two different versions of Ogre. A nightmare)
N0vember
Gremlin
 
Posts: 190
Kudos: 23
Joined: 27 Jan 2009

Re: [GLES3] Progress update: Some good news!

Postby dark_sylinc » Wed Feb 01, 2017 6:02 am

N0vember wrote:
dark_sylinc wrote:TL;DR WebGL 2.0 is a security nightmare and browsers are in a very difficult position to fix; unless they use their own software rasterizer. I'd imagine WebGL 2.0 may be supported soon but stay disabled by default for a very, very, very long time.
It would've been much easier if WebGL 2.0 had used SPIR-V instead of GLSL, thus browsers would have a much easier time inserting security checks to buffer accesses and upper bounds to dynamic control flow.


Okay, I understand WebGL 2.0 is not ready to be delivered to customers yet, but it is shipped in browsers, and it is ready to start developping for it.
So the question is, once the GLES3 renderer is working, what next steps would be needed to get Ogre to compile and render on the web ?
Since Ogre 2.1 is a very great engine that cannot render on the web, and this is a very big drawback for some, and an incentive to use other engines. (And don't get me started about branching the code to use two different versions of Ogre. A nightmare)

That statement was written days before WebGL 2.0 got released (aka enabled by default). It feels like the Mozilla & Chrome developers were challenged to release it by that statement :lol: :lol:

Rest assured we won't actively deny GLES3/WebGL2 support. In fact we'd like to support it very much. I was just stating that I doubt WebGL2 is going to be supported by browser soon.... which it's now supported, but I still wonder how long until a critical vulnerability forces vendors to disable it by default again.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 3080
Kudos: 469
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: [GLES3] Progress update: Some good news!

Postby Hotshot5000 » Wed Feb 01, 2017 3:22 pm

Right now I am focused on switching renderers for my game and this will take some time (as in months). But after that I will come back to Ogre. I was thinking on writing the WebGL2 backend if it's not done by then, but the more I think about it the less I am inclined to do so. GLES3 is already pretty bad and doesn't allow Ogre 2.1 to shine because it doesn't fully allow AZDO techniques to be used. That means the performance is impaired. I expect WebGL to be even more restrictive so even less of the things that make 2.1 fast will work. So, why use 2.1 if you're not actually benefiting from the improvements brought by 2.1? Might as well use 2.0 that already has improvements from 2.1 (from what I understand) but doesn't use AZDO. I don't know yet, maybe the market response will basically force me to port my game to the browser in which case I'll implement WebGL2 even if I'm not into it. Of course, if somebody wants to implement WebGL2 you can use my GLES3 Ogre fork for guidelines.

My game has lots and lots of objects on the screen (basically lots of space ships battling each other) and I want to implement a more complex AI than it's usually seen on mobile devices, so I would benefit from having the renderer use as little CPU as possible. GLES3 is the limiting factor here, but Vulkan isn't and it looks like it's the way forward in the next years. The GL3Plus renderer right now is plenty of fast so implementing Vulkan for desktop probably won't yield that much of a performance improvement, but I think for Android it would be a net win compared to GLES3. It will take a few years before Vulkan will be supported by practically all devices, so GLES3 it is for now. But if nobody will have started work on this by the time I make my comeback I am willing to do it myself.

So the question for me is what to do first: WebGL2 or Vulkan? Vulkan is clearly the more interesting project and I've been reading books and articles about it lately in order to prepare myself, but with WebGL I might reach the target audience faster as it's already here, while Vulkan will take years before we will see serious adoption. Also, Vulkan tools and drivers seem immature at this point, more so on mobile, so it will probably be a complete PITA developing for it.

And last and least important, Vulkan support is good from a marketing perspective: it's what the 'cool kids' use these days and every engine from big companies has support for it these days. I've read the following things a lot on forums where the people writing there aren't programmers or aren't experienced programmers: 'Vulkan will replace OpenGL', 'OpenGL is dead', 'Vulkan is much faster OpenGL is slow and sucks' etc. So they might consider Ogre inferior because it doesn't say Vulkan and DirectX 12 on the front page.
Hotshot5000
Greenskin
 
Posts: 111
Kudos: 23
Joined: 14 Oct 2010

Re: [GLES3] Progress update: Some good news!

Postby dark_sylinc » Wed Feb 01, 2017 3:51 pm

Hotshot5000 wrote:Right now I am focused on switching renderers for my game and this will take some time (as in months). But after that I will come back to Ogre. I was thinking on writing the WebGL2 backend if it's not done by then, but the more I think about it the less I am inclined to do so. GLES3 is already pretty bad and doesn't allow Ogre 2.1 to shine because it doesn't fully allow AZDO techniques to be used. That means the performance is impaired. I expect WebGL to be even more restrictive so even less of the things that make 2.1 fast will work. So, why use 2.1 if you're not actually benefiting from the improvements brought by 2.1? Might as well use 2.0 that already has improvements from 2.1 (from what I understand) but doesn't use AZDO. I don't know yet, maybe the market response will basically force me to port my game to the browser in which case I'll implement WebGL2 even if I'm not into it. Of course, if somebody wants to implement WebGL2 you can use my GLES3 Ogre fork for guidelines.

It's true that 2.1 can't shine without baseVertex/baseInstance family of draw calls (however they may get added as extensions for desktop since Desktop totally supports them).
But please note that even without AZDO:
  • 2.1's frustum culling is much more optimized: significantly less memory overhead, cache friendly, and SIMD friendly (also threading friendly but AFAIK Emscripten/Javascript doesn't have threads). I learnt Emscripten can now convert SSE intrinsics to SIMD.js
  • 2.1's rendering stack is much more lightweight. Go to Ogre 2.0 or 1.x's drawcalls, place a breakpoint and see the (deep) callstack and the surrounding code. There's a huge load of garbage between each draw that significantly reduces performance. GL3PlusRenderSystem::_render in 1.10 is 350 lines of code with lots of branches, loops and fat function calls. In comparison 2.1's _renderEmulated is 22 lines of code, with no branches and only a loop to render multiple draws. In Ogre 2.1 you have a much thinner callstack, and a lot more DrawPrimitive calls called in succession with little overhead between them.

So even without AZDO, Ogre 2.1 + GLES2/3 should be much faster than Ogre 1.x / 2.0 + GLES2/3 (ceteris paribus comparison)

Hotshot5000 wrote:My game has lots and lots of objects on the screen (basically lots of space ships battling each other) and I want to implement a more complex AI than it's usually seen on mobile devices, so I would benefit from having the renderer use as little CPU as possible. GLES3 is the limiting factor here

Well yeah, your case doesn't really fit GLES3 or WebGL very well.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 3080
Kudos: 469
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: [GLES3] Progress update: Some good news!

Postby N0vember » Wed Feb 01, 2017 3:56 pm

Hotshot5000 wrote:So the question for me is what to do first: WebGL2 or Vulkan? Vulkan is clearly the more interesting project and I've been reading books and articles about it lately in order to prepare myself, but with WebGL I might reach the target audience faster as it's already here, while Vulkan will take years before we will see serious adoption. Also, Vulkan tools and drivers seem immature at this point, more so on mobile, so it will probably be a complete PITA developing for it.


Interesting. In my opinion it's generally good to focus on the way forward. In the era of smartphones and tablets the hardware is renewing itself quickly enough that being able to render on old platforms is not so important anymore. So yes, I agree with you that Vulkan is appealing.
However the web is the web. And if you're not web compatible that's definitely a quite hindering drawback. So I think being at least WebGL2 compatible, even if as you say the performance is not great, is really important just to allow yourself to be present on the web.
The thing is I have no idea of the quantity involved. But if it's reasonably small compared to writing the GLES3 renderer in the first place, I think it's worth it.
Therefore if Vulkan is really the future, the winning strategy in my opinion, to get a game run on the most platforms possible, in the middle term and with few renderers, is to have at least WebGL2 and Vulkan.
N0vember
Gremlin
 
Posts: 190
Kudos: 23
Joined: 27 Jan 2009

Re: [GLES3] Progress update: Some good news!

Postby Hotshot5000 » Wed Feb 01, 2017 3:59 pm

dark_sylinc wrote:It's true that 2.1 can't shine without baseVertex/baseInstance family of draw calls (however they may get added as extensions for desktop since Desktop totally supports them).
But please note that even without AZDO:
  • 2.1's frustum culling is much more optimized: significantly less memory overhead, cache friendly, and SIMD friendly (also threading friendly but AFAIK Emscripten/Javascript doesn't have threads). I learnt Emscripten can now convert SSE intrinsics to SIMD.js
  • 2.1's rendering stack is much more lightweight. Go to Ogre 2.0 or 1.x's drawcalls, place a breakpoint and see the (deep) callstack and the surrounding code. There's a huge load of garbage between each draw that significantly reduces performance. GL3PlusRenderSystem::_render in 1.10 is 350 lines of code with lots of branches, loops and fat function calls. In Ogre 2.1 you have a much thinner callstack, and a lot more DrawPrimitive calls called in succession with little overhead between them.

So even without AZDO, Ogre 2.1 + GLES2/3 should be much faster than Ogre 1.x / 2.0 + GLES2/3 (ceteris paribus comparison)


I was under the impression that 2.0 is basically 2.1 without the optimized back end. I was wrong it seems.
Hotshot5000
Greenskin
 
Posts: 111
Kudos: 23
Joined: 14 Oct 2010

Re: [GLES3] Progress update: Some good news!

Postby dark_sylinc » Wed Feb 01, 2017 4:07 pm

N0vember wrote:Interesting. In my opinion it's generally good to focus on the way forward. In the era of smartphones and tablets the hardware is renewing itself quickly enough that being able to render on old platforms is not so important anymore. So yes, I agree with you that Vulkan is appealing.

What I see is exactly the opposite. Smartphones and tablets that can only do GLES2 and KitKat are still being manufactured and sold.
Driver updates take forever to roll in. If they ever do.
Even today GLES2-only devices account for 40% of the market share.
And those that do support GLES3, their drivers are incredibly broken.
Android makes up for its low per-user profitability with a huge market share. Missing half of the cake (or more if we account GLES3 devices that are really broken) is a lot to grok.

iOS world does behave the way you describe: People buy the newest phone and update to the latest OS update and drivers right away. As much as we could try to bash Apple, they got that part right.

N0vember wrote:However the web is the web. And if you're not web compatible that's definitely a quite hindering drawback. So I think being at least WebGL2 compatible, even if as you say the performance is not great, is really important just to allow yourself to be present on the web.
The thing is I have no idea of the quantity involved. But if it's reasonably small compared to writing the GLES3 renderer in the first place, I think it's worth it.

I agree.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 3080
Kudos: 469
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: [GLES3] Progress update: Some good news!

Postby dark_sylinc » Wed Feb 01, 2017 4:09 pm

Hotshot5000 wrote:I was under the impression that 2.0 is basically 2.1 without the optimized back end. I was wrong it seems.

2.0 does have the optimized frustum culling; but it does not have the optimized RenderSystem part. So in terms of speed it should 1.x < 2.0 < 2.1 no AZDO < 2.1 with AZDO
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 3080
Kudos: 469
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: [GLES3] Progress update: Some good news!

Postby frostbyte » Wed Feb 01, 2017 6:40 pm

So the question for me is what to do first: WebGL2 or Vulkan?

i think webGL2.0 adoptation rate will be much higher since the supported hardware is already there as commodity which is by far not the case for Vulkan mobile( as dark_sylinc mentioned es2 level gpu's are still a large part of the market )
and while vulkan for desktop sounds cool, it will share the high-end gpu market with dx12 and Metal
also don't forget that the best you can squeeze from high-end mobile gpu still falls behind commodity embedded desktop gpu even when running on WebGL2 and asm.js

however for ogre users my guess is that Vulkan ogre renderer will be more popular/useful than a webGL renderer
my guess is based on the fact that ever since the ogre-emscripten backend was released i've never read any posts regarding actually using it( googleBar search will confirm my assumptions )
but then again webgl1.x was'nt something you'll want to target heavy graphics and asm.js was'nt invented yet

i'm not sure there is much adoptation for c++ frameworks javaScript ports unless they come with all the goodies and a "deploy to web" button( unity/unreal/libgdx )
developers targeting browser seem to prefer using native browser frameworks as the popular three.js which is understandable considering developing for the web have some different aspects that are hard to achieve using a cumbersome c++ port
e.g integrating ogre with a web application is much harder and less rewarding than just using three.js

but for me the bottom line is that webGL2.0 will hit faster and harder than Vulkan
you can see the big effort that is put into developing webGL2.0, asm.js, webVR and other browser related tech with the intention of making a fundamental change to the web-surfing experience( lots of $$$ are involved )
i guess chrome and firefox enabling WebGL2 by default is the The starting gun for a new browser era( "postFlash" era )

considering we now have GL3 support, porting to webGL2 using emscriptem should be a much easier( but more boring ) task than a vulkan port and would give ogre users an extra platform which Vulkan would not
right now( and in near future ) beside the hype Vulkan does'nt seem to hold much benefit to ogre neither on mobile( small niche market ) or on desktop( not really needed )

SumUp: if you are targeting high-end android niche market it would make more sense for you to do the vulkan port first
but for targeting broader audience and for Ogre i guess webGL2 target is of higher importance and is much easier...

N0vember wrote:
However the web is the web. And if you're not web compatible that's definitely a quite hindering drawback. So I think being at least WebGL2 compatible, even if as you say the performance is not great, is really important just to allow yourself to be present on the web.
The thing is I have no idea of the quantity involved. But if it's reasonably small compared to writing the GLES3 renderer in the first place, I think it's worth it.

yep, browser support pretty much became a standard feature for renderers and game-engines
i think its a psychology thing, like having lots of money in the bank...you don't really use it, but you are happy that its there
For this message the author frostbyte has received 64K kudos
frostbyte
Gnoll
 
Posts: 672
Kudos: 40
Joined: 31 May 2013


Return to Ogre 2.0+

Who is online

Users browsing this forum: No registered users and 4 guests