Hello again,
I've run some more extensive tests regarding the action's signals and here
is what I gather from that. It seems that even if I don't release the mouse
key at all I get a actionFinished signal fired, not sure why. Here's an
example from my code (I just print out in the debug the slot's calls):
http://codepad.org/jWVZW3I7
It seems on the one hand that I get actionFinished/actionStarted signals
when I shouldn't (the mouse button was not released at any one point while
dragging it around. And also that for some reason events might be getting
rearranged a bit, note the difference in values, although the direction of
the mouse moving was not changed except at the boundaries (where I get the
started/finished actions actually).
I hope this helps in tracking that issue.
Kind regards.
On Wed, Dec 9, 2015 at 1:40 PM, Nye <kshegu...@gmail.com> wrote:
> Hello,
> I don't know how much you're open to "larger" changes, but I'd like to
> argue my case further, if you'd bear with me a bit more.
>
> >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.
>
> Currently, it seems that the Action is just a container for it's
> ActionInputs. I suggest the following, and you decide if it's applicable or
> it's something worth implementing:
>
> 1. Suppose you have an InputKey with properties the source device and a
> single key and InputAxis with the source device and the axis (both probably
> having a common superclass InputSource).
> 2. Then you may put a InputMap as a superclass for all types of
> InputSource behaviours - alternatives, sequences and chords. Let's say
> InputAlternatives defines the current behaviour - fires an action if one of
> the keys is triggered.
> InputGroup would perform the chord feature - checks all the required key
> actions and fires the events when all are pressed
> InputSequence configures the sequence of InputSources needed to fire the
> action.
> 3. Then your action object will take a single InputMap instance (one of
> the three possibilities at this point), and will be an abstraction for an
> action, not input mapping. The action would then be indifferent to the
> input mapping provided, but will follow its event depending on the InputMap
> you've set as a property.
>
> It'd look something like this in QML:
>
> Action {
> name: "shootCannons"
> input: InputAlternatives {
> sources: [
> InputKey {
> sourceDevice: mouseDevice
> key: MouseController.Left
> },
> InputKey {
> sourceDevice: keyboardDevice
> key: Qt.Key_Space
> }
> ]
> }
> },
> Action {
> name: "shootRockets"
> input: InputGroup {
> time: 0.1
> sources: [
> InputKey {
> sourceDevice: mouseDevice
> key: MouseController.Left
> },
> InputKey {
> sourceDevice: keyboardDevice
> key: Qt.Key_Shift
> }
> ]
> }
> }
>
> You keep the flexibility to change the input map at any one point, of
> course. And it'd be nice to be able to treat the Axis events on an equal
> footing with the button events (for example when emitting the action's
> signal the data from all InputMaps could be collected and passed as
> parameter).
>
> I think this'd be interesting to consider, because it makes the
> aggregation tree a bit less complex (less branches and nodes are needed to
> obtain the functionality). Also, as I see it, ActionInput objects in the
> current architecture are practically always used with a single key.
>
> I'd be willing to contribute source as well, but I'm afraid my knowledge
> of the underlying classes is pretty limited.
>
> Kind regards,
> Konstantin.
>
> On Wed, Dec 9, 2015 at 12:22 PM, Sean Harmer <s...@theharmers.co.uk> wrote:
>
>> 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 <kshegu...@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 <s...@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@qt-project.orghttp://
>> lists.qt-project.org/mailman/listinfo/
>> > >> interest
>> > >>
>> > >>
>> > >>
>> > >> _______________________________________________
>> > >> Interest mailing list
>> > >> Interest@qt-project.org
>> > >> http://lists.qt-project.org/mailman/listinfo/interest
>>
>>
>
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
