Empathy List Archives

P

Parkinbot

Tue, Apr 25, 2017 12:29 PM

This is also a nice - and so far unknown - new feature in general context.
Congratulations.

--
View this message in context: http://forum.openscad.org/Animation-manually-triggered-tp21347p21375.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

This is also a nice - and so far unknown - new feature in general context. Congratulations. -- View this message in context: http://forum.openscad.org/Animation-manually-triggered-tp21347p21375.html Sent from the OpenSCAD mailing list archive at Nabble.com.

TP

Torsten Paul

Tue, Apr 25, 2017 1:19 PM

If some bigger change is made to brush up the animation
interface, please also provide a possiblity to programmatically
set the physical framesize. The method I use now is to set
the viewport size with the mouse, which is very cumbersome.
Or did I miss something?

That's unfortunately a different can of worms as it needs an
off-screen renderer driven by the GUI application. So while
related, it's probably better to leave that separate. This
also would help with simple image export too (I think there's
also an issue for that already).

As this is a bigger topic, the workaround for now is to at
least show the actual viewport size in the status bar.

I'd expect something like:

$vps = [1280, 720]; // set viewport size

and a conditional expression to set it:

No, I don't think that's a good idea. It will potentially
break pretty much any export option that is not just single
image files. So I'd say this should be an option in the
export dialog or something, but not available in the script.

ciao,
Torsten.

> If some bigger change is made to brush up the animation > interface, please also provide a possiblity to programmatically > set the physical framesize. The method I use now is to set > the viewport size with the mouse, which is very cumbersome. > Or did I miss something? > That's unfortunately a different can of worms as it needs an off-screen renderer driven by the GUI application. So while related, it's probably better to leave that separate. This also would help with simple image export too (I think there's also an issue for that already). As this is a bigger topic, the workaround for now is to at least show the actual viewport size in the status bar. > I'd expect something like: > > $vps = [1280, 720]; // set viewport size > and a conditional expression to set it: > No, I don't think that's a good idea. It will potentially break pretty much any export option that is not just single image files. So I'd say this should be an option in the export dialog or something, but not available in the script. ciao, Torsten.

P

Parkinbot

Tue, Apr 25, 2017 3:36 PM

tp3 wrote

That's unfortunately a different can of worms as it needs an
off-screen renderer driven by the GUI application.

You are right, an offscreen renderer would be the technically most perfect
way to realize it, because it would even allow for 4K output in batch mode.
But I didn't mean it like that.
Why not restrict it to GUI sessions and directly control the viewport size -
exactly in the way, it is done with the mouse. Wouldn't it then be just like
setting $vpt, $vpr and $vpd, which I guess also doesn't have any effect when
used in batch mode?
For now I have to fidget with the mouse to first adjust the console pane and
then the editor pane to adopt the viewport size for image export. $vps =
[1280,720]; could have exactly this semantics.

BTW, the size information is already displayed in the status line.

--
View this message in context: http://forum.openscad.org/Animation-manually-triggered-tp21347p21377.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

tp3 wrote > That's unfortunately a different can of worms as it needs an > off-screen renderer driven by the GUI application. You are right, an offscreen renderer would be the technically most perfect way to realize it, because it would even allow for 4K output in batch mode. But I didn't mean it like that. Why not restrict it to GUI sessions and directly control the viewport size - exactly in the way, it is done with the mouse. Wouldn't it then be just like setting $vpt, $vpr and $vpd, which I guess also doesn't have any effect when used in batch mode? For now I have to fidget with the mouse to first adjust the console pane and then the editor pane to adopt the viewport size for image export. $vps = [1280,720]; could have exactly this semantics. BTW, the size information is already displayed in the status line. -- View this message in context: http://forum.openscad.org/Animation-manually-triggered-tp21347p21377.html Sent from the OpenSCAD mailing list archive at Nabble.com.

TP

Torsten Paul

Tue, Apr 25, 2017 7:10 PM

On 04/25/2017 05:36 PM, Parkinbot wrote:

Why not restrict it to GUI sessions and directly control the viewport size -
exactly in the way, it is done with the mouse. Wouldn't it then be just like
setting $vpt, $vpr and $vpd, which I guess also doesn't have any effect when
used in batch mode?

I tried that, but it did not really work reliable to force a specific
viewport size without messing up the rest of the UI. Maybe someone with
more Qt knowledge could give it a try...

We actually have an Off-Screen context which is used in command line mode,
so the challenge is to make this usable for the GUI too.

ciao,
Torsten.

On 04/25/2017 05:36 PM, Parkinbot wrote: > Why not restrict it to GUI sessions and directly control the viewport size - > exactly in the way, it is done with the mouse. Wouldn't it then be just like > setting $vpt, $vpr and $vpd, which I guess also doesn't have any effect when > used in batch mode? > I tried that, but it did not really work reliable to force a specific viewport size without messing up the rest of the UI. Maybe someone with more Qt knowledge could give it a try... We actually have an Off-Screen context which is used in command line mode, so the challenge is to make this usable for the GUI too. ciao, Torsten.

P

Parkinbot

Tue, Apr 25, 2017 8:05 PM

tp3 wrote

I tried that, but it did not really work reliable to force a specific
viewport size without messing up the rest of the UI. Maybe someone with
more Qt knowledge could give it a try...

have a look at this
http://stackoverflow.com/questions/10758267/how-to-force-layout-update-resize-when-child-it-manages-resizes

tp3 wrote

We actually have an Off-Screen context which is used in command line mode,
so the challenge is to make this usable for the GUI too.

I don't think that an Off-Sceen context will be a good solution. Being sized
differently it will show a different szene and you run into trouble to
synchronize the views to get at least some WYSIWG.

--
View this message in context: http://forum.openscad.org/Animation-manually-triggered-tp21347p21380.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

tp3 wrote > I tried that, but it did not really work reliable to force a specific > viewport size without messing up the rest of the UI. Maybe someone with > more Qt knowledge could give it a try... have a look at this http://stackoverflow.com/questions/10758267/how-to-force-layout-update-resize-when-child-it-manages-resizes tp3 wrote > We actually have an Off-Screen context which is used in command line mode, > so the challenge is to make this usable for the GUI too. I don't think that an Off-Sceen context will be a good solution. Being sized differently it will show a different szene and you run into trouble to synchronize the views to get at least some WYSIWG. -- View this message in context: http://forum.openscad.org/Animation-manually-triggered-tp21347p21380.html Sent from the OpenSCAD mailing list archive at Nabble.com.

discuss@lists.openscad.org

Animation manually triggered