Ogre Framework for practically starting projects

Discussion area about developing with Ogre-Next (2.1, 2.2 and beyond)


Post Reply
Dugi
Halfling
Posts: 46
Joined: Tue Jul 23, 2013 2:37 pm
x 7

Ogre Framework for practically starting projects

Post by Dugi »

While the old Ogre has Advanced Ogre Framework, a useful piece of code to start things up and eventually start changing the way Ogre is started when the user gains sufficient skill at Ogre. Ogre 2.1 doesn't.

So I decided to create one for Ogre 2.1. It has less features than Advanced Ogre Framework, basically just a loading screen and it goes right to rendering, because I found those menus of Advanced Ogre Framework nothing but annoying. It sets up a lot of stuff:
  • Ogre
  • CEGUI (for GUI)
  • SDL2 (window management and input)
  • Ogre's and CEGUI's resource groups
  • CEGUI's TaharezLook
  • HLMS
  • HDR
  • Shader cache
  • Input, injection from SDL2 to CEGUI
  • A basic scene with camera moved by user input
  • Examples for handling input
The minimalistic list of implemented features:
  • A loading screen
  • A scene with one object and camera man controlled by W+A+D+S buttons and moving mouse while the right button is held (to see if rendering is right)
  • Trays showing framerate and camera position (easy to extend)
  • An on screen debugging feed that shows anything written into a stream (every line stays there for 3 seconds unless it's filled up)
Its class structure is not the best, it has GraphicSystem, a class to set up graphics and rendering, Controller, a class to manage user input, UI, a class to handle the GUI and Application, the first file to be edited by the user. It does not follow OOP standards very well because these classes depend on each other a bit too much.

Here is a download link. I will make a github repository from it if it shows up to be useful.
https://drive.google.com/file/d/1gzg2tL ... sp=sharing
Last edited by Dugi on Thu Nov 09, 2017 5:53 pm, edited 1 time in total.
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: Ogre Framework for practically starting projects

Post by xrgo »

fantastic!!!!!!
thank you so much, many will find this very useful
123iamking
Gremlin
Posts: 152
Joined: Sat Aug 12, 2017 4:16 pm
x 4

Re: Ogre Framework for practically starting projects

Post by 123iamking »

Thank Dugi. I see that you are using Linux. But CEGUI currently doesn't work with Ogre 2.1 DirectX, so this framework currently doesn't support for Windows, right?
Dugi
Halfling
Posts: 46
Joined: Tue Jul 23, 2013 2:37 pm
x 7

Re: Ogre Framework for practically starting projects

Post by Dugi »

123iamking wrote: Fri Nov 10, 2017 4:17 am Thank Dugi. I see that you are using Linux. But CEGUI currently doesn't work with Ogre 2.1 DirectX, so this framework currently doesn't support for Windows, right?
I didn't know it doesn't work with DirectX. But you may use OpenGL on Windows (and you should use it if you don't want to make the program Windows-only), so Windows shouldn't be a blocker.

Because I am not familiar with other GUIs that work with Ogre, I can only hope the guy who updates CEGUI for Ogre will fix it.
crancran
Greenskin
Posts: 138
Joined: Wed May 05, 2010 3:36 pm
x 6

Re: Ogre Framework for practically starting projects

Post by crancran »

Overall great work, although I do have one suggestion.

I would consider removing the singleton pattern you're using in the code and instead use constructor dependency injection. Your Application class would have pointers to the GraphicsSystem, UI, Controller, and other objects. Should you run into some chicken-v-egg problem using constructor dependency injection, then you know you have some bad coupling between classes and you should fix it. This would also allow you to move a lot of the code you have in main() into Application too.

The main reason for this would allow any other developer to then simply create their own Application implementation that inherits your Application class and their main would then simply be something simple as:

Code: Select all

try 
{
  MyApplication* my_app = new MyApplication();
  int result = my_app->run();
  delete my_app;
  return result;
}
catch( std::exception& e ) 
{
  // do stuff
}
Either way you go, still good to see this put together for others.
Dugi
Halfling
Posts: 46
Joined: Tue Jul 23, 2013 2:37 pm
x 7

Re: Ogre Framework for practically starting projects

Post by Dugi »

crancran wrote:I would consider removing the singleton pattern you're using in the code and instead use constructor dependency injection.
I have written myself that its class structure isn't the best.

However, Application owning it all is against the basic idea. I wanted the programmer (who is clueless about most Ogre things) to be able to start editing Application or his own experiments and look into other parts later. Therefore Application only has code that deals with the scene itself.

I have used the singletons for Controller, GraphicSystem and UI because singletons are available everywhere but references to these classes would have to be passed everywhere, making constructor calls annoyingly long.

It would be structurally better if Application registered some callbacks at Controller and UI and these didn't have to be its friends, but that would, again, put more code into Application. That's why I kept it outside of it. Good idea to make the user edit something that inherits from Application, it would keep clean the code the user manipulates and make Application bear all the code it needs.

I'll edit it soon. I could also add a swtich to remove CEGUI for those who can't have it.
crancran
Greenskin
Posts: 138
Joined: Wed May 05, 2010 3:36 pm
x 6

Re: Ogre Framework for practically starting projects

Post by crancran »

Dugi wrote: Sat Nov 25, 2017 1:51 pm However, Application owning it all is against the basic idea. I wanted the programmer (who is clueless about most Ogre things) to be able to start editing Application or his own experiments and look into other parts later. Therefore Application only has code that deals with the scene itself.
I don't see why that should dictate the use of a specific pattern, but ok.
Dugi wrote: Sat Nov 25, 2017 1:51 pm I have used the singletons for Controller, GraphicSystem and UI because singletons are available everywhere but references to these classes would have to be passed everywhere, making constructor calls annoyingly long.
I get that, but constructor injection is a way to clearly define dependencies between objects rather than blindly having some relationship that is hidden in the implementation file using the singleton pattern. Additionally, constructors that get "annoying long" is a clear indicator that your class hierarchy is either flawed or your class is doing too much to require so many dependencies.
Dugi wrote: Sat Nov 25, 2017 1:51 pm It would be structurally better if Application registered some callbacks at Controller and UI and these didn't have to be its friends, but that would, again, put more code into Application. That's why I kept it outside of it. Good idea to make the user edit something that inherits from Application, it would keep clean the code the user manipulates and make Application bear all the code it needs.
The application class by very definition is the glue class here. I wouldn't fear this class having a variety of code placed in it to allow for all the various subsystems to coexist and interact according to some well defined pattern. Since a user would extend Application anyway, it would make sense that you would have a variety of virtual methods that the extended class can override with custom behavior and be able to access a variety of systems through either a protected variable or method as needed.

Code: Select all

struct ApplicationLifecycle {
  virtual ~ApplicationLifecycle() {}
  virtual void OnSetup() {}
  virtual void OnStart() {}
  virtual void OnStop() {}
  virtual void OnUpdate(float deltaTime);
}

class Application : public ApplicationLifecycle {
  // inherits the virtual methods from above
}

class MyApplication : public Application
{
public:
  void OnSetup() override {
    //! This is before OGRE has created the render window, so we can source these from some special logic.
    renderer_->SetWindowWidth( config.windowWidth_ );
    renderer_->SetWindowHeight( config.windowHeight_ );
  }
  void OnStart() override {
    //! This is called right before the main loop but all systems are initialized.
    //! I might want to register some listener callback to a specific system or something
  }
}
Anyway, you get the idea.
Dugi
Halfling
Posts: 46
Joined: Tue Jul 23, 2013 2:37 pm
x 7

Re: Ogre Framework for practically starting projects

Post by Dugi »

I understand what you mean here, but from my experience, not using the singleton pattern for things that exist only once leads to a load of additional parametres to constructors and larger classes. As long as the singletons have proper encapsulation, there's no additional risk of breaking something. If the program had just the classes I have uploaded, constructor injection would indeed be better. But there will not be only the Application class, there will be a load of other classes for various objects in the scene with different properties and purposes, all of which would need to access to SceneManager, UI and such.
crancran wrote:I get that, but constructor injection is a way to clearly define dependencies between objects rather than blindly having some relationship that is hidden in the implementation file using the singleton pattern.
There's little interdependence between 3D graphics, UI and input. I don't think there's a reason to have these three depend on each other in some well-defined way. Of course, they need to be initialised in the right order and input injects keystrokes into the UI, but that part isn't going to be edited much.
crancran
Greenskin
Posts: 138
Joined: Wed May 05, 2010 3:36 pm
x 6

Re: Ogre Framework for practically starting projects

Post by crancran »

Dugi wrote: Tue Nov 28, 2017 2:39 pm I understand what you mean here, but from my experience, not using the singleton pattern for things that exist only once leads to a load of additional parametres to constructors and larger classes. As long as the singletons have proper encapsulation, there's no additional risk of breaking something. If the program had just the classes I have uploaded, constructor injection would indeed be better. But there will not be only the Application class, there will be a load of other classes for various objects in the scene with different properties and purposes, all of which would need to access to SceneManager, UI and such.
I'd argue for a very simple project, the singleton pattern is fine if that is what you want to use.

But my concerns run deeper than just encapsulation. I've been in the industry for years and its quite typical that a newcomer finds some framework or sample and immediately begins writing their own code following the same style that the framework or sample used. In other words it propagates bad habits.

Yes, there are perfect scenarios for singletons. But I always like to caution developers of their use because what you might view as something you only need once in your application may not hold true for all use cases.
Dugi wrote: Tue Nov 28, 2017 2:39 pmThere's little interdependence between 3D graphics, UI and input. I don't think there's a reason to have these three depend on each other in some well-defined way. Of course, they need to be initialised in the right order and input injects keystrokes into the UI, but that part isn't going to be edited much.
But the fact they have a construction order that should be followed implies there is a certain level of coupling between them, e.g. inter-dependence. And if you properly define constructor injection, you explicitly enforce that construction order by virtue of design rather than several lines in an init method with a comment reminding you why these objects have to be created in said order.

Perhaps we can agree to disagree, but I have found after 30+ years in programming, if the code can be self-documenting without verbose comments or having to open implementation files to know the interdependence objects, you can be more productive as an engineer.
Dugi
Halfling
Posts: 46
Joined: Tue Jul 23, 2013 2:37 pm
x 7

Re: Ogre Framework for practically starting projects

Post by Dugi »

Yes, there are perfect scenarios for singletons. But I always like to caution developers of their use because what you might view as something you only need once in your application may not hold true for all use cases.
In this case, using singletons helps remove quite a non-neglectful amount of code. The performance difference is probably neglectful, but writing repetitive extra code is annoying.
But the fact they have a construction order that should be followed implies there is a certain level of coupling between them, e.g. inter-dependence.
I don't deny its advantages, but the advantage of having them all very accessible without passing references to these objects everywhere is also considerable. Singletons trade a slightly worse clarity of initialisation for shorter code in many places.

When I get to fix a few errors I have found there (mouse rotation is somewhat broken), I will publish it on github where it will be editable. If we don't find an agreement, one version can stay as a fork mention in the description of the other.
Post Reply