Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider a new module to deal with Images with offset #172

Closed
veillette opened this issue Aug 5, 2021 · 2 comments
Closed

Consider a new module to deal with Images with offset #172

veillette opened this issue Aug 5, 2021 · 2 comments

Comments

@veillette
Copy link
Contributor

veillette commented Aug 5, 2021

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.

@veillette
Copy link
Contributor Author

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.

@pixelzoom
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants