interactivity and VirtualMouse coordinates with MC's set off stage

[John Grden-2]

sorry for the wordy subject line, but i wanted to not waste anyone's time who didn't really care about this ;)

ok, well, I was doing some tests with using UI components as there's been some questions about using the etc.  One of the issues to tackle is that the movieclip you use for the material has to be on stage somewhere or else the components will never light up.  So, there are a few ways to do this:

1.  put on stage and set blendMode = ERASE.  This works, but of course, your clip is still interactive to 2D interaction since the movieclip is at 0,0 on stage
2.  hide / show the clip when you need to get objects under point for VirtualMouse - the problem with this is, you can see that the flash player is still redrawing any region of a hidden clip that is animating despite the parent visibility being set to false.  I haven't confirmed it with adobe, but seems that means there's some rendering consideration for that area of the screen and well, that sucks.
3.  coordinate conversion using localToLocal or globalToLocal or localToGlobal.  CPU intensive - not terribly, but more so that option 4
4.  move target container to 0,0, get objects under point, move back to original coordinates.

in running a side by side speed test, moving the clip and getting the array of objects was faster than coordinate conversion AND the coordinate conversion seemed to never work quite right with UI components or some other objects i was testing with.  Even if it had worked properly, moving the object first, then back is faster, so I'm inclined to push this out for people to try.

can anyone see any glaring issue with this method that i'm totally overlooking?

Thanks for your help,

John

PS> I have a blog post I'm working on with regards to using UI components in movie materials, i'll ping the list later on about that

--
[ JPG ]

_______________________________________________
Papervision3D mailing list
Papervision3D@...
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

[Justin Lawerance Mills]

John

I think that it may depend on the particular prob that is being  
tackled, I do not know all ins and outs and may not understand fully  
your points but have ideas.. which are prob crazy and misguided.

Generally it seems that mouse interaction is best served by real  
sprites.

1) switch to using a sprite per mouseable face/plane and back to not  
when just animating running two ver if needed.
2) use a mouse interaction layer, map mouse areas to 2d sprite areas  
on the mouse interaction layer porting planes faces 3d to 2d where  
needed.

It seems to me that we assume that interaction is statically defined  
but the reality is that there are always fazes where interaction is  
limited to waiting on a tween or dragging something before full on  
interaction so it makes sense to switch between mutiple sprite render  
and single sprite render and sometimes it might be simpler to have a  
2d hit state and a fancy effects with shadows etc.. real shape than  
just one object.

I would like virtual mouse to be more hackable!

Keep up the good work

Cheers


Justin
Ps any plans on haxe?


On 23 Jul 2008, at 20:07, John Grden wrote:

> sorry for the wordy subject line, but i wanted to not waste  
> anyone's time who didn't really care about this ;)
>
> ok, well, I was doing some tests with using UI components as  
> there's been some questions about using the etc.  One of the issues  
> to tackle is that the movieclip you use for the material has to be  
> on stage somewhere or else the components will never light up.  So,  
> there are a few ways to do this:
>
> 1.  put on stage and set blendMode = ERASE.  This works, but of  
> course, your clip is still interactive to 2D interaction since the  
> movieclip is at 0,0 on stage
> 2.  hide / show the clip when you need to get objects under point  
> for VirtualMouse - the problem with this is, you can see that the  
> flash player is still redrawing any region of a hidden clip that is  
> animating despite the parent visibility being set to false.  I  
> haven't confirmed it with adobe, but seems that means there's some  
> rendering consideration for that area of the screen and well, that  
> sucks.
> 3.  coordinate conversion using localToLocal or globalToLocal or  
> localToGlobal.  CPU intensive - not terribly, but more so that  
> option 4
> 4.  move target container to 0,0, get objects under point, move  
> back to original coordinates.
>
> in running a side by side speed test, moving the clip and getting  
> the array of objects was faster than coordinate conversion AND the  
> coordinate conversion seemed to never work quite right with UI  
> components or some other objects i was testing with.  Even if it  
> had worked properly, moving the object first, then back is faster,  
> so I'm inclined to push this out for people to try.
>
> can anyone see any glaring issue with this method that i'm totally  
> overlooking?
>
> Thanks for your help,
>
> John
>
> PS> I have a blog post I'm working on with regards to using UI  
> components in movie materials, i'll ping the list later on about that
>
> --
> [ JPG ]
> _______________________________________________
> Papervision3D mailing list
> Papervision3D@...
> http://osflash.org/mailman/listinfo/papervision3d_osflash.org

_______________________________________________
Papervision3D mailing list
Papervision3D@...
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

[John Grden-2]

yeah, originally that's how I'd approached interactivity, but the CPU hit was massive.  The current way of doing it works well, and seems to be not a bad hit at all.  But this area of having to deal with a movieclip that's on stage (either by choice or not) is the only real issue.  So far, I like the move idea for speed and accuracy, but I'd like to see more tests to be sure it's going to work in all situations and not cause any weird stuff to happen.

On Wed, Jul 23, 2008 at 3:12 PM, Justin Lawerance Mills <JLM@...> wrote:

John

I think that it may depend on the particular prob that is being
tackled, I do not know all ins and outs and may not understand fully
your points but have ideas.. which are prob crazy and misguided.

Generally it seems that mouse interaction is best served by real
sprites.

1) switch to using a sprite per mouseable face/plane and back to not
when just animating running two ver if needed.
2) use a mouse interaction layer, map mouse areas to 2d sprite areas
on the mouse interaction layer porting planes faces 3d to 2d where
needed.

It seems to me that we assume that interaction is statically defined
but the reality is that there are always fazes where interaction is
limited to waiting on a tween or dragging something before full on
interaction so it makes sense to switch between mutiple sprite render
and single sprite render and sometimes it might be simpler to have a
2d hit state and a fancy effects with shadows etc.. real shape than
just one object.

I would like virtual mouse to be more hackable!

Keep up the good work

Cheers


Justin
Ps any plans on haxe?

On 23 Jul 2008, at 20:07, John Grden wrote:

> sorry for the wordy subject line, but i wanted to not waste
> anyone's time who didn't really care about this ;)
>
> ok, well, I was doing some tests with using UI components as
> there's been some questions about using the etc.  One of the issues
> to tackle is that the movieclip you use for the material has to be
> on stage somewhere or else the components will never light up.  So,
> there are a few ways to do this:
>
> 1.  put on stage and set blendMode = ERASE.  This works, but of
> course, your clip is still interactive to 2D interaction since the
> movieclip is at 0,0 on stage
> 2.  hide / show the clip when you need to get objects under point
> for VirtualMouse - the problem with this is, you can see that the
> flash player is still redrawing any region of a hidden clip that is
> animating despite the parent visibility being set to false.  I
> haven't confirmed it with adobe, but seems that means there's some
> rendering consideration for that area of the screen and well, that
> sucks.
> 3.  coordinate conversion using localToLocal or globalToLocal or
> localToGlobal.  CPU intensive - not terribly, but more so that
> option 4
> 4.  move target container to 0,0, get objects under point, move
> back to original coordinates.
>
> in running a side by side speed test, moving the clip and getting
> the array of objects was faster than coordinate conversion AND the
> coordinate conversion seemed to never work quite right with UI
> components or some other objects i was testing with.  Even if it
> had worked properly, moving the object first, then back is faster,
> so I'm inclined to push this out for people to try.
>
> can anyone see any glaring issue with this method that i'm totally
> overlooking?
>
> Thanks for your help,
>
> John
>
> PS> I have a blog post I'm working on with regards to using UI
> components in movie materials, i'll ping the list later on about that
>
> --
> [ JPG ]

> _______________________________________________
> Papervision3D mailing list
> Papervision3D@...
> http://osflash.org/mailman/listinfo/papervision3d_osflash.org


_______________________________________________
Papervision3D mailing list
Papervision3D@...
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

--
[ JPG ]

_______________________________________________
Papervision3D mailing list
Papervision3D@...
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

[Justin Lawerance Mills]

John 

I dont know if u saw my recent posts but with a carousel if u click on a button and it rotates you click again but do not move the mouse pv provides the wrong visual movie to the real movie.  

It seems it is a flash prob and may well be platform/browser dependant as I got the mcs on stage sorted by x and routed onscreens transparent buttons to the carousel tween with the array index which worked well, but even here I found that without a mouse move the hand cursor ( which I turned off for tween ) was not updated. (let me know if you need private code [nda] to see what I mean but client is fussy for reasons)

So anything virtual is going to be hit hard by such bugs and in my case it was especially obvious.

For me real sprites are better for mousing but only when you need em, that is why I wonder about dynamic switching.

;j

 

On 23 Jul 2008, at 21:19, John Grden wrote:

yeah, originally that's how I'd approached interactivity, but the CPU hit was massive.  The current way of doing it works well, and seems to be not a bad hit at all.  But this area of having to deal with a movieclip that's on stage (either by choice or not) is the only real issue.  So far, I like the move idea for speed and accuracy, but I'd like to see more tests to be sure it's going to work in all situations and not cause any weird stuff to happen.

On Wed, Jul 23, 2008 at 3:12 PM, Justin Lawerance Mills <JLM@...> wrote:

John

I think that it may depend on the particular prob that is being
tackled, I do not know all ins and outs and may not understand fully
your points but have ideas.. which are prob crazy and misguided.

Generally it seems that mouse interaction is best served by real
sprites.

1) switch to using a sprite per mouseable face/plane and back to not
when just animating running two ver if needed.
2) use a mouse interaction layer, map mouse areas to 2d sprite areas
on the mouse interaction layer porting planes faces 3d to 2d where
needed.

It seems to me that we assume that interaction is statically defined
but the reality is that there are always fazes where interaction is
limited to waiting on a tween or dragging something before full on
interaction so it makes sense to switch between mutiple sprite render
and single sprite render and sometimes it might be simpler to have a
2d hit state and a fancy effects with shadows etc.. real shape than
just one object.

I would like virtual mouse to be more hackable!

Keep up the good work

Cheers


Justin
Ps any plans on haxe?

On 23 Jul 2008, at 20:07, John Grden wrote:

> sorry for the wordy subject line, but i wanted to not waste
> anyone's time who didn't really care about this ;)
>
> ok, well, I was doing some tests with using UI components as
> there's been some questions about using the etc.  One of the issues
> to tackle is that the movieclip you use for the material has to be
> on stage somewhere or else the components will never light up.  So,
> there are a few ways to do this:
>
> 1.  put on stage and set blendMode = ERASE.  This works, but of
> course, your clip is still interactive to 2D interaction since the
> movieclip is at 0,0 on stage
> 2.  hide / show the clip when you need to get objects under point
> for VirtualMouse - the problem with this is, you can see that the
> flash player is still redrawing any region of a hidden clip that is
> animating despite the parent visibility being set to false.  I
> haven't confirmed it with adobe, but seems that means there's some
> rendering consideration for that area of the screen and well, that
> sucks.
> 3.  coordinate conversion using localToLocal or globalToLocal or
> localToGlobal.  CPU intensive - not terribly, but more so that
> option 4
> 4.  move target container to 0,0, get objects under point, move
> back to original coordinates.
>
> in running a side by side speed test, moving the clip and getting
> the array of objects was faster than coordinate conversion AND the
> coordinate conversion seemed to never work quite right with UI
> components or some other objects i was testing with.  Even if it
> had worked properly, moving the object first, then back is faster,
> so I'm inclined to push this out for people to try.
>
> can anyone see any glaring issue with this method that i'm totally
> overlooking?
>
> Thanks for your help,
>
> John
>
> PS> I have a blog post I'm working on with regards to using UI
> components in movie materials, i'll ping the list later on about that
>
> --
> [ JPG ]

> _______________________________________________
> Papervision3D mailing list
> Papervision3D@...
> http://osflash.org/mailman/listinfo/papervision3d_osflash.org


_______________________________________________
Papervision3D mailing list
Papervision3D@...
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

--
[ JPG ]

_______________________________________________

Papervision3D mailing list

Papervision3D@...

http://osflash.org/mailman/listinfo/papervision3d_osflash.org

_______________________________________________
Papervision3D mailing list
Papervision3D@...
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

[John Grden-2]

ahh that's a great visual, I understand what you're saying - without the mouse move, etc, it fails.

Ok, I'll take a look - I might think that a public method called in the render loop might be a good idea - I'll look into it

On Wed, Jul 23, 2008 at 4:14 PM, Justin Lawerance Mills <JLM@...> wrote:

John 

I dont know if u saw my recent posts but with a carousel if u click on a button and it rotates you click again but do not move the mouse pv provides the wrong visual movie to the real movie.  

It seems it is a flash prob and may well be platform/browser dependant as I got the mcs on stage sorted by x and routed onscreens transparent buttons to the carousel tween with the array index which worked well, but even here I found that without a mouse move the hand cursor ( which I turned off for tween ) was not updated. (let me know if you need private code [nda] to see what I mean but client is fussy for reasons)

So anything virtual is going to be hit hard by such bugs and in my case it was especially obvious.

For me real sprites are better for mousing but only when you need em, that is why I wonder about dynamic switching.

;j

 

On 23 Jul 2008, at 21:19, John Grden wrote:

yeah, originally that's how I'd approached interactivity, but the CPU hit was massive.  The current way of doing it works well, and seems to be not a bad hit at all.  But this area of having to deal with a movieclip that's on stage (either by choice or not) is the only real issue.  So far, I like the move idea for speed and accuracy, but I'd like to see more tests to be sure it's going to work in all situations and not cause any weird stuff to happen.

On Wed, Jul 23, 2008 at 3:12 PM, Justin Lawerance Mills <JLM@...> wrote:

John

I think that it may depend on the particular prob that is being
tackled, I do not know all ins and outs and may not understand fully
your points but have ideas.. which are prob crazy and misguided.

Generally it seems that mouse interaction is best served by real
sprites.

1) switch to using a sprite per mouseable face/plane and back to not
when just animating running two ver if needed.
2) use a mouse interaction layer, map mouse areas to 2d sprite areas
on the mouse interaction layer porting planes faces 3d to 2d where
needed.

It seems to me that we assume that interaction is statically defined
but the reality is that there are always fazes where interaction is
limited to waiting on a tween or dragging something before full on
interaction so it makes sense to switch between mutiple sprite render
and single sprite render and sometimes it might be simpler to have a
2d hit state and a fancy effects with shadows etc.. real shape than
just one object.

I would like virtual mouse to be more hackable!

Keep up the good work

Cheers


Justin
Ps any plans on haxe?

On 23 Jul 2008, at 20:07, John Grden wrote:

> sorry for the wordy subject line, but i wanted to not waste
> anyone's time who didn't really care about this ;)
>
> ok, well, I was doing some tests with using UI components as
> there's been some questions about using the etc.  One of the issues
> to tackle is that the movieclip you use for the material has to be
> on stage somewhere or else the components will never light up.  So,
> there are a few ways to do this:
>
> 1.  put on stage and set blendMode = ERASE.  This works, but of
> course, your clip is still interactive to 2D interaction since the
> movieclip is at 0,0 on stage
> 2.  hide / show the clip when you need to get objects under point
> for VirtualMouse - the problem with this is, you can see that the
> flash player is still redrawing any region of a hidden clip that is
> animating despite the parent visibility being set to false.  I
> haven't confirmed it with adobe, but seems that means there's some
> rendering consideration for that area of the screen and well, that
> sucks.
> 3.  coordinate conversion using localToLocal or globalToLocal or
> localToGlobal.  CPU intensive - not terribly, but more so that
> option 4
> 4.  move target container to 0,0, get objects under point, move
> back to original coordinates.
>
> in running a side by side speed test, moving the clip and getting
> the array of objects was faster than coordinate conversion AND the
> coordinate conversion seemed to never work quite right with UI
> components or some other objects i was testing with.  Even if it
> had worked properly, moving the object first, then back is faster,
> so I'm inclined to push this out for people to try.
>
> can anyone see any glaring issue with this method that i'm totally
> overlooking?
>
> Thanks for your help,
>
> John
>
> PS> I have a blog post I'm working on with regards to using UI
> components in movie materials, i'll ping the list later on about that
>
> --
> [ JPG ]

> _______________________________________________
> Papervision3D mailing list
> Papervision3D@...
> http://osflash.org/mailman/listinfo/papervision3d_osflash.org


_______________________________________________
Papervision3D mailing list
Papervision3D@...
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

--
[ JPG ]

_______________________________________________

Papervision3D mailing list

Papervision3D@...

http://osflash.org/mailman/listinfo/papervision3d_osflash.org

_______________________________________________
Papervision3D mailing list
Papervision3D@...
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

--
[ JPG ]

_______________________________________________
Papervision3D mailing list
Papervision3D@...
http://osflash.org/mailman/listinfo/papervision3d_osflash.org