'Tindalos' (Ogre v2.0) SceneManager redesign

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
Post Reply
Chaster
OGRE Expert User
OGRE Expert User
Posts: 557
Joined: Wed May 05, 2004 3:19 pm
Location: Portland, OR, USA
Contact:

Post by Chaster »

[edit]
I assume there'll be a sample SceneNode model implementation that you'll provide that pretty much matches the current SceneNode implementation, and that others can do something completely different if they wish. Still, there has to be *some* sort of standard way of setting positions and orientations right? Am I missing some part of the design?
[/edit]
I am guessing that the Transform Source plug-in would specify how positions & orientations would be set. I also expect that the "default" (i.e. "sample") transform source would be a 1.x-like SceneNode implementation so as to ease porting from older code, n'est pas?

Chaster
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

Actually no. Yes, SceneNode will still be provided as a default and that's what our demos will use. But the whole point of TransformSource is that it's there to provide an interface to observe external models. Do we know that those are writable from our end? No - setting a position directly from our end may well be completely invalid. Therefore there will be no way of updating the model via TransformSource.

In the MVC framework the View never directly updates the Model, it always has to go via the Controller. What you're asking for is a standardised Controller, which I can't give you without limiting what people can do with their custom applications. You can't even do it abstractly with SceneNode really, since TransformSource is the fully derived transform and thus in a hierarchy you can't say which node would be best to alter if you come at it from the bottom of the tree.

All I can say is that SceneNode will still be there, and I pretty much guarantee that most people will still use it. The ability to point TransformSource at an external model is there for the more advanced users and to be honest, you're never going to be able to satisfy all of those will a simple snap-in, there are just way too many ways they could be updating their model, be it from a server update, from a physics / AI system, or something else.
Chaster
OGRE Expert User
OGRE Expert User
Posts: 557
Joined: Wed May 05, 2004 3:19 pm
Location: Portland, OR, USA
Contact:

Post by Chaster »

sinbad wrote:Actually no. Yes, SceneNode will still be provided as a default and that's what our demos will use. But the whole point of TransformSource is that it's there to provide an interface to observe external models. Do we know that those are writable from our end? No - setting a position directly from our end may well be completely invalid. Therefore there will be no way of updating the model via TransformSource.

In the MVC framework the View never directly updates the Model, it always has to go via the Controller. What you're asking for is a standardised Controller, which I can't give you without limiting what people can do with their custom applications. You can't even do it abstractly with SceneNode really, since TransformSource is the fully derived transform and thus in a hierarchy you can't say which node would be best to alter if you come at it from the bottom of the tree.

All I can say is that SceneNode will still be there, and I pretty much guarantee that most people will still use it. The ability to point TransformSource at an external model is there for the more advanced users and to be honest, you're never going to be able to satisfy all of those will a simple snap-in, there are just way too many ways they could be updating their model, be it from a server update, from a physics / AI system, or something else.
Ah, I see.

Chaster
User avatar
Falagard
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2060
Joined: Thu Feb 26, 2004 12:11 am
Location: Toronto, Canada
x 3
Contact:

Post by Falagard »

In the MVC framework the View never directly updates the Model, it always has to go via the Controller.
Yup, that's what I figured.
All I can say is that SceneNode will still be there, and I pretty much guarantee that most people will still use it. The ability to point TransformSource at an external model is there for the more advanced users and to be honest, you're never going to be able to satisfy all of those will a simple snap-in, there are just way too many ways they could be updating their model
Yup, that's what I figured, and sounds fine.
User avatar
tau
Silver Sponsor
Silver Sponsor
Posts: 413
Joined: Wed Feb 11, 2004 11:44 am
Location: Austin (that's kept wierd :))

Post by tau »

So, it seems like we are getting more for our money with backward compatibility? 8)
User avatar
raicuandi
Gargoyle
Posts: 1092
Joined: Wed Nov 09, 2005 12:56 pm
Location: Adelaide, Australia
Contact:

Post by raicuandi »

I don't think an API-level backward compatibility, not for the advanced usage of SceneNodes at least. But the idea will remain somewhere similar with SceneNodes, so it should be easy to port to 2.0

I was wondering: from what I read so far from Sinbad, at the bottom level (where TransformSource is), Ogre doesn't actually let you define/set positions/orientation etc. ??

Because Ogre doesn't even need to? It just renders the whole bunch, so just needs to read the positions/etc.? (hence TransformSource ?)

But you can set all those positions etc., using higher level stuff, like SceneNode, which extends TransformSource, or your own classes that extend TransformSource, OR just manipulate the data that is read by your TransformSource?

Because if its like that, it seems natural to me...

Just wondering if I got it all right :)
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

Yes, that's right.

I'm certainly going to try to keep as much conceptual API consistency as I can to ease migration, but there will certainly be quite a number of detail-level changes, hence why I wanted to separate it from 1.6.
User avatar
Dr.Source
Gnoblar
Posts: 8
Joined: Tue Apr 10, 2007 1:14 pm
Location: Australia, but usually between the chair and keyboard

Post by Dr.Source »

Just remembered, I wanted to ask you this a long time ago:

Will you change the resource stuff in Ogre 2.0, so that it uses templates, instead of subclassing a dozen times? :) ie: ResourcePtr<Mesh>

I've read in the code that you didn't do that because it wasn't compatible with VC6.0, but you've left that behind some time ago...
May the Source be with you!
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

We plan to replace our own SharedPtr with boost::shared_ptr. Boost will become a dependency in the next major version, it's just too good to avoid any longer.
User avatar
tau
Silver Sponsor
Silver Sponsor
Posts: 413
Joined: Wed Feb 11, 2004 11:44 am
Location: Austin (that's kept wierd :))

Post by tau »

sinbad wrote:We plan to replace our own SharedPtr with boost::shared_ptr. Boost will become a dependency in the next major version, it's just too good to avoid any longer.
Boost adds some complexity as well... Do you think it's safe to add, when some people are thinking of Console or PocketPC port?
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

Boost just needs a decent compiler, and I don't know of any compilers that can't handle it now. A few years ago VC6 and VC7.0 were a problem in some areas but these days even 7.1 use is fairly rapidly reducing.

A few years ago I would have balked, but now there's far less reason to avoid it.
User avatar
tau
Silver Sponsor
Silver Sponsor
Posts: 413
Joined: Wed Feb 11, 2004 11:44 am
Location: Austin (that's kept wierd :))

Post by tau »

sinbad wrote:Boost just needs a decent compiler, and I don't know of any compilers that can't handle it now. A few years ago VC6 and VC7.0 were a problem in some areas but these days even 7.1 use is fairly rapidly reducing.

A few years ago I would have balked, but now there's far less reason to avoid it.
Alright, I was just concerned that boost would add too much complexity and increase binary sizes.
User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 2
Contact:

Post by Kencho »

sinbad wrote:We plan to replace our own SharedPtr with boost::shared_ptr. Boost will become a dependency in the next major version, it's just too good to avoid any longer.
Wouldn't it better to stick to the standards? ;) Shared pointers have been accepted for the next C++ standarisation (which should be pretty soon)
http://www.open-std.org/jtc1/sc22/wg21/ ... n1450.html
Image
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Post by jacmoe »

Kencho wrote:Wouldn't it better to stick to the standards? ;) Shared pointers have been accepted for the next C++ standarisation (which should be pretty soon)
http://www.open-std.org/jtc1/sc22/wg21/ ... n1450.html
Pretty soon .. :lol:
I am also caving in to Boost.
It's just too good to be missed, IMO.

Shared pointers have been accepted for the next C++ standardisation, along with 9 more Boost libraries. (IIRC).

In case you didn't know. :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Post by jacmoe »

I too hate to have to distribute (or force users to get) a shed-load of code (Boost) considerably hugher than my library, but until recently I didn't know about Boost bcp:

http://www.boost.org/tools/bcp/bcp.html
The bcp utility is a tool for extracting subsets of Boost, it's useful for Boost authors who want to distribute their library separately from Boost, and for Boost users who want to distribute a subset of Boost with their application.
If you only use Boost::smart_ptr, you run a Boost bcp extraction and ends up with a tiny fraction in your third_party folder. :wink:
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

Yeah exactly - a great deal of Boost will be in the next C++ standard.

Most of Boost isn't a runtime distribution issue anyway - many of the things we use are template headers only, and things like boost::thread can be easily statically linked- no extra DLLs and the code is not large compared to similar libs. It's more of an issue for source distributions yes, which is what bcp is for.
User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 2
Contact:

Post by Kencho »

Haha, okay okay pals, don't hit me! :lol: Just wanted to ensure you knew that was one of those things in the C++'s to-be-standarised list ;) I've recently had a tough problem with Bison and Flex not following standards and have got very concerned about these things :)
Image
User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3335
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US
x 3
Contact:

Post by Praetor »

I just wonder what soon means in the standards world. 5 years? 10 years until adoption by standards implementors?
uzik
Goblin
Posts: 202
Joined: Sun Feb 25, 2007 1:45 am
Location: USA
x 6
Contact:

Post by uzik »

sinbad wrote:Absolutely. The same goes for so many technologies, like early database systems. I used to talk to grizzled DB techs who would shake their heads when MS released a new version of SQL Server with a 'new' feature, and they'd tell me how they solved that in 1982 on a machine with a hundred-thousandth of the processing power
LOL! Now that's funny. I'm working on a database to read and write
resources in ogre. I put together my list of features and started
looking at technology. I finally settled on what is essentially
the same as what was released in 1979.
---A dream doesn't become reality through magic; it takes sweat, determination and hard work.
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Post by jacmoe »

Praetor wrote:I just wonder what soon means in the standards world. 5 years? 10 years until adoption by standards implementors?
Exactly!
It could be a while - in the mean time I am getting Boost'ed. :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Slan
Halfling
Posts: 49
Joined: Wed Jun 09, 2004 11:13 pm

Post by Slan »

sinbad wrote:We plan to replace our own SharedPtr with boost::shared_ptr. Boost will become a dependency in the next major version, it's just too good to avoid any longer.
Too good to be true... I resisted a couple times posting for a praise to boost, mainly because I didn't want to start a 'religion' war. Anyway, boost has always been an extremely valuable and robust code base particularly helpful for writing frameworks (namely signal/slots - could be used for event-oriented scene graph management system ?).

While I'm at it... I guess some patterns used in Ogre could benefit from a bit of refactoring for better readability (core framework patterns like factory / singleton / delegates). Loki helped me a lot for that. Any views on that Sinbad?
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

Slan wrote:While I'm at it... I guess some patterns used in Ogre could benefit from a bit of refactoring for better readability (core framework patterns like factory / singleton / delegates). Loki helped me a lot for that. Any views on that Sinbad?
Got any specific examples? We're already pretty clear in that regard I thought.
Slan
Halfling
Posts: 49
Joined: Wed Jun 09, 2004 11:13 pm

Post by Slan »

Hmm... Singleton is the first that comes to mind. The implementation from Loki can be customized using traits (MT safety, lifecycle management & creation policy). I know it may not make sense for Ogre except for MT I guess but having a unified service wrapper for an engine helps a lot when you make services cooperate. It may look like syntaxic sugar only at first (Singleton<XXXManager>::instance() instead of XXXManager::getSingleton()) but it helps a lot tracking dependencies between services (physics/collison), creation method (new vs static vs malloc) and destruction order if the Singleton implementation is more flexible. Explicit template instanciation is used to choose the flavour of singleton you want to use, which is then transparently propagated to all user code.

Having an extra lib for Singleton is probably a bad idea. Since I didn't want to add the full dependency, I just added a couple .cpp / .h files from Loki in my projects.

Callbacks (delegates / boost::signal / boost::bind) are probably worth investigating too. At least this is an abstraction I wanted unified in my engine : those needs are already expressed in CEGUI (they basically tailored boost::bind to their need IIRC).

Concerning the factory pattern (MovableObject, SceneManager...), I'm wondering if a refactoring could bring some benefits too wrt using meta-data and dynamic loading / discovery. That may remain an open question if nobody comes with a clear use case. Factories for higher-level objects in an engine (game component / game entities) might benefit from a bit of refactored framework, but I would stay away from over-engineering at this point...

Sorry for going a bit off-topic, but seeing the event-driven approach you suggest (and beeing a great supporter for that), I'm throwing my .2€ ideas for a strong component/patterns base.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

Yes, Loki has lots of ways to customise the traits in things like Singletons but really that's only useful in a 'pattern library' - in the main library you'd have to instantiate those patterns anyway and they'd look just like we have now. If we had a variety of usages it would be worth it, but we don't so the simpler single-trait set patterns are simpler to understand.

Yeah, I already mentioned boost::bind earlier.

Factories are really quite basic to implement and I can't see any practical benefit from generalising them any further really.

So I can sort of see your point in theory, but in practice I can't think of a deserving instance of applying it. ;)
beaugard
OGRE Contributor
OGRE Contributor
Posts: 265
Joined: Sun Mar 25, 2007 1:48 pm
x 2

Post by beaugard »

I would consider replacing the Ogre singleton with something like Lokis singleton worthy. Just keep "Ogre behaviour" as the default parameters, so that unsuspecting users do not break anything... The reasons would be making it easier to change compile-time options for multi threading and memory managment - maybe not today, maybe not tomorrow, but some day :)

Also, it would make less people using Ogre have to implement their own specialized Singletons.

Whether the benefits outweigh the time investment for replacing the current implementation? Not sure... what's the time investment?
Post Reply