You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This simulation has to deal with offset images, where the position in the model does not match the actual position of the image, but some arbitrary point on it.
For instance, the first sourceImage (sourceObjectImage), secondSourceImage , projectorScreenNode and targetNode all deals with images with offsets.
In the first three cases, the images have an associated dragListener attached to them. In addition, these image must be dragBounds to a region of space as well as repositionned if the dragBounds changed.
TargetNode does not have a dragHandler scaled up and down with respect to the offset point.
The sourceObjectImage and projectorScreenNode deals with the dragHandler in a similar manner, and you will see a lot of overlap.
The secondImage (source) does not have correct handling of the image (see #82 and #58) but I feel that this is pointless to fix individually but instead come up with a more general solution to handle images that have an offset.
One could consider a class that would take an image, modelviewtransfrom, positionProperty, a position offset and an initial model size (say width). With this information, this class would rendered an image with the appropriate position.
An external method would allow to scale the function.
In addition, it should be able to mutate the image and the offset with an external method.
An optional flag (isDraggable) and dragBoundsProperty could add an optional dragListener with dragBounds such that the entire image always stay with the dragBounds.
The text was updated successfully, but these errors were encountered:
In #125, #126 and #109, the design team expressed the desire to mimic a 3D illusion by splitting the projector, sources and targets into images with two different z layers. This would allow the optical axis and the rays to be on top of one side of the image but underneath the other.
Although we may not want to implement the image splitting layer as part of this issue, we should consider the implications as part of this proposal.
In #125, #126 and #109, the design team expressed the desire to mimic a 3D illusion by splitting the projector, sources and targets into images with two different z layers. ....
There will be no need to split images. The approach used in #125 is working great. It uses clipArea to create foreground and background parts of the rays and optical axis.
I also don't think I'll have a need for the module described in this issue, so I'm going to close this issue.
This simulation has to deal with offset images, where the position in the model does not match the actual position of the image, but some arbitrary point on it.
For instance, the first sourceImage (sourceObjectImage), secondSourceImage , projectorScreenNode and targetNode all deals with images with offsets.
In the first three cases, the images have an associated dragListener attached to them. In addition, these image must be dragBounds to a region of space as well as repositionned if the dragBounds changed.
TargetNode does not have a dragHandler scaled up and down with respect to the offset point.
The sourceObjectImage and projectorScreenNode deals with the dragHandler in a similar manner, and you will see a lot of overlap.
The secondImage (source) does not have correct handling of the image (see #82 and #58) but I feel that this is pointless to fix individually but instead come up with a more general solution to handle images that have an offset.
One could consider a class that would take an image, modelviewtransfrom, positionProperty, a position offset and an initial model size (say width). With this information, this class would rendered an image with the appropriate position.
An external method would allow to scale the function.
In addition, it should be able to mutate the image and the offset with an external method.
An optional flag (isDraggable) and dragBoundsProperty could add an optional dragListener with dragBounds such that the entire image always stay with the dragBounds.
The text was updated successfully, but these errors were encountered: