Ogre 2.0 doc (slides) - Updated 1st dec 2012

[DanielSefton]

I see a big divide in programmers, tools, applications, and approaches between cellphone graphics programming and pc/console. I am unsure why anyone would want to do both with the same library. I'd take a mansion or a yacht over a houseboat, any day of the week. Some code / diskformat sharing would be good, but let's not overdesign the core APIs for compatability between cells and pcs! Noone is porting an optimised pc game to the cellphone by simply recompiling it with a different rendersystem. All the rendering techniques, materials, and assets will have to change. How about two different rendersystem APIs, two different scene management APIs, a shared resource system, and shared math/scene culling APIs? Bring all the appropriate bits together to make a complete library for your given system.

You're inflating a non-issue. I've spent 3 years working with Ogre on mobile platforms and performance could be better, but I still get a solid 60 FPS on iPhone 4 in my simpler levels, even despite the slower processor vs. resolution. As I mentioned before, any optimization made to Ogre for PC would trickle down to mobile, and any platform specific improvements can be reviewed and implemented by the appropriate team members. Plus, there's not as big difference as you're making out: It's not mice vs elephants, the iPad 4, iPhone 5 and higher end android devices are blisteringly fast, and they're only going to get more powerful.

That said, I'm with you about the idea of just splitting the threading into two operations: scene graph and drawing. A fancy task system is not the magic answer for performance, it's much deeper than that.

An example of performance loss from a Data-Oriented perspective is that currently we abstract render systems via inheritance and virtual overrides. There's even virtual functions infecting the main loop. We do not need the ability to swap render systems at runtime. If you're building a game for windows, choose DirectX at compile time, if you're building for Mac, choose OpenGL at compile time etc. There's no benefit for allowing the user to swap between the two.

[Klaim]

sparkprime> I basically agree with all you said, but the part about dlls " Static linking is the answer for libraries like Ogre." dont hold true for everybody. In most cases ok, but I have examples where this cannot be done, or an alternative would be equivalent to having dlls anyway (most common case is when you want to allow native extension of your app that needs to know the graphic api). That being said, it's still minor issue as Ogre can be compiled whatever the way the user wants. To me the point of separating in components isn't a problem if it's only Ogre that is compiled with it's component always static. Is that what you mean? If yes, I agree, forget what I just said.

If you're building a game for windows, choose DirectX at compile time, if you're building for Mac, choose OpenGL at compile time etc. There's no benefit for allowing the user to swap between the two.

+++
Definitely agree. That being said, the renderer switching feature is still useful for some kind of application (like samples?), so if they are still considered necessary, I dont see how to avoid it...

[Kojack]

If you're building a game for windows, choose DirectX at compile time, if you're building for Mac, choose OpenGL at compile time etc. There's no benefit for allowing the user to swap between the two.

+++
Definitely agree. That being said, the renderer switching feature is still useful for some kind of application (like samples?), so if they are still considered necessary, I dont see how to avoid it...

Wild Magic (the engine ogre borrowed some of it's maths code from) used to use runtime render system choosing like we do, but around version 5 they changed to a compile time choice to avoid the virtuals. I don't know how much it helped though (I've never used it). I have some vague ideas of how we could support both, but I haven't played around with it yet.

[Klaim]

Personally I wouldn't mind having only compile time choice (I think it's a good idea). I just wonder if other will not have problems with it (in particular when comparing samples).

[lunkhound]

If you're building a game for windows, choose DirectX at compile time, if you're building for Mac, choose OpenGL at compile time etc. There's no benefit for allowing the user to swap between the two.

What if you want your PC game to support DX11 but also DX9 as a fallback (for Windows XP, or lower end GPUs)? It is pretty common for current PC games to support both.

edit: To answer my own question, I guess in this case, one could compile OGRE as a pair of DLLs, one for DX11 and the other for DX9. The game executable then selects between the two at runtime. Each DLL is statically linked to its rendersystem and all of the other components it needs.

[masterfalcon]

As you may have noticed, we've created a new forum for 2.0 design and related discussion. Because there are so many aspects to the project using 1 thread is just unreasonable and frankly, getting confusing.

So let's start off with a thread for each feature or task so we can have some great, distinct discussions. For example: Threading, RenderSystem design and changes, SceneManager, RTSS, etc.

Also, if you find a comment in one of the existing threads that is particularly helpful or relevant to your comment please include a link to the comment or quote it in the new threads.

Thanks!

Masterfalcon

[syedhs]

I do support the idea (been thinking myself for quite some time) to do away with pluggable Rendering System. There is currently too much effort to create standardized interface for OpenGL, DirectX, DirectX11, OpenGLES.. Maybe there are common grounds for OpenGLXX but with DirectX11, it seems a bit too much effort is done so that it adheres to previous Ogre design (which was wonderful because we only have like 2 renderers).

But we need to move forward, a simpler design yet faster is preferred. I am not expert in Graphics Programming, but that is what I see from higher level point of view. With this way, we can also aim toward 'native' DirectX/OpenGL which make possible of all available features in DirectX/OpenGL

[dark_sylinc]

First of all, regarding the Threading/tasks issue. I quickly wrote an addedum to make a few things clearer. I'm updating the original post so it can be viewed there too.
I didn't include references & stuff because they're more like notes, and I didn't have the time.

My understanding of some of the plans is a little sketchy. I haven't been keeping up with it as much as I should have. But I believe one of the main goals is speed up scene graph updates via threads.

Discussion in the forum topic went straight to threading. But as for the slides, the topics were:

• Eliminate cache misses & cache polution through pointers to relevant data
• Smarter behavior about culling & traversing the scene
• Data-level parallelization (SIMD)
• Execution level parallelization (Threading)
• Other engine design changes.

Sqeaky's whole posts

Sqeaky seems to have a good understanding of my intentions. Also he seems to have a good graps of the parallel world hazards. I agree to everything he said.

It seems every body agrees Transforms -> Cull -> Complex Visuals -> Render, but which stages depend on each other for data and which connections are essential? How many of these become into 1 Task/WorkUnit and how many become some data driven amount of Tasks/WorkUnits?

I'm going to assume "Complex Visuals = Sorting & Material preparation".
There's no ultimate answer. "It depends". For example if the game consists on a simple scene of one pass, no shadows; then cull -> transform is preferred, because you only update what's visible. This was your typical 1999 game.
But if you have shadows, environment maps, and/or multiple passes; then cull -> transform may be counterproductive, because you may need to transform the same object on each pass where it appears repeated (i.e. no reuse). Transforming before culling may iterate over a few objects that were culled on all passes, but tends to be much scalable because the number of non-culled objects is statistically much higher.

For Each scene: const shared Nodes Buffer -> Transformed Nodes Buffer
For Each Viewport: const shared Transformed Nodes Buffer -> Culled Transformed Node Buffer (threadable)
For Each renderTarget: const shared Culled Transformed Node Buffer -> RenderQueue (threadable)
For Each RenderQueue: const shared Render Queue -> Command Buffer

Transforming the nodes is threadable. The baking the command buffer is threadable in D3D11 (apparently not in GL?)
I'd like to start thinking of "compositor output" rather than Viewport, since it's easier to visualize and work with. Viewports are still useful for setting up render area & some old school tricks; and ultimately each compositor outputs to a viewport.

sparkprime's whole post

I agree with Sparkprime. And his rant is hilarious.
Although I don't agree on his view on cells. Next generation of phones is going to be a beast (Samsung Galaxy SIII computing power is quite impressive) and GL ES 3.0 is a real step forward (may be the Khronos group is doing something good with GL for once?).
As for the PC vs Phone vs Tablet "who will win?" debate?, is a fairly subjective point. The media tends to hype "the PC is dying" because it's investor's lingo for "sales increasing slower than before".
If we look at history, live theaters took quite a hit when movies appeared. And radio took quite a hit too when TV appeared. And TV is "dying" when broadband internet became mainstream. People now spends more time on the PC than on the TV.
And the movie industry was predicted to be "dead by now" because of online piracy. But there are a few movies that sold quite well for a dead medium.
Radio wasn't replaced by TV, it had to share a similar market.

Most likely PC vs Phone/Tablet will follow the same pattern. Phones will grow as big to not be ignored hurting the PC; but the PC won't disappear. I could be wrong though. Exceptions happen.

Therefore having two different APIs is a tremendous amount of work we're not able to cope with. Of course, the Ogre user at a higher level can't aim at plug 'n play ports between PC & phones unless computing power required for his game isn't big. But he still needs to work out the shader quirks (as we don't provide uber shaders like UDK).


As for the static render systems, that's an interesting approach. I don't know how bad the virtuals will be after we separate states from SceneManager & RenderSystem; but certainly phones & consoles are the most affected.
Fallback support for DX11 & DX9 isn't hard really. Just watch all the other games: Include 2 executables + 1 launcher. The launcher detects DX support (or GL option) and launches the right program.

What I would propose is doing the work from back to front. First fixing the rendersystem API (...)

Well, you propose doing the reverse order I do. I'm writing the series of tasks regarding scene management, but it lacks a bit on the RenderSystem side. You could help up a little on that adding those tasks.
They can be done at the same time. I prefer focusing on the tasks I propose, then Render APIs; but there is no reason they can't be done concurrently if enough volunteers are found. I know what I'll be working on. But I can't speak for the rest of the team and contributors.

(...) It needs cleaning up too, with the removal of fixed function functionality. It seems we're coming close to this with the GL4 and D3D11 work nearing completion.

Well, one of the reasons I came with the idea of States (which isn't new btw.) is not only performance and usability (since RTSS should be able to build shaders for newbies basing on their states) but also as fear the FF makes a come back. You never really know. A new architecture. A new technique. Who knows.
A year ago Forward Rendering was dying. Today Deferred Shading using GBuffers has it's days counted. In 2006 FF was dying, but Nintento chose to launch the Wii with FF. And in 2010 FF appeared to be a dead end, but it was a good idea for the tessellator (since Geometry Shaders sucked at that).

[Xavyiy]

I'm on a hurry so it's going to be fast, I just want to share my opinion about dark_sylinc's addendum:

As some of you may know, 3 years ago I spent 2 months building a general-purpose task library, which I use in the Paradise Engine. In that scope, a whole framework to parallelize(Engine, editor, ocean simulation, ...), something like that is needed since it's very useful defining a list of tasks, define dependencies between them if needed, and then execute them relying on the task scheduler.

But, the scheduler itself adds some overhead(here is where tasks granularity becomes very important) when executing tasks, since it needs to signal the worker thread, executes the task, notify the scheduler back when finished, etc. The overhead will depend a lot of the scheduler features(support or not of data dependencies between tasks, etc) but it'll be always slower than a simple barrier system like dark_sylinc is proposing.

What I am trying to say? That if UpdateAllTransforms() & UpdateAllAnimation() are the most relevant candidates for parallelizing, I really suggest doing it in a simple, clear and efficient way: the barrier system. Easy to debug, easy to modify and, at the end, more efficient than using a task-based lib. Less overhead. Granularity could be a problem, but nothing stop us from doing some real-time profiling and adapt the range of objects each thread updates. Also, a great thing here is that the time needed to update each node is constant (it'll not be the same for animations, but it's not going to be a huge difference), so that helps a lot! (In a task-based system each task may have very different execution times, you can mix little tasks with big tasks, so granularity/profiling becomes very important to avoid wasting of CPU resources).

Xavier

[dark_sylinc]

OK!! I added the tasks needed for Ogre 2.x
They're in the WIKI PAGE.

I may have missed a lot of tasks, so feel free to add more (debate if unsure).
Some of you will probably argue about the order in which this has to be done. There's no magic bullet. This is the order *I* would do it. And since I'm going to commit a bit of my time in the next year for Ogre that's what I'll be working on.

If someone else feels to work on the RS side of things, for example; he can do it parallel to my work of course
For example task "Replace "create read only -> lock" pattern for "initialize on creation" pattern in order to ease D3D11 development. " is VERY important in order to let progress of D3D11 rendersystem go on smoothly; which is why I assigned it to 2.0

[Sqeaky]

start off with a thread for each feature or task so we can have some great, distinct discussions. For example: Threading, RenderSystem design and changes, SceneManager, RTSS, etc.

I made a new thread for threading... I feel like I need an xzibit picture that says something witty. I included link to the wiki page and my response to a few things said here.
http://www.ogre3d.org/forums/viewtopic.php?f=25&t=75628

[madmarx]

In the past, with Ogre I rewrote : an exporter (!), a resouce system, a threading system, my own node management ... i did direct calls in the rendersystem to get my own effects working.

sparkprime wrote:What I would propose is doing the work from back to front. First fixing the rendersystem API (...)

I think that your post describes exactly what should be done. And I would add that rewriting is what should really be done.
1/ write a render system encapsulated in C calls (not C++).
2/ maths functions and basic containers.
3/ rebuild on top of that. You know, writing a queue, a node system etc... is not hard. Everything oriented with data representations.

I think it's an error to try to correct the scenemanager/resources system/etc.. as they are now. It will take tons of efforts, while it would be vastly easier to rewrite everything. The only thing is that the team should agree on the structs that contains datas, and then the community provides the fonctions / bodys to use them.

I tried both. My conclusion is : Correcting Ogre is too timing consuming for very little gain. rewriting is easy + it's more motivating compared to the other option. The interfaces just need to be "canon'd" by the team. The community can handle the rest IMO.

From my point of view, the best plan would be : provide a simple render system interface for everyone, and then give a clean priority order for describing the datas necessary to represent everything else. BTW I am not saying that the team is not doing a great job, I think they are great and do a lot. (But I wouldn't mind if Kojack / Tommo / Klaim were to propose something too ).

Question to the team : if a first good shot for data structure is proposed by someone not from the team (ex: Kojack/ Spark / Klaim / Tommo ... sorry for the one i forgot, but I mean someone not completely unrelated to Ogre), how to make it accept as a base for Ogre 2.0 and allows people to work for real on it? What should be the minimum functionality offered by it, so that it would be satisfying as a good base for 2.0 ?

Best regards,

Pierre

[Brocan]

[*]Export integration. So far the biggest complain I get from artists & indie companies is that the export process pipeline sucks. UDK & Unity do this pretty well. There are too many steps involved into getting from 3DS Max/Maya/Blender into the actual game. This is because:

1. It usually involves setting a material file (by hand, using text! artists don't like text!), being careful not to overwrite a previous material file
2. Exporting all the right submeshes; and placing the .mesh folder into the right folder (or setup resources.cfg)
3. Setting up an additional file for the custom game engine to link the GameObject with a given Mesh
4. Getting a preview means doing all the above (+ launching a custom preview tool, Ogre Meshy, or even loading the full game depending on each case). It's a pita if something was wrong and above steps must be followed all over again. Cuts the iteration process

Having that said, most of us don't have the time to work on tools, because tools involve GUI code (many find it boring & frustrating). Making good GUI is an art, and requires a lot of co-developing with artists & designers (after all, those are the users). This forum sadly lacks artists.
It's a chicken and egg problem; we can't make appealing tools because we don't have artists to work with, and we don't have artists because we have no appealing tools.

What about dropping actual mesh/material formats and adopt a "more-standard" format like fbx?

And made somekind of library for tools, that can be easily used for adding the node/material/what-else editor for your engine editor?

[Klaim]

(ex: Kojack/ Spark / Klaim / Tommo ... s

Just to be clear: I don't think I understand part of what dark_sylinc and others are talking about on the multithreading stuffs. To me the whole threading system should be managed outside Ogre or even not mentioned by Ogre at all as sparkprime suggested (if my memory is correct). IF Ogre needs to provide a support in multitasking, my current understanding is that Ogre rendering process should be cut in a way that allows client code to organize the rendering in parallel if he wants, in the way he wants, with the tools he wants. Any way to automate this (other than optionally) from ogre itself could cause problem to people using Ogre in not-so-common context.

Now, that makes me feel like a noob which I feel I am on the subject, so don't think my input or work could help.

Maybe on other subjects. I will have to setup my resource management system very soon...

[dark_sylinc]

What about dropping actual mesh/material formats and adopt a "more-standard" format like fbx?

And made somekind of library for tools, that can be easily used for adding the node/material/what-else editor for your engine editor?

No sane engine would choose a format in which the developers have no control of, the specs depend on a 3rd party with interests that may not be aligned to ours, opening the file does not guarantee 100% that the model & animation will look exactly as it looks in the modeling tool..... as a native format.

What we should aim is to an import/export simplification process just like Unity & UDK do. Not adopting a foreign format as our own.

[mkultra333]

Technical details are all well above my pay grade, but as a user I fear the following about a massive, non-incremental rewrite.

They take ages, and if the main few involved lose interest, need to move on for financial or other reasons, or get hit by a meteor, then it's very hard for others to come in and pick up where they left off. So Ogre could simply die.

With a more incremental approach, improvements ready to use come a lot faster, and if there's any turnover in the main movers and shakers it's a lot less devastating.

I can live with an Ogre that isn't absolutely as perfect and fast as it could be, I couldn't live with a half-written super-fast Ogre that is never completed.

[Brocan]

What about dropping actual mesh/material formats and adopt a "more-standard" format like fbx?

And made somekind of library for tools, that can be easily used for adding the node/material/what-else editor for your engine editor?

What we should aim is to an import/export simplification process just like Unity & UDK do. Not adopting a foreign format as our own.

I understand your point of view, but for example Unity has direct FBX import, which simplifies a lot the artist pipeline because you have direct integration with a lot of 3D programs and tools.

[Wolfmanfx]

Half written and never finished - its super unrealistic to say that we are faster with a scratch rewrite, we forget the man hours/years in testing and every workaround which is done over the years to make ogre that stable. With a fresh codebase you make the same error/mistakes we think we are much smarter and elegant and then we realize that we forget this edge case and the other on too and the codebase will grow again...
When someone read this thread it sounds that OGRE is unusable (too slow) but the world is not just black and white we are not perfect but who is perfect (and i am talking about opensource)? Its naive to say we did not catch up with AAA engines....they have paychecks and hundred of ppl working on it full time and the codebase of them is also not perfect (i have already worked with a few).

I agree we should refactor the render system interfaces and do a more thread friendly design which process gpu commands like gamebryo does or other engines as well.

Regarding threading - i think the best approach is to tell ogre how many threads it is allowed to use 0 - N or auto and thats it so the user can control how much is spawned. What is the benefit to make this also plug-able?

All in all the thread is awesome do not get me wrong and i can not await do begin with the planning inside jira.

[Wolfmanfx]

No unity has no direct FBX support - the unity editor has a fbx importer which is a different thing the runtime has not - a thirdparty runtime importer exist for 300$.
I recently wrote an runtime importer for unity for a custom format but it sucked too you can not use it with unity flash because of the sanboxing and stuff like that.

[Brocan]

No unity has no direct FBX support - the unity editor has a fbx importer which is a different thing the runtime has not - a thirdparty runtime importer exist for 300$.
I recently wrote an runtime importer for unity for a custom format but it sucked too you can not use it with unity flash because of the sanboxing and stuff like that.

You are right, but the effect is the same, you can directly use fbx without the need of exporting to unity's internal format.

The problem, as you said, is that the runtime hasn't this feature due to the heavy weight of the libraries that fbx uses, so importing meshes at runtime is quasi-impossible (which sucks).

[Wolfmanfx]

You have to use neoaxis or the another ogre based game engine which comes with this features btw OC3 released an fbx to ogre converter.

[al2950]

I have only just caught up with this topic and I would just like to say thank you to dark_sylinc and anyone else who has had input into the slides and this forum, it has been a very interesting read.

I will soon be adding a few notes about RTSS

[madmarx]

Half written and never finished - its super unrealistic to say that we are faster with a scratch rewrite, we forget the man hours/years in testing and every workaround which is done over the years to make ogre that stable.

Well this is where we disagree . For example, concerning the background loading in ogre, i was pretty sure i would have done better than sinbad from the first go (if i had known the internals), the reason being that i developed such multithreaded appli in pure opengl in 2005. I read many posts reporting bugs on this feature from ogre 1.5 to 1.7, which clearly asserts that to many efforts have been put on that element. Also, to write a "not-as-full feature" graphic engine is quite straigt forward : let's forget about high level (shadows, batching) first, and do it only after the core works. I suspect that most of the tricky code which had been hard to stabilize is in the plateform management. These are my opinions. Now you have a different experience than me which leads you to warn about "the man hours/years in testing and every workaround " that we could lose.

When someone read this thread it sounds that OGRE is unusable (too slow)

. I agree with you; but it is not an attack toward the engine, these are proposition to make it better now that we got better knowledge of what should be done on today's hardware. Given what we know now, it is easier and faster to rewrite than to modify.

The problem IMO is that if someone propose an already working fully rewriten ogre, we don't know if the team will accept to continue with it, or if the team will throw it away without discussion .

[drwbns]

How many of the team members are actually interested in a complete rewrite?

[TheSHEEEP]

I'd be completely against it.
The best file format for any engine is one that is tinkered to its needs. And we already have that.

Though it would be great to have an official importer/converter that can convert from some standard formats into our own. And if we had that we could do it on-the-fly like Unity, etc.
Of course that would come at a performance cost (converting fbx->mesh/skeleton at runtime), but if that would be okay for some projects, why not? It would at least be interesting for artist so they could try out their assets in the engine without having to convert it manually.
But there is nothing we can do here without having some official team members being responsible for pipeline tools.

Hmm.. would such a thing (pipeline tools) be an interesting GSoC project?