Ogre Forums

[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

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.

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

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.

So, it seems like we are getting more for our money with backward compatibility?

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

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.

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...

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.

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?

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.

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.

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

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 ..
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.

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.

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.

Haha, okay okay pals, don't hit me! 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

I just wonder what soon means in the standards world. 5 years? 10 years until adoption by standards implementors?

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.

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.

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?

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.

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.

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.

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?