Hi,
Can I make a feature request? Quite often I'd like to inspect a small
detail of my design. Then you'd say: Just zoom until it is big enough
to see on your screen , rigth?
But it is not that simple. Wat "feels" like a zoom is not. It just
moves the camera closer to the point where you're looking. This means
that quite often the camera ends up inside an object that is being
subtracted, and then the "preview" render doesn't work.
Example:
wt = 1.3;
module myobject ()
{
difference () {
cylinder (d=20, h=20, center=true);
cylinder (d=20-2wt, h=20-2wt, center=true);
}
}
difference () {
myobject ();
cube (50);
}
I'm using the last difference to "inspect" the inside that I can't
otherwise see.
In the "view" menu it is called "zoom in" but it is not zoom, it is
"move camera in".
There are workarounds. like setting $vpf (i've found that while
writing this) or hitting render. But there are disadvantages to both.
Just say control-scroll will "zoom in/out" instead of "move camera
in/out" would be very much appreciated.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.
2wt needs to be 2*wt, then it works.
In the "view" menu it is called "zoom in" but it is not zoom, it is
"move camera in".
Isn’t it the other way round? A zoom lens narrows or widens the angle of view, making the object APPEAR closer or further respectively, while the photographer stays put. What I think you want is to be able to go inside the object, i.e. "move camera in".
I recently modeled a room in my flat and could have done with a feature like that myself, to get an eye-level 360° view of the inside.
But it is not that simple. Wat "feels" like a zoom is not. It just
moves the camera closer to the point where you're looking. This means
that quite often the camera ends up inside an object that is being
subtracted, and then the "preview" render doesn't work.
Yeah, I see what you mean.
I think ideally "travel in/out" and "adjust FOV" should be different mouse controls.
Even though they seem similar they're actually quite different operations, as you describe.
I keep switching back and forth betwen OpenSCAD and Cura which means
I never know which button does what anyway.
-----Nick
… quite often the camera ends up inside an object that is being
subtracted …
The camera goes inside the cavity?
I would love to know how to do that!
Maybe I have the wrong version of OpenSCAD.
Nick Moore wrote:
I never know which button does what anyway.
-----Nick
Yes, I know the problem.
You can zoom in without going inside the object by switching to the
orthogonal view.
On Mon, 7 Aug 2023 at 05:22, mikeonenine@web.de wrote:
Nick Moore wrote:
I never know which button does what anyway.
-----Nick
Yes, I know the problem.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Amen, brother. Too many standards means no standards at all
On 8/6/2023 10:35 PM, Nick Moore wrote:
I keep switching back and forth betwen OpenSCAD and Cura which means
I never know which button does what anyway.
On Mon, Aug 07, 2023 at 11:53:18AM +0100, nop head wrote:
You can zoom in without going inside the object by switching to the
orthogonal view.
One more workaround that has disadvantages.
The display-engine is able to do it. I know how it works. And my
"assertion" is apparently true, as assigning to the $fpv variable
works. So it is just the lack of user-controls that prevent me from
doing it my way.
I am not demanding that someone go and add this for me immediatly,
"should be doable by next week, right?".
Just that when someone on this list happens to come across the
scroll-wheel-code and think he/she is up to the task, they just go in
and add the few lines-of-code that might be handy for some people.
It is not that it is debatable if it is a good idea. and that there
is no consensus. I'm just saying to keep it in mind. If you or
anybody else comes across the code for this and thinks it is a good
idea, then please implement it.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.
Hi,
It took me a while to figure out where this would go. I'm convinced it
is a couple (about two) lines near line 362 of QGLView.cc .
It would be neat to create a new version of:
void QGLView::zoom(double v, bool relative)
{
this->cam.zoom(v, relative);
update();
emit cameraChanged();
}
that calls
this->cam.setVpf
so total lines changed about 10.
I'm getting stuck on: "can I get the modifier state" inside the
wheelevent handler. Wait.... Idea.
Here is the patch.
diff --git a/src/gui/QGLView.cc b/src/gui/QGLView.cc
index 622108969..c061529c7 100644
--- a/src/gui/QGLView.cc
+++ b/src/gui/QGLView.cc
@@ -358,7 +358,9 @@ void QGLView::wheelEvent(QWheelEvent *event)
{
const auto pos = Q_WHEEL_EVENT_POSITION(event);
const int v = event->angleDelta().y();
+void QGLView::zoomfov(double v)
+{
void QGLView::zoomCursor(int x, int y, int zoom)
{
const auto old_dist = cam.zoomValue();
diff --git a/src/gui/QGLView.h b/src/gui/QGLView.h
index 4524cde8e..c14dea72b 100644
--- a/src/gui/QGLView.h
+++ b/src/gui/QGLView.h
@@ -51,6 +51,7 @@ public:
QLabel *statusLabel;
void zoom(double v, bool relative);
Roger.
On Mon, Aug 07, 2023 at 07:27:47PM +0200, Rogier Wolff wrote:
On Mon, Aug 07, 2023 at 11:53:18AM +0100, nop head wrote:
You can zoom in without going inside the object by switching to the
orthogonal view.
One more workaround that has disadvantages.
The display-engine is able to do it. I know how it works. And my
"assertion" is apparently true, as assigning to the $fpv variable
works. So it is just the lack of user-controls that prevent me from
doing it my way.
I am not demanding that someone go and add this for me immediatly,
"should be doable by next week, right?".
Just that when someone on this list happens to come across the
scroll-wheel-code and think he/she is up to the task, they just go in
and add the few lines-of-code that might be handy for some people.
It is not that it is debatable if it is a good idea. and that there
is no consensus. I'm just saying to keep it in mind. If you or
anybody else comes across the code for this and thinks it is a good
idea, then please implement it.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.
I suppose we really need to have all the input stuff configurable
at some point. But I don't think having another option makes things
worse. So lets try that.
https://github.com/openscad/openscad/pull/4718
Let me know if you want to be attributed as author by name and
email from the mailing list.
ciao,
Torsten.