<p dir="ltr">I can see real value in that too.<br>
As said, this would indeed allow avoiding a lot of scripting I complex ui design.<br>
Daniel</p>
<div class="gmail_extra"><br><div class="gmail_quote">On 7 Sep 2016 11:07 p.m., "Yves Piguet" <<a href="mailto:yves.piguet@gmail.com">yves.piguet@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Might be easiest to do additional 'extension fields' (for new specs?) to a few sensor nodes so as not to break old scenes:<br>
SFFloat scalar_changed<br>
Or add utility nodes in a new Utility Component for splitting SFVec3f, SFRotation into scalars?<br>
<br>
Linesensor<br>
x I didn't implement the translation_changed as sffloat (sfvec3f like planesensor)<br>
<br>
PointSensor<br>
- yes, plane perpendicular to view, at distance where pick ray hits affected geometry<br>
<br>
-Doug<br>
<br>
> ______________________________<wbr>__________<br>
> From: Yves Piguet <<a href="mailto:yves.piguet@gmail.com">yves.piguet@gmail.com</a>><br>
> Sent: September 8, 2016 12:24 AM<br>
> To: doug sanden<br>
> Cc: X3D Graphics public mailing list<br>
> Subject: Re: [x3d-public] PlaneSensor x_changed output event<br>
><br>
> I'd also thought about a LineSensor node. I don't really have a strong preference between LineSensor and x_changed in PlaneSensor, provided that the output of LineSensor is an SFFloat, not an SFVec3f. The advantages of x_changed are (1) simpler change to specs and implementations, and (2) easier to generalize to an angle_changed in CylinderSensor node (scalars in SphereSensor aren't very useful without further processing anyway).<br>
><br>
> I'm not sure to understand your PointSensor. There must be some projection from 2D mouse position to a value with 1 or 2 degrees of freedom. Is it implicitly a plane perpendicular to the view direction? It might solve other problems, but not what I'm trying to address: obtaining a scalar value from a VR slider without obfuscating the x3dv file with trivial scripts and routes.<br>
><br>
> Yves<br>
><br>
> Le 8 sept. 2016 à 00:35, doug sanden a écrit :<br>
><br>
> ><br>
> > Somewhat related: proposed PointSensor node<br>
> > I found LineSensor (not in specs, did as experiment) would do some of the work of PlaneSensor > trackpoint_changed for dragging axis handles. And extrapolating from that when playing with a X3DConnector prototype, I thought there should be a PointSensor node. Then you don't need trackpoint changed because the main output from PointSensor would be doing that job, except more explicitly and reliably.<br>
> > <a href="http://dug9.users.sourceforge.net/web3d/tests/JohnCarlson/x3dconnector.x3d" rel="noreferrer" target="_blank">http://dug9.users.sourceforge.<wbr>net/web3d/tests/JohnCarlson/<wbr>x3dconnector.x3d</a><br>
> > - problem with planesensor: for general 3D sensing, as you move around the object to drag from an orthogonal axis, you could be looking edge-on at the planesensor. Similar to problem dragging axes handles with planesensor, solved with LineSensor.<br>
> ><br>
> > ______________________________<wbr>__________<br>
> > From: x3d-public <<a href="mailto:x3d-public-bounces@web3d.org">x3d-public-bounces@web3d.org</a>> on behalf of Yves Piguet <<a href="mailto:yves.piguet@gmail.com">yves.piguet@gmail.com</a>><br>
> > Sent: September 7, 2016 4:05 PM<br>
> > To: X3D Graphics public mailing list<br>
> > Subject: [x3d-public] PlaneSensor x_changed output event<br>
> ><br>
> > Hi,<br>
> ><br>
> > I'm investigating ways to simplify scenes. To avoid some scripts, I propose to add scalar output events to PlaneSensor: in addition to its existing trackPoint_changed and translation_changed output events, it would also have x_changed and y_changed, of type SFFloat. Likewise an SFFloat angle_changed could be added to CylinderSensor.<br>
> ><br>
> > What do you think?<br>
> ><br>
> > Yves<br>
> ><br>
> ><br>
> > ______________________________<wbr>_________________<br>
> > x3d-public mailing list<br>
> > <a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br>
> > <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/<wbr>listinfo/x3d-public_web3d.org</a><br>
> ><br>
> > ______________________________<wbr>_________________<br>
> > x3d-public mailing list<br>
> > <a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br>
> > <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/<wbr>listinfo/x3d-public_web3d.org</a><br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/<wbr>listinfo/x3d-public_web3d.org</a><br>
</blockquote></div></div>