Common issue. Custom animators & scene nodes

[hokan]

Hello everyone, hope it's right partition.

Googling around, I still can't find proper answer where exactly should I use custom nodes.
Idea:
I successfully implemented RPG(TPS)-camera attached to my character-joint-node (currently using .X models). Camera got all messages from global EventReceiver (and it move character as well), but when I took a look on some articles about loading custom nodes (and animators) from *.irr files, it seemed that I was needed my own factories for scene nodes so as for animators (for successful loading in future). It was done, but I got another problem coding animator (refactoring RPG-camera code) from cameraFPS-source (1.5v) example.
Animator (in example) attached to camera-type node, it's pretty well and it coordinates all camera-stuff (zooming & rotating around model), but it won't be good if camera-animator move character too, so it seemed that I need custom scene node (don't want to burden global EventReceiver), but it doesn't support IEventReceiver interface.
So I stuck - I want animator work only with camera (camera->addAnimator(RPGCam); with attaching it to some BoneNode with camera->addParent(Node->addJointNode("Node_name")) call), but also want character moving (using its own EventReceiver) & cooperating with camera animator (character must fade when camera close enough).
Should I just implement own class (not custom scene node) with deriving IEventReceiver interface & with pointer to my camera & Irrlicht will dispatch all keyborad/mouse events by itself (& I won't have any troubles in future saving/loading *.irr files) OR should I implement own scene node with same features?

P.S
And how exactly Irrlicht will catch my non-registered (if I implement not scene node) class to dispatch events?

// oh, so many brackets!

[CuteAlien]

It's obvious you run into a lot of problems, but I'm sorry to say that I'm not really understanding which concrete questions you have.

One problem seems to be about .irr files and I can't help much there (I'm using my own custom xml-formats).

The next problem seems to be about that the eventreceiver has events for moving the camera and the scenenode for your character. My solution is usually that one knows the other, so either the camera animator can pass info to the character or other way round. Or sometimes I have one class above both and that gives the necessary control information to the camera-animator and the character. So my camera-animator has for example funcions like rotate, and the player class functions like move/slide. And a controller class get's all the input (for example from an IEventReceiver, although in reality I usually have that even more abstracted) and then decided which functions for the camera-animator and player object to call.

I generally avoid deriving own scenenodes and rather write classes which have pointers to scenenodes. So my player class for example might simply be class Player not derived from anything. And then it has an ISceneNode for the player object in the scene. I only create own scenenodes when they have special functionality in the 3d scene - for example drawing a 3d cursor, or a grid - stuff that's not yet in Irrlicht and which I need.

I hope that helped at least a little...

[hokan]

Thanks, CuteAlien for reply about using custom scene nodes.
But I still wondering can I use several "layers" of EventReceivers same time?
Animators derive IEventReceiver interface so it's easy to implement own dispatcher (OnEvent method) inside them, but I can't do similar trick for other classes. Irrlich simply don't see my implementation. Searching around I came to idea that Irrlicht can only manipulate _one_ user-EvenReceicer which can be set with device->setEventReceiver(&receiver) call or in constructor. So the way I can manipulate multiple EventReceivers (or single in many classes) is to write one common class derived from IEventRec. (like MastEventReceiver by Mastiff) and, as you mentioned, pass pointer to it in every class where I want to use it. And perhaps, write some ReceiverManager if I want to use multiple receivers.
Is there another simpler way?

[CuteAlien]

Yeah, just pass it on in your event-receiver, for example like in the code here: http://irrlicht.sourceforge.net/forum// ... highlight=

[hokan]

Side question, if you don't mind:

When I move character straight forward, permanently on _totally_ plain terrain, I get some artifacts - it can stuck for a moment (less than a 0.1 sec.) and than move correctly. Is it a bug or should I double check my terrain high-map or character model?

[CuteAlien]

Sounds like a bug to me, but hard to tell without testcase.

[hokan]

Returning to animators.

Is there a way to check if animator was successfully inits (in animateNode function)? Other than enumerating all animators and search for one specific.
I mean situations when, for ex., camera animator has been attached to non-camera node or some parameters in constructor are incorrect.

[CuteAlien]

No, it's expected that it's correctly initialized.

[hokan]

Playing with Tutotial #8, face problem - buttons with size more than 16x16 pix. (images) doesn't fit toolbar space, so they sliced a bit. What can be wrong?
In Irr-source there are no limitations about size.

[CuteAlien]

Maybe that's the size. Does not take a size-parameter on creation - I'll have to check that.

[CuteAlien]

I've split the thread and moved your other report to here: http://irrlicht.sourceforge.net/forum/v ... =7&t=47960
It's harder to keep track of different problems for us if they are all hidden within one thread, so it's always better to create one thread per problem.

[hokan]

Thanks, thought that it's not necessary & just mine little error.

Double check bug with plain terrain with other model and various values of ellipsoid radius & ellipsoid translation - still wrong, should I make new thread in "Bug report" partition about this?

[CuteAlien]

Depends - is this another problem or something that belongs to the terrain-texture problem?

[hokan]

Another, but I'll check once more, finding too many bugs, suspicious )

Don't mind for some side Q here? Forum filled with threads of two-three posts.

Is it possible quick texturing terrain with brushes not only with shader teq., and what will be more efficient, shaders or pixel-changing by lock()/unlock() functions?
Not complaining, but I spend a lot time googling around, and still best answer is to write pixel shader and blend textures in it (based on alpha/red/etc. mask channel). Not tried, but articles said it works, exampling only static rendering, without real-time brush-modifying.
So second question (quite stupid) is - can it be done with brushes and in real time?

[CuteAlien]

Hm, I'm the wrong guy to answer this (didn't do that stuff yet) :-(