[x3d-public] LineSensor and avoiding uncontrolled dragging

Mon Apr 1 06:00:33 PDT 2019

likewise thanks, glad you think the pathology issues are real.  they are perhaps expected by grizzled 3D veterans, but will not be expected or understood by non-expert users ("hey everything i try to move around disappears!")

let's press on with prose that identifies the issue and provides implementation guidelines and requirements (candidates listed before).  As your latest prose implies, giving browsers some leeway to adaptively respond (and thus "do the right thing") is a good idea.  this will also help authors understand how to better avoid interaction difficulties.

once you and Doug and list participants think that this contribution is mostly ready, X3D Working Group will be happy to review specification inputs for X3Dv4.  less than 100% completion is OK, if the TODO items are well defined and open questions are somehow resolvable.  examples like yours certainly help!  onward we go.

v/r Don

On 3/31/2019 7:12 AM, Andreas Plesch wrote:
> Hi Don,
> 
> thanks for looking into this issue. I have amended the write-up to
> include a more complete draft for a spec. comment:
> 
> https://gist.github.com/andreasplesch/33016fd0918178f5dfcf4632d477f4e4#file-readme-md
> 
> You are right that there are pathologies with dragging. Some of them
> are unavoidable as is the case for dragging in a plane which can only
> be seen on edge by a viewer. The equivalent for the line sensor case
> would be dragging along the line where only the tip of the line is
> visible.
> 
> I am not sure if these cases need to be codified since there is not an
> expectation by a user to be able to drag for these viewing situations
> in the first place. Although I think it is a good idea to add a
> provision that dragging should be disabled in these situations. "Ill
> defined" could be left fuzzy. I cannot think of another pathology.
> 
> But this provision would not address the jumping line sensor, I am afraid.
> 
> The difference with line sensor as currently specified is that if the
> view is on edge down the tracking plane, generally the line still can
> be seen fully (not just the tip) and so there is an expectation that
> well defined dragging is still possible. In fact, browsers like
> Octaga, x_ite or view3dscene ignore the XY tracking plane in the line
> sensor case to allow proper dragging in this case, in contradiction to
> the spec.
> 
> Any feedback much welcome, Andreas
> 
> On Sun, Mar 31, 2019 at 3:21 AM Brutzman, Donald (Don) (CIV)
> <brutzman at nps.edu> wrote:
>>
>> thanks for the in-depth look at these challenges.
>>
>> yes, good specification preparation really helps a lot... this work all takes time, which is our only limited constraint.
>>
>> On 3/27/2019 8:07 PM, Andreas Plesch wrote:
>>> In preparation for a well presented spec. comment, I developed a
>>> minimal but discerning example scene illustrating the problematic on
>>> edge view for 1D PlaneSensors:
>>>
>>> https://gist.github.com/andreasplesch/33016fd0918178f5dfcf4632d477f4e4#file-planesensor1donedge-x3d
>>
>> In the writeup there you say:
>> =============================
>> Drag the red cone
>> This scene illustrates the difficulty of using a PlaneSensor when the view is parallel to the tracking plane (light blue). Dragging works well in the default view normal to the tracking plane. Press PgUp to change the viewpoint to an on edge view. Dragging cannot work because the intersection of the bearing with tracking the plane becomes ill defined.
>> =============================
>>
>> A not-uncommon 3D pathology when dragging along a direction that is nearly perpendicular to the screen is that translations can become wildly large, moving things behind the user's view, or inside /outside the view frustum clipping planes.  At which point, the selected geometry is not visible and the handle is lost if the drag sensor is released.
>>
>> A good practice for implementers is "don't do that" but am not sure that is codified anywhere.  Not seeing any cautionary prose like that in the X3D specification.
>>
>> Perhaps we can come up with a functional limitation on drag sensors that avoids this pathology?
>>
>> Perhaps
>> a. Drag sensors must avoid operating when the tracking geometry becomes ill defined and does not permit positive user control.
>> b. Dragging past the boundaries of the view frustum is not allowed.
>> c. something else?
>>
>> all the best, Don
>> --
>> Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
>> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
>> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
> 
> 
> 

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman