Ogre2 questions - Performance, API, etc

Discussion area about developing with Ogre2 branches (2.1, 2.2 and beyond)
Post Reply
Gwenn_
Kobold
Posts: 30
Joined: Tue Dec 10, 2013 11:08 pm

Ogre2 questions - Performance, API, etc

Post by Gwenn_ » Tue Dec 10, 2013 11:10 pm

Hi,

First off, thank you all for the wonderful work done on the Ogre project. :)

I'm currently working on a rather ambitious game using Ogre as the rendering engine. It's advancing well, we have a complete rendering pipeline with deferred shading, SSAO, anti-aliasing, and a small mockup of a game engine.
I'm very satisfied with Ogre for most parts, but I'm also following up closely on Ogre2 (we're on 1.9 RC), because I saw "performance" somewhere about it. So, I have a few questions.

1. Performance

This is my main concern. Currently, a very small scene with 20K triangles, a few 2k maps, 15 lights and physics, SSAO, AA etc runs at only ~50fps in full HD. This computer was used to build a Unreal 3 game, with scenes going up to 500K triangles, with handcoded shaders ; it was running smoothly.
Games like Crysis 3 (which outputs, litteraly, millions of triangles with animated vegetation) also run smoothly.

Obviously something is very wrong. Even if deferred shading scales very well, the performance looks off by a factor of ten. I am very aware that my implementation is probably the culprit, but I have heard rumors of bad performance in Ogre 1.x, so I would love some inputs from people who push the engine a bit.
Is Ogre known for less-than-average performance ?
Or is OpenGL on Windows (nvidia GTX560 with recent drivers) known for that ?
And, of course, is it different in Ogre 2.x ? Is it part of the focus ?

2. API, compositors, overlays

I love the compositor system. I use it for everything.
I understand that it is one of the Ogre components that is being rewritten in Ogre2 (actually I can't build my Ogre2 branch, with OgreCompositorLogic.h misisng). Is there any kind of up-to-date sample, generated documentation or help to try out the new Ogre ?

What about overlays ? Not that I plan on keeping them for long, but are they gone from Ogre (can't find the headers either) ?

3. Shaders and RTSS

Okay, so I'm pretty much a low-level guy (C++ looks actually very high-level and abstract in my current line of work) and I love writing shaders. Please don't shoot me.
I see RTSS everywhere in forum threads, I understand what it's used for but I have no interest in it, since most of my scenes are made from very, very similar materials (diffuse/spec/normal map with a metallic look) and use mostly one shader with 4/5 parameters.

Will Ogre2 force RTSS or similar concepts onto the user ?

4. Windows build

Okay, not everyone is perfect, I work with Windows.
I got the last revision of the 2.0 branch built, at least for OgreMain, the OpenGL plugin and a few other things. Some others (Terrain, OpenGL3, etc) won't build, the install target also won't (I had to copy headers by hand, that was fun).

The question here is not "y u no work ??". Of course it doesn't, it's a work in progress. The question is : when will Ogre2 be considered usable for development ? Like in beta or RC state ?


That was it ! Again, thanks a lot for what you do.
0 x

User avatar
c6burns
Beholder
Posts: 1511
Joined: Fri Feb 22, 2013 4:44 am
Location: Deep behind enemy lines

Re: Ogre2 questions - Performance, API, etc

Post by c6burns » Wed Dec 11, 2013 1:05 am

Gwenn_ wrote:Will Ogre2 force RTSS or similar concepts onto the user ?
That would make absolutely no sense. You aren't the only one who uses shaders hehe :)
0 x

User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
Contact:

Re: Ogre2 questions - Performance, API, etc

Post by Klaim » Wed Dec 11, 2013 1:11 am

I expect dark_sylinc to provide detailed answers to each of your questions but meanwhile this might help:

- Almost all information you are asking about is discussed in this thread: http://www.ogre3d.org/forums/viewtopic.php?f=13&t=77143
- The first post describe the work being done (by dark_sylinc for the architectural change, by others for OGL and DX11 changes that will come in 1.10)
- Yes there is a performance problem with Ogre, and yes it's the focus of 2.x (until it's not a problem anymore)
- Don't forget that 2.0 is still work in progress, there is no release, not even release candidate or alpha, it's not usable at all at the moment if I understand correctly (expect limited cases); I believe a lot of code is not pushed yet into the official Ogre repository, and some code might not be merged into 2.0 branch either;
- dark_sylinc did some (not very scientific but just to see if there is a difference) benchmarks on his blog, see the link in the first post of the thread
- you will also find a work-in-progress manual explaining the changes between 1.9 (at least) to 2.0, at the end of the first post
0 x

Gwenn_
Kobold
Posts: 30
Joined: Tue Dec 10, 2013 11:08 pm

Re: Ogre2 questions - Performance, API, etc

Post by Gwenn_ » Wed Dec 11, 2013 9:43 am

Thanks a lot, looks like I missed that tread !

So if I understand well, the current scope of ogre2 is to remake most of the scene managing, node hierarchy to bring more performance.

I took a close look at the small benchmark made here (http://yosoygames.com.ar/wp/2013/07/ogr ... 3x-faster/). The difference looks nice. However I'm still surprised by the vast difference between Ogre performance and commercial games. Apparently, a low-res 750k-tris scene will go from 400ms to 250ms, that is nice but... The hardware used can run a high settings, full HD Crysis 2 at a fraction of the cost.

I am not trying to trash Ogre here, just trying to get an idea of what to expect and what is costing so much. Game developers publish a lot of data on their engines, commercial SDK output the frame time breakdown as well. Is such data available for Ogre to understand what we are doing wrong ?
0 x

AgentC
Kobold
Posts: 33
Joined: Tue Apr 24, 2012 11:24 am

Re: Ogre2 questions - Performance, API, etc

Post by AgentC » Wed Dec 11, 2013 11:57 am

That particular benchmark is not something you would want to run in a real application, considering that it consists of 62500 individual drawcalls of very simple objects of only a few triangles each, so the total triangle count ends up being very low while the rendering is totally bottlenecked by the CPU.

There's also an instanced version of the same benchmark where much nicer frametimes (below 20ms range) are reported.

http://yosoygames.com.ar/wp/2013/08/hw- ... rk-on-2-0/

However there is also potential for Ogre to handle the drawcalls themselves much faster (it's doing a lot of redundant work & API calls per drawcall). Just an example, in another open source engine which tries to reduce unneeded API calls as much as possible I've replicated the benchmark scene - without animation - with following results -
Individually culled 62500 objects, no instancing - 40 ms
Individually culled 62500 objects, hardware instancing - 16 ms
Group culled 62500 objects, no instancing - 25 ms (625 objects per group -> 100 groups)
Group culled 62500 objects, hardware instancing - 2.5 ms

Where the third case (25 ms) represents a workload where it's mostly only about the drawcalls, basically looping SetVertexShaderConstantF() for the object's world transform and DrawIndexedPrimitive() 62500 times. I highly recommend looking at an Ogre program with PIX (on Windows) to see what the rendersystem is doing for each drawcall. It's easily tens of API calls, even when drawing objects with same material and lighting.
0 x

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

Re: Ogre2 questions - Performance, API, etc

Post by dark_sylinc » Wed Dec 18, 2013 12:33 am

Hi!

I'll try to answer your answers. Please read the Ogre 2.0 slides to know more about the state of the art of Ogre 1.9 and how far you can push it (these slides were written as a proposal, i.e. Ogre 2.0 had not been written at that time).
This is my main concern. Currently, a very small scene with 20K triangles, a few 2k maps, 15 lights and physics, SSAO, AA etc runs at only ~50fps in full HD. This computer was used to build a Unreal 3 game, with scenes going up to 500K triangles, with handcoded shaders ; it was running smoothly.
Games like Crysis 3 (which outputs, litteraly, millions of triangles with animated vegetation) also run smoothly.

Obviously something is very wrong. Even if deferred shading scales very well, the performance looks off by a factor of ten. I am very aware that my implementation is probably the culprit, but I have heard rumors of bad performance in Ogre 1.x, so I would love some inputs from people who push the engine a bit.
All you mentioned (triangle count, texture resolution, number of lights, SSAO, AO, screen resolution) depends on your video card and to a lesser extent, the cpu. So if THAT's the culprit, it's your own fault (shaders, inefficient passes, etc)

That being said, where Ogre is most likely at fault is in the Entity count and the number of Compositor passes. As you may see from the slides, Ogre 1.9 is very stupid when performing compositor passes, thus traverse a lot of the scene graph unnecessarily.
The other thing that hurts directly is the number of Entities. Regardless of how many triangles you have, the more Entities you create, the much slower it gets.

Ogre 2.0 solves the Compositor inefficiencies (note the script syntax changed a little, but it is easy to port) and scales very, very well with high number of Entities. It is however advised that you use Instancing (see NewInstancing example) whenever possible (this applies to both 1.9 and 2.0). Improvements like 3x or 5x are common when porting from 1.9 to 2.0 unless you had too many texture and shader switches.
There are still big inefficiencies we need to address (like the RenderSystem API management and the RenderQueue) though if you use instancing these will affect you very little; and these won't be improved in Ogre 2.0; but probably in 2.1 or 2.2

As for the particular case Crysis comparision, beware that on the GPU side they use extremely optimized algorithms: They work with framebuffers in YUV space to halve the bandwidth usage, pack their vertex data using a technique called QTangents, compress normal map's GBuffers into just 24-bit using an algorithm they called "Best Fit normals", etc.
Though these techniques are up to you to implement, we're trying to ease some of them (i.e. try to support QTangent generation natively in the exporter) but it will be a long time until we reach then. Right now we've got various elephants in the room.
They also use D3D11 which allows for some optimizations currently not possible due to Ogre's highly compatible RS (D3D9, D3D11, GL, GL3.0; GL ES, etc)

Beware though, we're still working on Animations, and if you've got too many skeletal animations, Ogre 2.0 may perform worse than 1.9 did.
Gwenn_ wrote: 2. API, compositors, overlays

I love the compositor system. I use it for everything.
I understand that it is one of the Ogre components that is being rewritten in Ogre2 (actually I can't build my Ogre2 branch, with OgreCompositorLogic.h misisng). Is there any kind of up-to-date sample, generated documentation or help to try out the new Ogre ?
The compositor has been rewritten, but the script syntax is almost the same; if you were using scripts, porting is very easy. If you used to heavily control the Compo from C++, then the code changes could be massive.

There is no working example of the new Compositor yet and that's my fault. After I'm done with animations, I will focus on these samples.
Gwenn_ wrote: What about overlays ? Not that I plan on keeping them for long, but are they gone from Ogre (can't find the headers either) ?
They're still on Ogre 2.0 (look in the Components folder). AFAIK we don't have any plans for them (to remove, improve, nor anything)
Gwenn_ wrote: 3. Shaders and RTSS

Okay, so I'm pretty much a low-level guy (C++ looks actually very high-level and abstract in my current line of work) and I love writing shaders. Please don't shoot me.
I see RTSS everywhere in forum threads, I understand what it's used for but I have no interest in it, since most of my scenes are made from very, very similar materials (diffuse/spec/normal map with a metallic look) and use mostly one shader with 4/5 parameters.

Will Ogre2 force RTSS or similar concepts onto the user ?
We don't plan to force high level shaders on users. For many users writing their own shaders is tricky, and no system currently offers something easy for them (that includes RTSS, hence a hot topic).
Additioanlly, RTSS is currently the best way to deal with mobile; because these mobile platforms don't support fixed function pipelines; and writing a shader for each trivial thing like showing up an overlay with alpha blending is a PITA even for us low level coders (this also includes D3D11).
Gwenn_ wrote: 4. Windows build

Okay, not everyone is perfect, I work with Windows.
I got the last revision of the 2.0 branch built, at least for OgreMain, the OpenGL plugin and a few other things. Some others (Terrain, OpenGL3, etc) won't build, the install target also won't (I had to copy headers by hand, that was fun).
That's ok. Some samples and components are very low priority and hence not being giving attention; besides I'm the main guy behind 2.0; and there are a few components I've never even looked at; like the Terrain component. Eventually they'll get fixed I guess.
Sometimes, some RS (like OpenGL3) stop working because I don't use them too often and get out of sync, but that's only temporary and get fixed easily afterwards. Perhaps GL3 not the best example because it is a big exception: have been major developments on another branch (it was a parallel GSoC project) and I want to wait until I merge those change into 2.0 before I keep touching GL3.
Gwenn_ wrote: The question here is not "y u no work ??". Of course it doesn't, it's a work in progress. The question is : when will Ogre2 be considered usable for development ? Like in beta or RC state ?
I personally use it, and some few people already started using it. But beware it comes with a "use at own risk" moniker attached. I would say it's somewhere between alpha and beta. Don't be surprised if your scene suddenly glitches, or it has got memory leaks.
For example, yesterday I happen to fix a nasty memory corruption problem that was going unnoticed.
The current version is actually very stable, and we would love to hear early developer feedback.
0 x

Gwenn_
Kobold
Posts: 30
Joined: Tue Dec 10, 2013 11:08 pm

Re: Ogre2 questions - Performance, API, etc

Post by Gwenn_ » Wed Dec 18, 2013 9:39 am

Hi !
dark_sylinc wrote:All you mentioned (triangle count, texture resolution, number of lights, SSAO, AO, screen resolution) depends on your video card and to a lesser extent, the cpu. So if THAT's the culprit, it's your own fault (shaders, inefficient passes, etc)

That being said, where Ogre is most likely at fault is in the Entity count and the number of Compositor passes. As you may see from the slides, Ogre 1.9 is very stupid when performing compositor passes, thus traverse a lot of the scene graph unnecessarily.
The other thing that hurts directly is the number of Entities. Regardless of how many triangles you have, the more Entities you create, the much slower it gets.
That's interesting. Right now I have no more than 20 entities, and as much meshes. The shaders are pretty simple, textures can be big but it's not nearly as texture-heavy as a 2007 game either.

However I do have a complex pipeline. We are doing deferred shading with forward rendering for transparency, and glowing transparency for some effects. So we have three rendering passes, as much as ten compositor targets, some very basic post-processing. Can I expect much better performance ?

I also noticed that though my current framerate is just average, doubling the poly count on screen doesn't impact performance (at least not much). I'm still at very low numbers so I guess I should just try with 100k, 200k, 500k etc.
dark_sylinc wrote:As for the particular case Crysis comparision, beware that on the GPU side they use extremely optimized algorithms: They work with framebuffers in YUV space to halve the bandwidth usage, pack their vertex data using a technique called QTangents, compress normal map's GBuffers into just 24-bit using an algorithm they called "Best Fit normals", etc.
Though these techniques are up to you to implement, we're trying to ease some of them (i.e. try to support QTangent generation natively in the exporter) but it will be a long time until we reach then. Right now we've got various elephants in the room.
They also use D3D11 which allows for some optimizations currently not possible due to Ogre's highly compatible RS (D3D9, D3D11, GL, GL3.0; GL ES, etc)
Should I use OpenGL3 for better performance ? I am still using the default GL renderer.
dark_sylinc wrote:There is no working example of the new Compositor yet and that's my fault. After I'm done with animations, I will focus on these samples.
That would be great indeed. Maybe you have some pointers to existing code that works with Ogre2 ? Reverse-engineering undocumented code is pretty much my current employment, I'd rather have something to crunch now than wait for a clean and proprer sample.
dark_sylinc wrote:I personally use it, and some few people already started using it. But beware it comes with a "use at own risk" moniker attached. I would say it's somewhere between alpha and beta. Don't be surprised if your scene suddenly glitches, or it has got memory leaks.
For example, yesterday I happen to fix a nasty memory corruption problem that was going unnoticed.
The current version is actually very stable, and we would love to hear early developer feedback.
Okay. Well I'm good with that, I'll try to get it built. Expect feedback soon !

Thank your for answering my questions.
0 x

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

Re: Ogre2 questions - Performance, API, etc

Post by dark_sylinc » Wed Dec 18, 2013 5:48 pm

Gwenn_ wrote: That would be great indeed. Maybe you have some pointers to existing code that works with Ogre2 ? Reverse-engineering undocumented code is pretty much my current employment, I'd rather have something to crunch now than wait for a clean and proprer sample.
We have porting a manual that should explain/clarify your doubts about the code, including examples inside.
0 x

Gwenn_
Kobold
Posts: 30
Joined: Tue Dec 10, 2013 11:08 pm

Re: Ogre2 questions - Performance, API, etc

Post by Gwenn_ » Wed Dec 18, 2013 5:58 pm

dark_sylinc wrote:
Gwenn_ wrote: That would be great indeed. Maybe you have some pointers to existing code that works with Ogre2 ? Reverse-engineering undocumented code is pretty much my current employment, I'd rather have something to crunch now than wait for a clean and proprer sample.
We have porting a manual that should explain/clarify your doubts about the code, including examples inside.
Unless I am mistaken, there is very little C++ code in this document, and nothing on the C++ API for compositors. Things like adding a compositor, enabling it, that kind of stuff.
0 x

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

Re: Ogre2 questions - Performance, API, etc

Post by dark_sylinc » Wed Dec 18, 2013 6:20 pm

Gwenn_ wrote:
dark_sylinc wrote:
Gwenn_ wrote: That would be great indeed. Maybe you have some pointers to existing code that works with Ogre2 ? Reverse-engineering undocumented code is pretty much my current employment, I'd rather have something to crunch now than wait for a clean and proprer sample.
We have porting a manual that should explain/clarify your doubts about the code, including examples inside.
Unless I am mistaken, there is very little C++ code in this document, and nothing on the C++ API for compositors. Things like adding a compositor, enabling it, that kind of stuff.
Ooops, sorry.
You'll find some stray code that works, scheduled for removal in CompositorManager2::CompositorManager2 constructor that setups a compositor definition.
You can also look CompositorManager2::createBasicWorkspaceDef.
Finally, to fully know how to set a definition, for now may want to look what CompositorWorkspaceTranslator, CompositorPassTranslator, CompositorNodeTranslator & CompositorShadowNodeTranslator are doing (in OgreScriptTranslator.cpp)

Once a definition is set, just use the same snippet codes that are in the manual, i.e.:

Code: Select all

CompositorWorkspace *myWorkspaceInstance = compositorManager->addWorkspace( mSceneMgr, mWindow, mCamera, workspaceName, true );

myWorkspaceInstance->setEnabled( myBoolean );
A workspace instance right now is quite hard to manipulate on real time (i.e. just destroy the instance, modify the definition, create the instance again). In the future you should be able to access the CompositorNodes of the instance and alter the connections on the fly (with some limitations).
See section 4.4 and 4.4.3 of the porting manual.
The idea is that there should be one workspace per window; so if you want Bloom and Sharpen edges, you would create a workspace definition including bloom and sharpen edges, then instantiate.
If you wanted to toggle sharpen edges on and off very frequently, you would alter the channel connections of the node one the fly with no performance penalty (but for now this is not feasible as there is no public interface written to do so); and perhaps a function could handle this toggling automatically for Nodes that have one input and one output (it's like a VCR plugged to a DVD which is plugged to the TV; if you want to disable the DVD, unplug the VCR from the DVD, and plug it directly to the TV; to re-enable, unplug the VCR from the TV, plug it to the DV andD, plug the DVD back to TV).
0 x

Gwenn_
Kobold
Posts: 30
Joined: Tue Dec 10, 2013 11:08 pm

Re: Ogre2 questions - Performance, API, etc

Post by Gwenn_ » Thu Dec 19, 2013 12:00 am

Thanks a lot !

Well, Ogre builds (mostly). At least all components that I used do.

So I'm trying to get my current code to build. The code seems to compile but it doesn't link, which is weird because I didn't expect it to compile in the first place and because, well, 115 unresolved externals ?
I double-checked that I have the correct path, that the lib files are existing, that everything is built as Release x64 but no, it won't link. And errors are everywhere, things as trivial as the MaterialPtr or SceneNode constructors or Camera::getViewport, basically every Ogre method throws a linker error.

Like I said before all headers and lib files are hand-copied since the INSTALL target fails.

Since the 2.0 branch is deemed "usable", that's probably an issue on my end. What can I do to debug the build ?
0 x

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

Re: Ogre2 questions - Performance, API, etc

Post by dark_sylinc » Thu Dec 19, 2013 1:19 am

Camera::getViewport no longer exists (it's now called Camera::getLastViewport). So if it compiled but linker complains, either you need a clean rebuild (i.e. precompiled headers didn't update, a cpp file didn't recompile, etc), or you're using the headers of 1.9 but the libs of 2.0
0 x

Gwenn_
Kobold
Posts: 30
Joined: Tue Dec 10, 2013 11:08 pm

Re: Ogre2 questions - Performance, API, etc

Post by Gwenn_ » Thu Dec 19, 2013 1:42 am

:roll:

Okay, well, cleaning wasn't enough, I had to remove my build folder. Don't event want to know what Visual is doing here...
Now it's using the actual headers, I just have to port my code. Thank you for your patience ! I'll get back to you as soon as I get a working build (OR another noob question).
0 x

Gwenn_
Kobold
Posts: 30
Joined: Tue Dec 10, 2013 11:08 pm

Re: Ogre2 questions - Performance, API, etc

Post by Gwenn_ » Thu Dec 19, 2013 8:22 pm

Back to business !

I'm now working on porting my code to Ogre2. Most of the API seems to be unchanged, apart from a few things I can't find anymore.
  • Where are CustomCompositionPass and RenderSystemOperation ? I use them actively for deferred shading
    SimpleRenderable now need a full constructor, what am I supposed to use as Id and ObjectMemoryManager ?
    Why is there no more getDerivedPosition in Lights ?
Thank you for your work !
0 x

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

Re: Ogre2 questions - Performance, API, etc

Post by dark_sylinc » Fri Dec 20, 2013 2:06 am

Hi!

Something similar to CustomCompositionPass will make soon a comeback, but I haven't written it yet (it's actually easy, but I want to test the other passes first before adding more). Note however that with the new Compo it's possible to do stuff that earlier you could only do with custom composition passes. A deferred shading is perfectly possible with just messing a bit with RQs and Scene flags. I haven't written a sample yet.
SimpleRenderable now need a full constructor, what am I supposed to use as Id and ObjectMemoryManager
I haven't gotten around SimpleRenderable thinking to see how to "by design" deal with these problems.
The ID is the easy one. An ID must be unique within the set of MovableObjects it will be used. If unsure, just call Id::generateNewId<MovableObject>() (we allow the caller to set the ID rather than doing it inside the object, in case of multithreaded environments where the user may want to have parallel scenes or similar where ID clashing won't be a problem; thus no need to share the same global count)

As for the ObjectMemoryManager, that is a bit trickier. Right now because there is no Scene Manager implementation written other than the default, it can only be either SceneManager::mEntityMemoryManager[SCENE_DYNAMIC] or SceneManager::mEntityMemoryManager[SCENE_STATIC] and thus using those directly will work.
The "tricky" part is that I have yet to think of an interface that will deal generically with future implementations. I guess something like virtual ObjectMemoryManager& getDefaultMemoryManager( SceneMemoryMgrTypes ) may actually work.
You can currently grab the pointer using SceneManager::_getEntityMemoryManager

Note: If you only intend to do local stuff in a local scope, i.e.

Code: Select all

{
    //Local scope
    SimpleRenderable s( 0, ObjectMemoryManager() ); //Null ID, local-scoped memory manager
}
This will actually work (unless you actually want to render to scene). This pattern is most useful when creating local versions of Cameras or SceneNodes (to aid in calculations)
0 x

Gwenn_
Kobold
Posts: 30
Joined: Tue Dec 10, 2013 11:08 pm

Re: Ogre2 questions - Performance, API, etc

Post by Gwenn_ » Fri Dec 20, 2013 8:19 am

Thanks a lot, some errors down !

As for the CustomCompositionPass I will wait for something to come up. I need two things :
- A RenderOperation, to compute the lighting
- The CustomCompositionPass was just here to set this RenderOperation

If something existing looks like that, well...

What about the getDerivedPosition thing ?

Also, what about the _getLightsAffectingFrustum method in SM ?

Thanks !
0 x

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

Re: Ogre2 questions - Performance, API, etc

Post by dark_sylinc » Fri Dec 20, 2013 4:18 pm

Gwenn_ wrote:What about the getDerivedPosition thing ?
Oops, forgot to answer that question. It's in section 2.5 of the manual, basically, ask the SceneNode it's attached to, which contains that information.
Gwenn_ wrote: Also, what about the _getLightsAffectingFrustum method in SM ?
That function was extremely slow. Again, Ogre will do the culling for you if you keep the lighting objects in its own pass. And by using instancing for the light objects, it should be super fast; surely faster than a per-draw-call light object.
But if you choose to keep using the "custom" route, getGlobalLightList may provide what you want. However, it's more inclusive than its predecessor since it is a list of lights affecting all frustums (in case you've created more than one camera; note the cameras used for shadow mapping don't count; if you just created one camera, the global light list will only contain all lights visible by that camera).
0 x

Gwenn_
Kobold
Posts: 30
Joined: Tue Dec 10, 2013 11:08 pm

Re: Ogre2 questions - Performance, API, etc

Post by Gwenn_ » Fri Dec 20, 2013 4:35 pm

To clarify the culling thing. My 1.9 implementation is very close to the Ogre deferred shading demo : the light culling is done manually in a custom renderoperation. That is, user code checks, for all lights affecting the frustrum, wether they are close enough to affect the render, and compute the lighting / shadows. Looks like this. : https://github.com/arbonagw/Soyouz/blob ... ration.cpp

Now, from what you said I understand that I should now leave all that stuff to the engine (I'd love that actually). How exactly will this code be rewritten when Ogre supports a new kind of custom pass ? Maybe a "custom pass" attribute in the compositor script ?
0 x

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

Re: Ogre2 questions - Performance, API, etc

Post by dark_sylinc » Fri Dec 20, 2013 4:52 pm

When custom pass support is added, it will work more less just like in 1.9
The thing is, you can implement a deferred shading system without actually using custom passes. I need to write that sample.
0 x

Gwenn_
Kobold
Posts: 30
Joined: Tue Dec 10, 2013 11:08 pm

Re: Ogre2 questions - Performance, API, etc

Post by Gwenn_ » Fri Dec 20, 2013 4:57 pm

Okay then. I'll wait for the sample :)

Thanks a lot for your support.
0 x

Lacero
Halfling
Posts: 72
Joined: Tue Feb 13, 2007 1:57 am

Re: Ogre2 questions - Performance, API, etc

Post by Lacero » Sun Dec 22, 2013 1:13 pm

dark_sylinc wrote: I personally use it, and some few people already started using it. But beware it comes with a "use at own risk" moniker attached. I would say it's somewhere between alpha and beta. Don't be surprised if your scene suddenly glitches, or it has got memory leaks.
For example, yesterday I happen to fix a nasty memory corruption problem that was going unnoticed.
The current version is actually very stable, and we would love to hear early developer feedback.
I tried Ogre 2.0 on windows Mingw DW2 with eclipse, I found a couple of interesting things. I disabled everything except overlay (which seems to be needed, compiling without it failed)
This is just in the interest of helping out anyone else, and maybe pointing some things out to you that you may have missed on your platform and that may be easier to fix sooner than later. It's very early I know, and likely I've done something wrong more often than the code base hasn't been ready. But I figure this is useful for morale purposes in showing someone trying to use it if nothing else ;)

* overlay seems to be needed to compile successfully
* OgreSceneManager.cpp creates a material for "Ogre/TextureShadowCaster", this immediately tried to mess with technique 0. The current Material creation code doesn't seem to create techniques by default so this is a crash.
* More seriously the use of __m128 is causing (predictable) problems on windows with the stack. see http://www.peterstock.co.uk/games/mingw_sse/
It seems like someone will have to go through and add __attribute__((force_align_arg_pointer)) to every thread entry point on gcc windows builds. Or we could add -mstackrealign to gcc on windows. This last one is slow so kind of against the point. This is the one that might be better with early action than trying to fix everything up later.
* the OgrePixelBox.h header was missing in a few places. OgrePixelConversions.h, OgreWin32Window.cpp
* use of intrin.h should be x86intrin (or something else) on this platform. OgreBarrierWin.h for example

I'm going back to 1.9 rather than rewrite how I set up the viewport and camera but other than that everything looked ok. It rendered a cleared black screen fine :D
0 x

TheSHEEEP
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 972
Joined: Mon Jun 02, 2008 6:52 pm
Location: Berlin

Re: Ogre2 questions - Performance, API, etc

Post by TheSHEEEP » Wed Jan 01, 2014 11:08 pm

Lacero wrote:* More seriously the use of __m128 is causing (predictable) problems on windows with the stack. see http://www.peterstock.co.uk/games/mingw_sse/
It seems like someone will have to go through and add __attribute__((force_align_arg_pointer)) to every thread entry point on gcc windows builds. Or we could add -mstackrealign to gcc on windows. This last one is slow so kind of against the point. This is the one that might be better with early action than trying to fix everything up later.
In the recent 2.0 version, this __attribute__ can be found in OgreSIMDHelper.h. It is used in OgreOptimisedUtilSSE.cpp.
This should already fix that problem, or are there other places where it should be used, that we missed?
0 x
My site! - Have a look :)
Also on Twitter - extra fluffy

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

Re: Ogre2 questions - Performance, API, etc

Post by dark_sylinc » Thu Jan 02, 2014 5:04 pm

TheSHEEEP wrote:
Lacero wrote:* More seriously the use of __m128 is causing (predictable) problems on windows with the stack. see http://www.peterstock.co.uk/games/mingw_sse/
It seems like someone will have to go through and add __attribute__((force_align_arg_pointer)) to every thread entry point on gcc windows builds. Or we could add -mstackrealign to gcc on windows. This last one is slow so kind of against the point. This is the one that might be better with early action than trying to fix everything up later.
In the recent 2.0 version, this __attribute__ can be found in OgreSIMDHelper.h. It is used in OgreOptimisedUtilSSE.cpp.
This should already fix that problem, or are there other places where it should be used, that we missed?
There are a few new threads introduced for the new multithreading.
I'll take a look

Edit: Should be fixed now in https://bitbucket.org/sinbad/ogre/commi ... ed9ddcfe56
0 x

Post Reply