Feature request: event-driven scene manager

[CodeGen]

Hello Irrlicht community !
Wouldn't it be nice to make Irrlicht's scene manager event/task driven ?
Currently, the engine renders, transforms, animates scene nodes every frame. But we can raise events when something changes, generate and process new tasks only when it's needed ( much like in OSes ).
For example:

Code: Select all

  void mxSceneNode::SetPosition( const Vec3D& newPosition )
  {
	m_vPosition = newPosition;
	PostEvent( ESceneEvent::EVENT_Traslation_Changed, this );
  }

In the scene manager new tasks are generated for processing events, added to the task list, the list is sorted by the tasks' priorities and their data ( for example, a task can also hold a pointer to a scene node, nodes can keep their previous transforms, hints to the scene graph optimizer, etc. ) and then the task list is executed. ( Many modern engines still use 'mutable bools' for updating. )
Thus we would be able to save a lot of processor cycles. We don't have to make a full-blown task class, a simple 'switch' will do the job:

Code: Select all

  /* ... */
  case ESceneEvent::EVENT_Camera_Moved :
  {
      mxCameraNode * pCameraNode = static_cast< mxCameraNode* >( pNode );
      pCameraNode->RecalculateViewMatrix();
      pNode->SetPosition( pCameraNode->GetView().Position );
  }
  break;
  /* ... */

We can also store a boolean variable m_bSceneHasChanged. It would be assigned the value (m_taskList.Num() > 0). If m_bSceneHasChanged is false, we can skip rendering the frame and so on. Or the scene manager may hold two scene managers: an active one for rendering the frame and another which runs when the system is idle or no user input has been received. And they would be switched:

Code: Select all

  if ( m_taskList.Num() > 0 ) {
     m_pSceneProcessor = & m_pRenderFrameProcessor;
  } else {
     m_pSceneProcessor = & m_pOnIdleProcessor;
  }

( The second 'scene manager' will try to optimize the scene during idle time ).
If the scene doesn't change we will have minimal system load.
Is it a good idea to implement in Irrlicht or not ?
( i'm fairly new to the fascinating field of computer graphics and i know little of the subject. And i like Irrlicht because it's very easy to use (and so it attracts many users) and has a friendly community. And sorry for my english. )

[Dorth]

Actually, that's not a OR scenario. You can have both. I'm sure if you implement such a system and offer patches for it, it'll find it's way in Irr soon enough ^^

[DeM0nFiRe]

Now, maybe I misunderstand what you want, but I don't see where the point to something like this would be in a game engine. I mean, I suppose you can use it to make it so that if the scene didn't change at all then don't bother redrawing, but other than that if anything changes you have to redraw the scene. Maybe if one scene node changes just redraw that scene node and the ones behind it, I guess. The problem is, though, that in a game, how often are you going to need that to happen? Chances are you need a lot of stuff to be moving all the time. It sounds to me like it would be a lot of work for a small gain. OSes use the sort of system because there is a crapload of things that OSes do that don't always need to be done. Even 2D games could benefit from this more, because it's a lot easier to determine precisely which pixels need to be redrawn each frame, and in fact in the early days it was only that fact that let 2D games be played on PCs. (Dangerous Dave in Copyright Infringement anyone? XD)

EDIT: Oh yeah, and the other problem is that doing that would not change just the scene manager, because it is the video driver that decides to erase the entire screen before every frame.

[CodeGen]

Yes, you're right, in games scenes usually change every frame. i just wanted to say that we could avoid doing unnecessary work. If a scene node 'changes' how would we know about that ? Currently, we traverse and update the entire hierarchy, calculate visibility, store some info in scene nodes, and we do that every frame. That simple brute force may not work well for large scenes ( wasted processing power, cache misses -> low FPS ). And if some scene node 'changes' and we don't want to draw scene nodes occluded by it, we will most probably need to refit our data structures and we should update only those parts that have changed ( e.g. a moving object crossing boundaries of a cell of our scene partitioning data structure raises 'update' events which (along with the line segment, etc.) are passed to our scene database; maybe, in the future, there'll be 'trigger' scene nodes, ... ). We can cache visibility information in camera nodes and update that intelligently. It's the scene manager that should optimize the scene for rendering and less overdraw. And as far as i know we erase the screen by calling 'IVideoDriver::beginScene' directly in our application.
IMHO, event-driven systems are more effective than ones based on polling, especially, for processing large scenes. i've implemented a simple event-driven scene manager and the results are encouraging.
Oh, yes, those new crappy bloated OSes do crapload of needless work.
Anyway, thanks for reply, DeM0nFiRe. Creative criticism is always welcome.

[roxaz]

then each object should save it's drawn appearance into a separate buffer in order for it to be used in final frame composition right? what if there are lots of objects? for 1024x768 resolution single buffer would be over 3 megs (4bpp). it would add up soon.
but this will not work due to simple fact that camera angle changes too often. think about it - if camera moves objects around it are perceived from different position thus they look a little bit differently - means whole scene requires a redraw.

event driven systems are cool but in this case it would just complicate code without providing anything useful. only static scenes would really yield notable performance gains. faster way to achieve this is to pause rendering altogether ^_^

[CodeGen]

yes, you're absolutely right!

back then i was just starting to learn CG and, due to my incompetence, became fascinated by the idea of universal, mega-city one scene graphs, fancy update strategies, dynamic algorithm selection, etc.
so, what i wrote is typical C++ bull$hit !

code must be simple, purposeful and clean.

i'm sorry for wasting other people's time.