Entraides et échanges autour de la technologie Scol - Informations and exchanges on the Scol technology
Vous pouvez changer la langue de l'interface une fois inscrit - You can change the language once registered
You are not logged in.
look here http://www.scolring.org/forum/viewtopic.php?id=1288
this is the same
Offline
the ergonomy you want is a directional button like on gameboy ?
if you press the top of the button it goes forward ... ?you could make a specific plugit from the button code whete you use button state de change the button press bitmap, top, left, right, bottom and left + top, top + right ...
you could call it directionnal touch pad
no, dragging is best, and your button code does that. your finger is in contact with the button and drags, you start moving. you stop, the movement continues in the same direction. you lift your finger, you stop moving. as for the throttle and trackball, both are behaving like this. what i'm thinking is not allowing reaction to touchpoints on the buffer that is not covered by a button. that way the user can get a 'feel' for how much movement is needed to achieve desired movement on the widgets, as opposed to having widgets, but also being able to initiate movement from randon points on the screen.
i was thinking i could set the callbacks for touchpoint creation no the walkthrough plugit to do nothing. that way the only touchpoints that exist are those that are created on the buttons. then with each frame i could test to see if the touchpoint is still on the button. if it isn't, the button won't send a push moved event. but that may affect performance.
all in all, it's not that big an issue. people will see the buttons, i will set up some touchpoint bitmaps to give feedback like in your multitouch plugit (or i will just include the multitouch plugit in the project, although perhaps performance will be better if i just add some code to the buttons, i don't know) and they will know what to do. that's what's important, making something intuitive and obvious without any text or words.
Offline
look here http://www.scolring.org/forum/viewtopic.php?id=1288
this is the same
thanks that will reverse the x axis rotation i will try that
that leaves issues 2 and 3 i raised, but it's really issue 3 that at this point is the most mysterious. i think i can edit the walkthrought to allow translation and y rotation at the same time. or maybe not, i will see
Offline
the ergonomy you want is a directional button like on gameboy ?
if you press the top of the button it goes forward ... ?you could make a specific plugit from the button code whete you use button state de change the button press bitmap, top, left, right, bottom and left + top, top + right ...
you could call it directionnal touch pad
navigation plugIt do not limit the axis on the same time, as you can see with the mouse or the keyboard.
I still don't understand the issue and which ergonomy you are trying to make
Offline
I add tests in walkthrough and fps plugit to prevent touch moves when you are on a widget.
so the "control" widget have the priority on moves.
it's hard to allow so much ergonomics at the same time. I could add a check box to disable "automatic control" that should disable mouse, keyboard and touch in the navigation plugit but allows external control actions only.
forgot the previous post I missed your response ^^^
I'm preparing th A.8 release for monday.
so if you found another things we only have this weekend
Offline
I add tests in walkthrough and fps plugit to prevent touch moves when you are on a widget.
so the "control" widget have the priority on moves.it's hard to allow so much ergonomics at the same time. I could add a check box to disable "automatic control" that should disable mouse, keyboard and touch in the navigation plugit but allows external control actions only.
forgot the previous post I missed your response ^^^
I'm preparing th A.8 release for monday.
so if you found another things we only have this weekend :)
thx i will download the client files and see what they do.
Actually i played around with the existing button plugits and i think i got behavior which is consistent and what i'm trying to implement....controlling movement without having to remove your fingers from the widgets. maybe the best way to explain it is emulating two joytsticks. one is a +-z throttle, the other rotates +-x and =-y. when you remove your hand from the widget, it's like removing your hand from the joystick, which pops back into neutral and stops movement
..i think the best way of letting you see what i mean is skyping and showing you with my tablet or getting your hands a tablet...i'll upload my experiments over the weekend.
Offline
yes this is exactly what I was in mind when I add the pushed move event
we just had difficulties to understand each other
this is the Y axis that is reverted ?
Offline
yes this is exactly what I was in mind when I add the pushed move event
we just had difficulties to understand each otherthis is the Y axis that is reverted ?
I don't know what I did on the link settings but both y and x are inverted which is ok as I will use vector multiply on both. I won't be at tablet till tomorrow or Sunday .
I will be stress testing this a lot and should be able to resolve the unpredictability at least at the logic brick or scol code level.
Last edited by hebdemnobad (21-Nov-2014 23:43:10)
Offline
Could you enable file attachments (mp4) on the forum that could help in communicating but no worry if you can't.
Last edited by hebdemnobad (21-Nov-2014 23:46:18)
Offline
yes sorry just noticed that I made a mistake
i'm correcting this
Thx
Offline
ouf done ^^
there was more cases too manage with mouse too...
I also reverted the Y axis to have 1 for up -1 for down and -1 for left and 1 for right
you can take the client file from the svn
Offline
ouf done ^^
there was more cases too manage with mouse too...
I also reverted the Y axis to have 1 for up -1 for down and -1 for left and 1 for right
Kl
you can take the client file from the svn
Thx will try tomorrow
Offline
hello arekon you have solved isssues 1 and 3, now the x axis looks up and down correctly (issue 1) and 3 s solved too:
to explain about issue 3:
i initiate throttle movement along z axis
and while i keep finger on throttle moving forward or backward i initiate y rotation on trackball/trackpad.
i release throttle finger
since i still have finger on trackpad, i start rotating around y, without reverse y rotation.
here are the remaining issues for trackpad like movement:
if i am rotating around y, i cannot begin forward or backward movement (converse of issue 2)
and one more issue (i will call it 4
if i am rotating around y, then iniate swipe on throttle for z movement, nothing happens. moreover, when i release trackball touchpoint, the throttle does not start iniating any movement (somehing tells me if issue 2 is resolved, issue 4 will probably go away)
i presume there is a test in cbasic nav that says if rotating along y do not move along z, and if moving along z, don't rotate along y..i will look for this test in cbasicnav.pkg but if you know the line number or function, let me know and i can change code to make this behavior a checkbox option in editor.
i will try to post a screen capture now, with touchoint plugit in scene, you should see what i mean....
Offline
can you show me how you set the links parameters ?
Yes give me a few minutes
Offline
ok...i'm using the cbasicnav.pkg you uploaded on 21/11/2014, os3d revision 6876
i'm using cbutton.pkg you uploaded on 22/11/2014, os3d revision 6883
throttle (name for a button).pushed move-> walkthrough plugit (using cbasicnav.pkg revi. 6876) control: 0 0 $2 ax ay az
throttle (name for a button).release-> walkthrough plugit (using cbasicnav.pkg revi. 6876) control: 0 0 0 ax ay az
trackball (name for a button).pushed move-> walkthrough plugit (using cbasicnav.pkg revi. 6876) control: vx vy vz $2 $1 0
trackball (name for a button).release-> walkthrough plugit (using cbasicnav.pkg revi. 6876) control: vx vy vz 0 0 0
Offline
vx vy .. does nothing this values come from nowhere.
this should be 0 or _ to ignore
oops, somewhere i picked up the idea that those values left the inputs unaffected.
in any case, with walkthrough, i changed the links to
throttle (name for a button).pushed move-> walkthrough plugit (using cbasicnav.pkg revi. 6876) control: 0 0 $2 _ _ _
throttle (name for a button).release-> walkthrough plugit (using cbasicnav.pkg revi. 6876) control: 0 0 0 _ _ _
trackball (name for a button).pushed move-> walkthrough plugit (using cbasicnav.pkg revi. 6876) control: _ _ _ $2 $1 0
trackball (name for a button).release-> walkthrough plugit (using cbasicnav.pkg revi. 6876) control: _ _ _ 0 0 0
and i am encountering the same issues.
Offline
perhaps the route of using buttons as a virtual throttle and trackpad isn't the best use of your time right now....once you have a tablet it will be easier to see the issues i am encountering.
i'm thinking the problem is making navigation intuitive to the a new user with visual symbols.
so instead of using buttons to control the scene, i should use area plugit to explain how the user interacts with the scene, for example, with fps navigation the scene would display symbols for forward-backward/strafe for the left side of the screen, and x eye rotate and y rotate/rotate z vector on the right side of the screen. the correct visual cues would remain on screen for the life of a touchpoint, so a touchpoint with fps that begins on the left side of the screen and moves over to the right side of the screen would continue to show a symbol for 'forward, backward, strafe', and a touchpoint that begins on the ritght side of the screen and moves to the left would still show a visual symbol for (rotate eye up down/right left, and right/left turn if lid touchpoint is still active)
the more experienced user could toggle these overlays on and off. for the advanced beginner, the overlays would appear when he/she creates a touchpoint, and would explain interaction when the user is using his/her thumbs.
or i could paint alphabitmaps onto 3d plains to give more of a 3d feel to the interaction explanations.
so the ui for interacting with thumbs would use an hud approach to show scene interaction to a new or beginning user. i would be using the touchpoint interactivity that you already have up and running instead of building it into buttons as controllers. by using SO3BodyGetVelocity and SO3BodyGetOmega in actions or events of the navigation plugits, along with areas or widgets of some sort, os3d can give the user feedback as to turning, rotating, banking, etc. so i would approach the problem as telling the user how he/she is influencing the movement with visual symbols that would appear on the screen or on planes in the scene itself.
i think the virtual throttle and trackpad approach still has merit, as it gives a user an idea that he/she is driving a vehicle, since we use often use tools/buttons/throttles/etc to make things move forward, back, turn, etc, (especially when the camera is tied to a vehicle or mechanism of some kind like a car/plane/balloon/submarine/ship, etc, as opposed to driving a living thing that walks, runs, flies, swims, and eats/picks up things/shoots/put your other activities here)
but i don't want you to spend more time on this problem if you have other stuff to do, you are of so much help as it is.
in any case, if you want me to continue to troubleshoot the button approach, i will keep on reporting back to you to help figure out the issues that arise when using buttons to move/rotate camera shells. i'm sure allowing buttons to influence camera position/rotation/speed is needed elsewhere anyway, (as in increasing speed by some set multiplier/allowing for rotation of the camera along the z axis for flying and swimming)
presently i have camstudio screen capture setup on my tablet, but arg it has windows 8 issues and i have to spend time to figure it out. and i have some housework to attend to this afternoon.
Last edited by hebdemnobad (23-Nov-2014 20:18:21)
Offline
this was a conflict between the default multi touch navigation method and external inputs.
I added an option on walktrough and fps plugit to disable the default control inputs.
this should work
Offline
this was a conflict between the default multi touch navigation method and external inputs.
I added an option on walktrough and fps plugit to disable the default control inputs.
this should work
I'll test it thx! Later I'll download from redmine and try things out and report back.
Last edited by hebdemnobad (23-Nov-2014 20:56:48)
Offline
wow with your latest revision it works exactly as i first imagined. the only issues (minor imho) are:
1.. positive vx and vy values are inverted to negative ones, so if you have pushed out paramater one (vx) mapped to control vx, it moves the shell -vx, or to rotate ax, it rotates -ax,
so there is somewhere the negative/positive values get switched, and
2. if a touchpoiont is created on a button, the output continues to increase as the increasing distance from the touchpoints origin. this can lead to a problem if you have a trackpad in a corner or a throttle justified to an edge, since you can swipe off in one direction and go faster than the other (or example i set up a trackpad element to the lowerr right corner. since i can swipe to the left all the way across the screen, i can achieve faster rotation than if i swipe to the right, since the touchpoint leaves the buffer and os3d cooncludes that it as been destroyed.)
the workaround to 1 is use a vector multiply plugit, the workaround to 2 is center control widgets on the screen.
maybe its just me, but i find it does give the user better feedback to see the touchpoint in relation to a widget as opposed to half of a screen
great work in any case. i guess issue 2 could be addressed by testing at each prerender if a touchpoint is on a button or not; i can see a downside here though, since if a user's finger wanders off the widget, movement stops. so perhaps the workaround for issue 2 is better than my proposed solution.
Last edited by hebdemnobad (23-Nov-2014 23:02:14)
Offline
button values are correct this is the inputs in the control that do that way. so yes you must revert the values when needed.
put the buttons with a margin, also it should not happen in fullscreen.
Offline
usually fps games on tablets use the split screen (default fps ergonomic) and some others use track pads on screen.
the difference in facts is that the pad appear when the user put it's finger on the left or right screen parts.
so it could just be a picture shown under the finger.
Offline