). It does allow the community to offer solutions for others as well then like boost or their own implementations like the paradise engines micro threading
+1Kojack wrote:The main problems are that the math classes all use _OgreExport so they think they are a DLL, and they all include ogrestableheaders.h which then includes movableobjects and zip files and resources and other stuff that's definitely not needed. Fix those two things and the math code is easy to insert into another project or build as a lib.
Many major changes are planned for 2.0. But to get there, we need to divide these changes up into smaller tasks. Some of these tasks will be targeted for 1.9. If this means API-breaking changes in 1.9, then this must to be done in the name of progress towards 2.0.Blader wrote:I think it would make more sense to only add features for 1.9 then break compatibility in 2.0 with the cleanup \ redesign compared to breaking compatibility between 1.8 to 1.9.
Controversial statement. I think singletons are sometimes bad, and sometimes good depending on the characteristics of the code. But lets avoid restarting the singleton holy war in this thread.Blader wrote:Ogre does seem to over-use singletons which is always a sign of bad software design
Disagree. Threading is key for:Blader wrote:On the topic of multi-threading Ogre should not be doing it's multi-threading itself, it should be multi-thread friendly as to allow a person using it to multi-thread with whatever they feel like.
+1 to all points!Jabberwocky wrote:Thanks for that CABAListic.
That explains in better detail why threading in the core is absolutely necessary. You can't have a modern, high performance renderer without it.
I agree we should keep the threading details abstracted ("threading strategy"), so advanced users can tailor it as they see fit. Hopefully that works for Mako_energy & Blader, although continued discussion is more than welcome.
Sure, I can agree with that. I guess the real question is whether Ogre should just be a pure render engine, without any of the support systems you generally need to render stuff. Taking the example of resource loading. Agreed, that's not pure rendering functionality. But without it, the audience for Ogre would be vastly diminished to people who are both interested and capable of writing a lot of low level engine code. Not that Ogre is a full game engine, but it does give you everything you need to handle getting graphics on screen.Mako_energy wrote:I also feel the need to state that I disagree with your word choice of "could conceivably be", where it should be "absolutely are". A "pure" render engine should just render. There are a lot of hobbyists and students out there, and for them providing as many built in tools as possible is an amazing thing. I know it was for me when I started with Ogre. But as I go deeper I find it cumbersome and annoying, as I have to account for Ogre's design in integrating it with other systems.
I'll go into a little bit more detail for my plans, I don't know what others want to do so I can't speak for them much.CABAListic wrote:The goal of threading is to parallelise the inner Ogre loop. There is no way whatsoever to do that in an optional component/plugin as this is as core as it gets. But it doesn't mean we have to tie Ogre to its own threading system.
In practice, what I believe would happen is that Ogre's scene update gathers necessary updates and arranges them in some kind of microtasks. This is basically the core part of the threading change and would not be optional. What can be modular, however, is the strategy to execute those microtasks. The trivial strategy just executes them one after the other, not using any multithreading at all. The standard threading strategy for Ogre would manage a pool of threads and distribute the tasks to the pool. And if you want, you can write your own strategy to have Ogre use your own threading system, but you'll have to ensure that your other threading stuff does not block Ogre's microtasks.
Is that agreeable?
Whoa. Hadn't realized you were even considering giving an ax to the WorkQueue. I agree with your instincts, and I like the standing plans for the threading re-factor.CABAListic wrote:Disregard the WorkQueue, I am fairly certain that it isn't suited to microtasking and therefore will probably not survive the threading change.
As for possible candidates for tasks, I can't say right now. I think that's part of the analysis that has yet to be done and is imo too specific for this thread. But the ones you mentioned are probably the prime candidates, and my instincts tell me that they will not (always) be completely independent.
No apology needed.Jabberwocky wrote:Hey Blader -
I appreciate you're here sharing your opinion.
Apologies for disagreeing with most of it.
I don't really get that if it is .Major what is the X. part SuperMajor? Maybe you could clarify that for me. I do think that is potentially a negative for Ogre in some aspects, such as if I were to try and pitch Ogre to my director and included in my report that Ogre may, at any major(minor?) release, break all code associated with it forcing a re-write to catch up to the latest features, they would probably decline it. But that is potentially something for the Ogre team to consider in the future.Jabberwocky wrote: Many major changes are planned for 2.0. But to get there, we need to divide these changes up into smaller tasks. Some of these tasks will be targeted for 1.9. If this means API-breaking changes in 1.9, then this must to be done in the name of progress towards 2.0.
The convension with Ogre has been that API changes are acceptable in new major releases, which 1.9 counts as. It may still work out that the majority of API changes won't occur until 2.0, but I don't think we can proceed with that as a requirement.
Well, it isn't really controversial. I agree that there may be uses for Singletons, however nothing that can't be done another, nicer way. The problem with the Singleton design in Ogre is that "All of everything' is accessible everywhere, which helps propagate that same thinking and design.Jabberwocky wrote:Controversial statement. I think singletons are sometimes bad, and sometimes good depending on the characteristics of the code. But lets avoid restarting the singleton holy war in this thread.
Yes I agree, but the way CABalistic mentioned is almost exactly what I meant, that is most assuredly agreeable.Jabberwocky wrote: Disagree. Threading is key for:
1- high graphics performance
2- background loading to avoid graphics hitches and stuttering
3- smooth paging of large worlds
While (2) and (3) could conceivably be considered outside the scope of a pure rendering engine, in practical situations most users who need these features would want Ogre to provide it. You shouldn't need to write your own threading code (a highly expert topic) to achieve good graphics performance from ogre.
If they are optional components they could potentially be maintained separately to Ogre then right? Although yes you are right, it is most definitely good for the Ogre ecosystem to provide these things already for basic users. One way to do this would well for everyone would be to use branches to maximum effect, letting someone choose between the RenderOnly branch or the OgreFull branch. Something to that effect would be pretty awesome in my opinion.Jabberwocky wrote:I do understand that some people will want more or less functionality out of Ogre. It's understandable some users will want to write their own resource manager or threading code. Wherever possible, this should be addressed by moving things into optional components or compile options, not by yanking it out alltogether.
- I mean "additional parallelisation potential for the Ogre core" which should be transparent for the user.