Animators as entity components

[CondeNostaw]

I'm trying to use animators as components and nodes as entities, to perform some sort of component-based programming in Irrlicht.

That would be possible if the animators were able to communicate to each other. I'm trying to use the event system so animators can send messages to each other, unsuccesfully so far.

Posting events with ISceneManager::postEventFromUser does not seem to have any effect at all. I have tried to post UserEvents and my own SEvent derived structs.

What I want, precisely, is that: animator A sends messages and animator B receives them if they are both attached to node N. If animator B is not attached to N then the message is simply not received, no collateral damages.

[CuteAlien]

This sounds like you are using own animators (as the current animators obviously don't have functionality for this). In this case you can also use an own event-system. Trying to use the Irrlicht event system for this doesn't look wrong to me (I don't think it was designed for component communication, but rather to mainly pass on system events fast).

[CondeNostaw]

This sounds like you are using own animators

Yes.

In this case you can also use an own event-system.

If Irrlicht has a built-in perfectly functional event system, why should I reinvent the wheel?

I don't think it was designed for component communication, but rather to mainly pass on system events fast

So, when is SUserEvent struct supposed to be used?

[CuteAlien]

I don't know - originally you wouldn't even have been able to pass a struct derived from SEvent, I just realized now that this is possible now since we switched to references.

I can also only guess based on what I see how the event-system works. What I can tell you is that postEventFromUser will be passed on to animators of the active camera if the camera is set to receiving events. It's not passed around every scenenode and I don't think this should be changed as the event system is there to handle events fast and this could cause a serious slowdown.

For passing events between any entities/components you will probably be better of using an event-system where objects can register which events they want to receive.

edit: Note that it would be easy to pass on events also to all scenenode-animators yourself if you really want that. Use a function to go through all scenenodes, go for each scenenode through all it's animators can call OnEvent for each one.
edit2: I also don't really know the idea behind passing events at all to the active camera. This looks rather strange to me and if I'd have to guess I then I'd say it was mostly to keep using camera-animators simple.

[CondeNostaw]

Ok, so I think Irrlicht is only one step of being a complete component-based engine. All it needs is to allow animators to communicate using events.

Let me write this as a feature suggestion:

- There must be some sort of "SAnimatorEvent" struct to handle animator events. It must have a message identifier and a generic attribute to contain the message body (void * ? string ?)
- The animator posts its event to its parent.
- When a node receives a SAnimatorEvent, it re-sends the message to all of its animators and child nodes. Its child nodes will do the same.
- The users of Irrlicht will write their own animators and attach them to nodes to create Entities.

What do you Irrlicht development guys think?

[serengeor]

Ok, so I think Irrlicht is only one step of being a complete component-based engine. All it needs is to allow animators to communicate using events.

Let me write this as a feature suggestion:

- There must be some sort of "SAnimatorEvent" struct to handle animator events. It must have a message identifier and a generic attribute to contain the message body (void * ? string ?)
- The animator posts its event to its parent.
- When a node receives a SAnimatorEvent, it re-sends the message to all of its animators and child nodes. Its child nodes will do the same.
- The users of Irrlicht will write their own animators and attach them to nodes to create Entities.

What do you Irrlicht development guys think?

My opinion about this would be that irrlicht should be nothing more/less than a flexible and easy to inteface rendering engine, any game/app logic should be written by the game/app developers.

If you really need this you may write it yourself, irrlicht is open source you know

[Xaryl]

What do you Irrlicht development guys think?

I am not an "Irrlicht development guy", or even close to being an expert of Irrlicht but here are my two pennies:

I also don't really know the idea behind passing events at all to the active camera. This looks rather strange to me and if I'd have to guess I then I'd say it was mostly to keep using camera-animators simple.

I traced the calls around and it really indeed only pass the events to the camera's animators oO
But that makes sense, because some scenes can contain huge amounts of nodes and passing events to every node is not a good idea.
There is also another use of that animator I guess, you can attach your scene related event receiver there, and the input events won't reach there if absorbed by GUI.

What I want, precisely, is that: animator A sends messages and animator B receives them if they are both attached to node N. If animator B is not attached to N then the message is simply not received, no collateral damages.

How about passing your event to everyone (besides self) in

Code: Select all

AttachedNode->getAnimators();

Of course, you will have to keep the track of which node the Animator belongs to or do that in the animateNode call.

- There must be some sort of "SAnimatorEvent" struct to handle animator events.

There is UserEvent for extension.

[CuteAlien]

I'm still working on an event system for components with which I'm happy in an own project. Maybe once I manage getting this working well enough I can think about adding something to Irrlicht, but I'm not there yet (with working well I mean - used extensively in a project without me wanting to rewrite it anymore).

Architecture ideas are always very welcome, especially when they are for stuff people already coded and found useful. It's rather easy to get into the Irrlicht code and try out own patches there, so maybe just experiment with it yourself a little bit.

But there's also other solutions which can be done without changing Irrlicht at all. As mentioned you can call OnEvent and so nothing really stops you from sending events directly to animators. You have to solve the same problem - how to identify to whom you send those events as you probably don't want the whole scene to listen. Which means either animators register themselves for certain events or you have some way to identify the correct event-receiver(s) (depends on what you want to do).