[Interest] [Qt3D] Camera controller
Sean Harmer
sh at theharmers.co.uk
Wed Dec 9 11:22:49 CET 2015
Hi,
On Wednesday 09 Dec 2015 08:54:58 Nye wrote:
> Hello Sean,
>
> So I've implemented my simple camera controller. Before going into the
> detailed text, here is how I set it up:
> http://codepad.org/mXiL5Rs7
> and then what I do in the controller itself:
> http://codepad.org/9oARCaOv
>
> The code is for testing, so please try to tolerate the stupid variable
> names. Also, any comments, especially if I'm doing something wrongly, are
> appreciated.
>
> Now I'll go into the details of my experience:
> Firstly, I'd like to note the responsiveness is somewhat poor (possibly
> because I'm not using the onFrameUpdate part of the QML), maybe the problem
> originates from all that string comparisons or maybe because Qt is
> struggling to handle the amount signal-slot invocations, I'm not quite
> sure. This I believe is a serious problem, which should be addressed
> somehow. (As a side note: I'd like to use Qt3D for a game, so this is quite
> important for me).
Hmm the QML version works fine for me. I'll try a C++ app similar to yours. It
may well be the lack of delta t causing it.
> As a second note, the initialization and device mapping is quite cumbersome
> to do, but this is not a real dealbraker, because can be wrapped nicely in
> the user's class. One thing that I was wondering about is why it was
> decided to pass the actions triggered by their name, is this because QML
> support is needed? As I see it, maybe it's better to directly emit a
> started()/finished() signal for the QAction object?
Right, this is mainly for QML API. We probably should add the signals directly
to the actions/axes for C++ uses to make that less cumbersome.
> Thirdly, if I want to setup some key combination (for example camera
> rotation by left AND right mouse buttons) for operating on a given entity,
> I'd need to put quite a lot of code to handle each of the actions
> separately and then depending on my controller's internal state decide
> whether or not I should rotate/manipulate the entity. Maybe it's a good
> idea to think about the function of the action object. The ActionInput
> abstraction I very much like, but maybe an action should be triggered if
> all the inputs are in the provided state - this would abstract the
> button/axis mapping more cleanly I believe. In QML it probably would look
> like this:
>
> LogicalDevice { // Maybe rename to InputController/InputAdapter?
> id: cameraControlDevice
> actions: [
> Action {
> name: "RotateX"
>
> inputs: [
> ActionInput {
> sourceDevice: mouseSourceDevice
> key: MouseController.Left
> },
>
> ActionInput {
> sourceDevice: mouseSourceDevice
> keys: MouseController.Right
> },
>
> AxisInput {
> sourceDevice: mouseSourceDevice
> axis: MouseController.X
> }
> ]
>
> // Some code (signal/slot w/e) when the action is triggered -
> triggered when all the ActionInput-s are set?
> }
> ]
> }
This is the Chords feature I mentioned in my earlier email. At the moment any
of the ActionInputs trigger the containing action to be fired. I'm planning on
adding InputChord and InputSequence types (names pending) that allow to
specify either a combination of ActionInputs or a sequence of ActionInputs
within a specified time period are needed to fire the containing Action.
This is kind of analogous to the ParallelAnimation/SequentialAnimation feature
in Qt Quick. So it would look something like this:
LogicalDevice {
id: gamepadLogicalDevice
actions: [
Action {
name: "fire"
inputs: [ // Require any of the ActionInputs to trigger
ActionInput {
sourceDevice: ps3SourceDevice
keys: [PS3Input.Cross]
},
ActionInput {
sourceDevice: keyboardSourceDevice
keys: [Qt.Key_Space]
}
]
},
Action {
name: "bigBomb"
inputs: [
InputChord { // Require two buttons to fire the "bigBomb"
ActionInput {
sourceDevice: ps3SourceDevice
keys: [PS3Input.Triangle]
},
ActionInput {
sourceDevice: ps3SourceDevice
keys: [PS3Input.Left]
}
}
]
},
Action {
name: "specialMoveCombo"
inputs: [
InputSequence { // Require a sequence within 0.5 seconds to
fire the "specialMoveCombo"
duration: 500
ActionInput {
sourceDevice: ps3SourceDevice
keys: [PS3Input.Up]
},
ActionInput {
sourceDevice: ps3SourceDevice
keys: [PS3Input.Left]
},
ActionInput {
sourceDevice: ps3SourceDevice
keys: [PS3Input.Down]
},
ActionInput {
sourceDevice: ps3SourceDevice
keys: [PS3Input.Right]
}
}
]
}
]
axes: [ ... ]
}
I hope to get that in very soon, along with keyboard modifiers.
Thanks for the feedback.
Cheers,
Sean
>
>
> That's for now, I hope it's helpful.
>
> Kind regards,
> Konstantin.
>
> On Wed, Dec 9, 2015 at 6:10 AM, Nye <kshegunov at gmail.com> wrote:
> > A guinea pig now, am I? ;)
> > Am I assuming correctly that these new changes are available through the
> > 5.6 HEAD? If so I'll fetch the repo and rebuild.
> > I think I understand what steps I need to take, so I'll try to implement
> > my controller and will report any *thoughts* ...
> > Thanks for the help!
> >
> > Kind regards,
> > Konstantin.
> >
> > On Tue, Dec 8, 2015 at 9:00 PM, Sean Harmer <sh at theharmers.co.uk> wrote:
> >> Aha, a timely guinea pig :)
> >>
> >> We've just merged in a bunch of changes to extend the Qt3DInput library.
> >> Please take a look at:
> >>
> >>
> >> http://code.qt.io/cgit/qt/qt3d.git/tree/examples/qt3d/simple-qml/CameraCo
> >> ntroller.qml
> >>
> >> for an example where we exercise the new API a little. We are in the
> >> process of folding something back into Qt3D proper to act as a camera (or
> >> anything else with a transform component) controller, but you can easily
> >> roll your own custom one with what is there now.
> >>
> >> The basic concepts are:
> >>
> >> 1) Instantiate 1 or more QAbstractPhysicalDevice's - MouseController,
> >> KeyboardController so far. These will be renamed to something without
> >> Controller appended shortly. These house a set of "axes" and "buttons".
> >> The
> >> axes can be processed in some simple ways as specified by an AxisSettings
> >> object. E.g. for a gamepad controller or other analogue devices we can
> >> support deadzones (https://codereview.qt-project.org/#/c/143265/) and
> >> hopefully tomorrow, low pass filtering. We also have the ability to add
> >> more devices by way of plugins. We have a WIP plugin for the PS3 SixAxis
> >> controller for e.g.
> >>
> >> 2) The physical devices can be mapped onto LogicalDevices as shown in the
> >> simple-qml example above. This mapping takes the form of specifying axes
> >> and actions on the logical device and declaring which physical device
> >> axis/buttons they originate from. Support for chords and sequences will
> >> land shortly. The logical device allows you to customise the input within
> >> your application to map through to some named axes and actions in your
> >> application and allows support for multiple input devices and dynamically
> >> reconfiguring them.
> >>
> >> 3) Instantiate a AxisActionHandler component and associate a logical
> >> device with it. The handler's actionStarted(), actionFinished() and
> >> axisValueChanged() signals will be fired as appropriate for you to react
> >> to
> >> in a signal handler.
> >>
> >> 4) If you need to perform smooth animations per frame as a result of
> >> input, also instantiate a LogicComponent and implement it's signal
> >> handler
> >> which gets the frame delta-time passed in as an argument. Use this to
> >> multiply your calculated velocity (or whatever) by.
> >>
> >> Hope this helps. If you have ideas for how to improve this then please
> >> let us know.
> >>
> >> Cheers,
> >>
> >> Sean
> >>
> >>
> >> On 08/12/2015 14:51, Nye wrote:
> >>
> >> Hello,
> >> I wish to have the camera movement bound to a certain "slice" of the
> >> world space. I didn't see that to be available through the default
> >> implementation, so I assume I'd have to write my own component that
> >> implements the input aspect and attach it to my camera. I've gone through
> >> the sources, because at this point the documentation is pretty thin.
> >> Unfortunately, I don't seem able to grasp at this point how the aspect
> >> will
> >> notify my component of the input events. I have 2 questions:
> >> 1. For my case, am I assuming correctly that I'd need my own component to
> >> realize that functionality?
> >> 2. If I do need a separate component, how can I make it? I understand
> >> that I have to subclass from QComponent, but how would I be notified for
> >> the input events occurring? Do I need to implement some other classes to
> >> make it work (I saw a number of "functors" created in Qt3D's source)?
> >>
> >> Any help is greatly appreciated.
> >>
> >> Kind regards,
> >> Konstantin.
> >>
> >>
> >> _______________________________________________
> >> Interest mailing
> >> listInterest at qt-project.orghttp://lists.qt-project.org/mailman/listinfo/
> >> interest
> >>
> >>
> >>
> >> _______________________________________________
> >> Interest mailing list
> >> Interest at qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/interest
More information about the Interest
mailing list