'nohidden3d' option behavior

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

'nohidden3d' option behavior

Daniel J Sebald
I've read through the documentation for the option "with ...
nohidden3d".  My initial understanding of the nohidden3d option is that
it could be a means to individually select what items are included in
hidden line removal:

"
  As of gnuplot version 4.6, hidden3d also affects 3D plotting styles
`points`,
  `labels`, `vectors`, and `impulses` even if no surface is present in
the graph.
  Unobscured portions of each vector are drawn as line segments (no
arrowheads).
  Individual plots within the graph may be explicitly excluded from this
  processing by appending the extra option `nohidden3d` to the `with`
specifier.
"

I'm not sure how "even if no surface is present in the graph" is to be
interpreted.  I take it to mean there is something in plots, currently,
other than surfaces which can have a 2D subspace that obscures the
visual field.

More than that though is this phrase "excluded from this processing".
It's ambiguous as to what "this processing" applies to.  There are two
ways to take this:

1) "nohidden3d" applies to any object because "individual plots" would
include anything.

2) "nohidden3d" only applies to points, labels, vectors and impulses.

My initial thought was that 1 is the case, but the current version of
gnuplot does nothing to "with lines" objects when 'with ... nohidden3d'
is specified.  The "with lines nohidden3d" still has hidden3d effects.
So, 2 seems more the case and to confirm that, here is the code from
plot3d.c:

            /* Rule out incompatible line/point/style options */
            if (this_plot->plot_type == FUNC3D) {
                if ((this_plot->plot_style & PLOT_STYLE_HAS_POINT)
                &&  (this_plot->lp_properties.p_size == PTSZ_VARIABLE))
                    this_plot->lp_properties.p_size = 1;
            }
            if (this_plot->plot_style == LINES) {
                this_plot->opt_out_of_hidden3d = FALSE;
            }

My thought on this is, Why exclude lines from the "nohidden3d" option?
If no hidden 3d processing is done on the surface lines, would that pose
a problem?  Also, "LINES" is excluded, but why then not "LINESPOINTS"?

Just to illustrate, try these plots:

gnuplot> set samples 20
gnuplot> set hidden3d
gnuplot> splot 20*sin(x*y)/(x*y) with lines, x+y with lines nohidden3d

The above just illustrates that "lines" is unaffected by "nohidden3d".
Now try

gnuplot> splot 20*sin(x*y)/(x*y) with lines, x+y with lp nohidden3d

So, linespoints is affected.  However, although the points behave as
expected, the lines have disappeared.  Why should the lines disappear?
I would think the second plot should look very similar to this result:

gnuplot> unset hidden3d
gnuplot> splot 20*sin(x*y)/(x*y) with lines, x+y with lp

Again to illustrate the disappearing lines, try:

gnuplot> set hidden3d
gnuplot> splot 20*sin(x*y)/(x*y) with linespoints nohidden3d
          *All* edges undefined or out of range, thus no plot.

Maybe the current behavior isn't the intended behavior, but I'm not
fully comprehending the nohidden3d option.

Dan


------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: 'nohidden3d' option behavior

sfeam
On Monday, 23 May, 2016 18:24:39 Daniel J Sebald wrote:

> I've read through the documentation for the option "with ...
> nohidden3d".  My initial understanding of the nohidden3d option is that
> it could be a means to individually select what items are included in
> hidden line removal:
>
> "
>   As of gnuplot version 4.6, hidden3d also affects 3D plotting styles
> `points`,
>   `labels`, `vectors`, and `impulses` even if no surface is present in
> the graph.
>   Unobscured portions of each vector are drawn as line segments (no
> arrowheads).
>   Individual plots within the graph may be explicitly excluded from this
>   processing by appending the extra option `nohidden3d` to the `with`
> specifier.
> "
>
> I'm not sure how "even if no surface is present in the graph" is to be
> interpreted.  I take it to mean there is something in plots, currently,
> other than surfaces which can have a 2D subspace that obscures the
> visual field.
>
> More than that though is this phrase "excluded from this processing".
> It's ambiguous as to what "this processing" applies to.

I'll reply in more detail later, but for now the key thing is that
"this processing" means "sorted together on depth (distance from viewer)".
I.e. even if there are no surfaces to obscure pieces of a vector,
it may still be useful to sort the vectors so that the close ones are
drawn on top of the further ones.  

If you attach the "nohidden3d" attribute to something then it isn't sorted
on depth.  All elements of that unsorted plot will appear in the same layer
(could be in front of; could be behind) the objects that were sorted together.

        Ethan



> There are two
> ways to take this:
>
> 1) "nohidden3d" applies to any object because "individual plots" would
> include anything.
>
> 2) "nohidden3d" only applies to points, labels, vectors and impulses.
>
> My initial thought was that 1 is the case, but the current version of
> gnuplot does nothing to "with lines" objects when 'with ... nohidden3d'
> is specified.  The "with lines nohidden3d" still has hidden3d effects.
> So, 2 seems more the case and to confirm that, here is the code from
> plot3d.c:
>
>    /* Rule out incompatible line/point/style options */
>    if (this_plot->plot_type == FUNC3D) {
> if ((this_plot->plot_style & PLOT_STYLE_HAS_POINT)
> &&  (this_plot->lp_properties.p_size == PTSZ_VARIABLE))
>    this_plot->lp_properties.p_size = 1;
>    }
>    if (this_plot->plot_style == LINES) {
> this_plot->opt_out_of_hidden3d = FALSE;
>    }
>
> My thought on this is, Why exclude lines from the "nohidden3d" option?
> If no hidden 3d processing is done on the surface lines, would that pose
> a problem?  Also, "LINES" is excluded, but why then not "LINESPOINTS"?
>
> Just to illustrate, try these plots:
>
> gnuplot> set samples 20
> gnuplot> set hidden3d
> gnuplot> splot 20*sin(x*y)/(x*y) with lines, x+y with lines nohidden3d
>
> The above just illustrates that "lines" is unaffected by "nohidden3d".
> Now try
>
> gnuplot> splot 20*sin(x*y)/(x*y) with lines, x+y with lp nohidden3d
>
> So, linespoints is affected.  However, although the points behave as
> expected, the lines have disappeared.  Why should the lines disappear?
> I would think the second plot should look very similar to this result:
>
> gnuplot> unset hidden3d
> gnuplot> splot 20*sin(x*y)/(x*y) with lines, x+y with lp
>
> Again to illustrate the disappearing lines, try:
>
> gnuplot> set hidden3d
> gnuplot> splot 20*sin(x*y)/(x*y) with linespoints nohidden3d
>           *All* edges undefined or out of range, thus no plot.
>
> Maybe the current behavior isn't the intended behavior, but I'm not
> fully comprehending the nohidden3d option.
>
> Dan
>
>
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> _______________________________________________
> gnuplot-beta mailing list
> [hidden email]
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta


------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: 'nohidden3d' option behavior

Daniel J Sebald
On 05/23/2016 06:35 PM, Ethan A Merritt wrote:

> On Monday, 23 May, 2016 18:24:39 Daniel J Sebald wrote:
>> I've read through the documentation for the option "with ...
>> nohidden3d".  My initial understanding of the nohidden3d option is that
>> it could be a means to individually select what items are included in
>> hidden line removal:
>>
>> "
>>    As of gnuplot version 4.6, hidden3d also affects 3D plotting styles
>> `points`,
>>    `labels`, `vectors`, and `impulses` even if no surface is present in
>> the graph.
>>    Unobscured portions of each vector are drawn as line segments (no
>> arrowheads).
>>    Individual plots within the graph may be explicitly excluded from this
>>    processing by appending the extra option `nohidden3d` to the `with`
>> specifier.
>> "
>>
>> I'm not sure how "even if no surface is present in the graph" is to be
>> interpreted.  I take it to mean there is something in plots, currently,
>> other than surfaces which can have a 2D subspace that obscures the
>> visual field.
>>
>> More than that though is this phrase "excluded from this processing".
>> It's ambiguous as to what "this processing" applies to.
>
> I'll reply in more detail later, but for now the key thing is that
> "this processing" means "sorted together on depth (distance from viewer)".
> I.e. even if there are no surfaces to obscure pieces of a vector,
> it may still be useful to sort the vectors so that the close ones are
> drawn on top of the further ones.

OK, I suppose that makes sense.  Typically I think of the hidden3d
processing as bisecting or segmenting, but yeah it could be useful to
order things.


> If you attach the "nohidden3d" attribute to something then it isn't sorted
> on depth.  All elements of that unsorted plot will appear in the same layer
> (could be in front of; could be behind) the objects that were sorted together.

Meaning that the lines of linespoints are disappearing because somehow
the algorithm thinks the lines are fully obscured because at every
endpoint of the line is covered by a point?  Hence, there are only
points left and no edges so the error message?

I just altered the code to allow LINES to go on through to the rest of
the nohidden3d list.  That still produces an error even though there are
no obscuring points coinciding with the lines:

[ALTERED CODE RESULT]
gnuplot> set samples 20
gnuplot> set hidden3d
gnuplot> splot 20*sin(x*y)/(x*y) with lines nohidden3d
          *All* edges undefined or out of range, thus no plot.

Well, I can work around the use of "nohidden3d" for what I'm programming
by adding some extra logic; it's just that it would be convenient if
nohidden3d applied to lines.

Dan

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: 'nohidden3d' option behavior

sfeam
On Monday, 23 May 2016 07:01:11 PM Daniel J Sebald wrote:

> On 05/23/2016 06:35 PM, Ethan A Merritt wrote:
> > On Monday, 23 May, 2016 18:24:39 Daniel J Sebald wrote:
> >> I've read through the documentation for the option "with ...
> >> nohidden3d".  My initial understanding of the nohidden3d option is that
> >> it could be a means to individually select what items are included in
> >> hidden line removal:
> >>
> >> "
> >>    As of gnuplot version 4.6, hidden3d also affects 3D plotting styles
> >> `points`,
> >>    `labels`, `vectors`, and `impulses` even if no surface is present in
> >> the graph.
> >>    Unobscured portions of each vector are drawn as line segments (no
> >> arrowheads).
> >>    Individual plots within the graph may be explicitly excluded from this
> >>    processing by appending the extra option `nohidden3d` to the `with`
> >> specifier.
> >> "
> >>
> >> I'm not sure how "even if no surface is present in the graph" is to be
> >> interpreted.  I take it to mean there is something in plots, currently,
> >> other than surfaces which can have a 2D subspace that obscures the
> >> visual field.
> >>
> >> More than that though is this phrase "excluded from this processing".
> >> It's ambiguous as to what "this processing" applies to.
> >
> > I'll reply in more detail later, but for now the key thing is that
> > "this processing" means "sorted together on depth (distance from viewer)".
> > I.e. even if there are no surfaces to obscure pieces of a vector,
> > it may still be useful to sort the vectors so that the close ones are
> > drawn on top of the further ones.
>
> OK, I suppose that makes sense.  Typically I think of the hidden3d
> processing as bisecting or segmenting, but yeah it could be useful to
> order things.
>
>
> > If you attach the "nohidden3d" attribute to something then it isn't sorted
> > on depth.  All elements of that unsorted plot will appear in the same layer
> > (could be in front of; could be behind) the objects that were sorted together.
>
> Meaning that the lines of linespoints are disappearing because somehow
> the algorithm thinks the lines are fully obscured because at every
> endpoint of the line is covered by a point?  Hence, there are only
> points left and no edges so the error message?
>
> I just altered the code to allow LINES to go on through to the rest of
> the nohidden3d list.  That still produces an error even though there are
> no obscuring points coinciding with the lines:
>
> [ALTERED CODE RESULT]
> gnuplot> set samples 20
> gnuplot> set hidden3d
> gnuplot> splot 20*sin(x*y)/(x*y) with lines nohidden3d
>           *All* edges undefined or out of range, thus no plot.
>
> Well, I can work around the use of "nohidden3d" for what I'm programming
> by adding some extra logic; it's just that it would be convenient if
> nohidden3d applied to lines.


Can you describe what it is you are trying to plot, rather than listing
things that don't work?   I am failing to understand why you would ever
select hidden3d and then draw a surface that doesn't use it.
What is the goal?

        Ethan







------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: 'nohidden3d' option behavior

Daniel J Sebald
On 05/23/2016 10:52 PM, sfeam wrote:

> On Monday, 23 May 2016 07:01:11 PM Daniel J Sebald wrote:
>> On 05/23/2016 06:35 PM, Ethan A Merritt wrote:
>>> On Monday, 23 May, 2016 18:24:39 Daniel J Sebald wrote:
>>>> I've read through the documentation for the option "with ...
>>>> nohidden3d".  My initial understanding of the nohidden3d option is that
>>>> it could be a means to individually select what items are included in
>>>> hidden line removal:
>>>>
>>>> "
>>>>     As of gnuplot version 4.6, hidden3d also affects 3D plotting styles
>>>> `points`,
>>>>     `labels`, `vectors`, and `impulses` even if no surface is present in
>>>> the graph.
>>>>     Unobscured portions of each vector are drawn as line segments (no
>>>> arrowheads).
>>>>     Individual plots within the graph may be explicitly excluded from this
>>>>     processing by appending the extra option `nohidden3d` to the `with`
>>>> specifier.
>>>> "
>>>>
>>>> I'm not sure how "even if no surface is present in the graph" is to be
>>>> interpreted.  I take it to mean there is something in plots, currently,
>>>> other than surfaces which can have a 2D subspace that obscures the
>>>> visual field.
>>>>
>>>> More than that though is this phrase "excluded from this processing".
>>>> It's ambiguous as to what "this processing" applies to.
>>>
>>> I'll reply in more detail later, but for now the key thing is that
>>> "this processing" means "sorted together on depth (distance from viewer)".
>>> I.e. even if there are no surfaces to obscure pieces of a vector,
>>> it may still be useful to sort the vectors so that the close ones are
>>> drawn on top of the further ones.
>>
>> OK, I suppose that makes sense.  Typically I think of the hidden3d
>> processing as bisecting or segmenting, but yeah it could be useful to
>> order things.
>>
>>
>>> If you attach the "nohidden3d" attribute to something then it isn't sorted
>>> on depth.  All elements of that unsorted plot will appear in the same layer
>>> (could be in front of; could be behind) the objects that were sorted together.
>>
>> Meaning that the lines of linespoints are disappearing because somehow
>> the algorithm thinks the lines are fully obscured because at every
>> endpoint of the line is covered by a point?  Hence, there are only
>> points left and no edges so the error message?
>>
>> I just altered the code to allow LINES to go on through to the rest of
>> the nohidden3d list.  That still produces an error even though there are
>> no obscuring points coinciding with the lines:
>>
>> [ALTERED CODE RESULT]
>> gnuplot> set samples 20
>> gnuplot> set hidden3d
>> gnuplot> splot 20*sin(x*y)/(x*y) with lines nohidden3d
>>            *All* edges undefined or out of range, thus no plot.
>>
>> Well, I can work around the use of "nohidden3d" for what I'm programming
>> by adding some extra logic; it's just that it would be convenient if
>> nohidden3d applied to lines.
>
>
> Can you describe what it is you are trying to plot, rather than listing
> things that don't work?   I am failing to understand why you would ever
> select hidden3d and then draw a surface that doesn't use it.
> What is the goal?

I'm trying to generalize the hidden behavior of lines and surfaces for
Octave, and for the most part I've got all their demos working now by
backing off the use of "nohidden3d".  (Originally I thought that option
applied to mesh lines.)  But Octave's demos are pretty much simple
single surface/mesh types of things.

The problem of course comes with cases where there are multiple
surfaces, patches, etc.  Granted, that sort of thing doesn't arise too
often in practice, but it is a very easy thing to do in something like
Octave.  Octave treats meshes/surfaces that have no facecolor as
non-hidden.  So it is conceivable to have one surface that has a
facecolor and requires hidden line removal while another mesh doesn't.

What would be nice is finer control in gnuplot of what entities should
have hidden property and what shouldn't.  Also to create groups or
families of hidden objects.  And then those groups might interact too.
Add in true hidden surface removal.  Sounds overblown, but sometimes it
isn't too difficult building an object-oriented hierarchy and leave the
arrangement up to the user.  Big project.

Anyway, I'm not too concerned about this for the moment now that I have
reasonably good behavior without the need for "nohidden3d".

Dan

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: 'nohidden3d' option behavior

Daniel J Sebald
In reply to this post by sfeam
On 05/23/2016 10:52 PM, sfeam wrote:
[snip]
> Can you describe what it is you are trying to plot, rather than listing
> things that don't work?   I am failing to understand why you would ever
> select hidden3d and then draw a surface that doesn't use it.
> What is the goal?

I looked through the code a bit.  Attached is a short patch that allows
LINES to continue onward and corrects what I think is an oversight.  To
test, apply the patch, compile and then run something like:

set hidden3d front nooffset
splot 20*sin(x*y)/(x*y) with lines, x+y with linespoints nohidden3d
splot x+y with lines nohidden3d

This should show lines now (but isolines are missing and I can't figure
out why), and in the second splot give a warning but continue on plotting.

The reason I think it should be the following (or no test at all, see below)

     /* These are handled elsewhere.  */
     if (plot->has_grid_topology && !plot->opt_out_of_hidden3d && hidden3d)
        return;

is that if one looks at where the plot3d_lines_pm3d() function is called
in graph3d.c, there's a check on opt_out_of_hidden3d:

                if (draw_this_surface) {
                    if (!hidden3d || this_plot->opt_out_of_hidden3d)
                        plot3d_lines_pm3d(this_plot);
                }

So, there is a more stringent test within the subroutine than there is
in the calling code without the change I'm suggesting.  Note that the
same sort of setup exists for plot3d_points(), and there is no test on
the hidden property within that routine.  Similarly, there probably
doesn't need to be a test at all within plot3d_lines_pm3d() either.  At
least one of the items is already confirmed prior to being called.

Well, that's about all the change I would want to make for this.  If the
attached changes make things clear and seem worth pursuing, I will
create a bug report.

Dan


------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

gnuplot-allow_nohidden3d_lines-djs2016may23.diff (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 'nohidden3d' option behavior

sfeam
On Tuesday, 24 May, 2016 02:13:45 Daniel J Sebald wrote:

> On 05/23/2016 10:52 PM, sfeam wrote:
> [snip]
> > Can you describe what it is you are trying to plot, rather than listing
> > things that don't work?   I am failing to understand why you would ever
> > select hidden3d and then draw a surface that doesn't use it.
> > What is the goal?
>
> I looked through the code a bit.  Attached is a short patch that allows
> LINES to continue onward and corrects what I think is an oversight.  To
> test, apply the patch, compile and then run something like:
>
> set hidden3d front nooffset
> splot 20*sin(x*y)/(x*y) with lines, x+y with linespoints nohidden3d
> splot x+y with lines nohidden3d
>
> This should show lines now (but isolines are missing and I can't figure
> out why), and in the second splot give a warning but continue on plotting.

I still do not see the rationale for selecting "hidden3d" and then turning
it off for a surface.  (Yeah it's a bit confusing that "lines" really means
"surface" in this context).   So if there is a bug in what you have shown
so far, I would say it is the treatment of the points in a "linespoints" plot.
I would expect them to be treated as part of the surface and hence not
eligible for "nohidden3d".

I.e.,  I can understand for example wanting to attach "nohidden3d" to
labels so that a label is visible even if the node it is attached to is
considered to be on the back of the surface rather than the front of the
surface.  Similarly for individual points when they are functioning as
special markers rather than part of the surface grid.
But I don't see the validity of excluding whole surfaces.

Basically "nohidden3d" is there to handle special cases like labels.
I would have expected it to be rarely used in practice.  The more common
problem has been things that are unexpectedly omitted from the hidden3d
calculation, e.g. images (hidden3d processing added only recently) or
individual filled polygons defined via "set object".


        Ethan


>
> The reason I think it should be the following (or no test at all, see below)
>
>      /* These are handled elsewhere.  */
>      if (plot->has_grid_topology && !plot->opt_out_of_hidden3d && hidden3d)
> return;
>
> is that if one looks at where the plot3d_lines_pm3d() function is called
> in graph3d.c, there's a check on opt_out_of_hidden3d:
>
> if (draw_this_surface) {
>    if (!hidden3d || this_plot->opt_out_of_hidden3d)
> plot3d_lines_pm3d(this_plot);
> }
>
> So, there is a more stringent test within the subroutine than there is
> in the calling code without the change I'm suggesting.  Note that the
> same sort of setup exists for plot3d_points(), and there is no test on
> the hidden property within that routine.  Similarly, there probably
> doesn't need to be a test at all within plot3d_lines_pm3d() either.  At
> least one of the items is already confirmed prior to being called.
>
> Well, that's about all the change I would want to make for this.  If the
> attached changes make things clear and seem worth pursuing, I will
> create a bug report.
>
> Dan
>


------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: 'nohidden3d' option behavior

Daniel J Sebald
On 05/24/2016 11:47 AM, Ethan A Merritt wrote:

> On Tuesday, 24 May, 2016 02:13:45 Daniel J Sebald wrote:
>> On 05/23/2016 10:52 PM, sfeam wrote:
>> [snip]
>>> Can you describe what it is you are trying to plot, rather than listing
>>> things that don't work?   I am failing to understand why you would ever
>>> select hidden3d and then draw a surface that doesn't use it.
>>> What is the goal?
>>
>> I looked through the code a bit.  Attached is a short patch that allows
>> LINES to continue onward and corrects what I think is an oversight.  To
>> test, apply the patch, compile and then run something like:
>>
>> set hidden3d front nooffset
>> splot 20*sin(x*y)/(x*y) with lines, x+y with linespoints nohidden3d
>> splot x+y with lines nohidden3d
>>
>> This should show lines now (but isolines are missing and I can't figure
>> out why), and in the second splot give a warning but continue on plotting.
>
> I still do not see the rationale for selecting "hidden3d" and then turning
> it off for a surface.  (Yeah it's a bit confusing that "lines" really means
> "surface" in this context).

Yes, and I think this is the source of the problem.  Really, what I'm
interested in is not technically excluding a mesh "surface" from
hidden3d processing but more something that doesn't treat isoline
surfaces as being solid--yet those isolines can be hidden by other solid
surface elements.  So, that's really what the issue is--i.e., gnuplot
automatically casts the wire mesh to solid surface in hidden3d mode.
That is, one can't have a wire mesh in hidden3d mode.

To reiterate, consider if gnuplot had a true hidden surface algorithm
added to the hidden3d code.  One can think of pm3d or images or patches
as having solid surfaces as we've sort of added support for those.
Images and patches though are easy because these are flat and hence work
within the existing hidden3d framework with just a bit of effort.  If
there were a hidden3d surface, the current behavior of mesh-with-"unset
hidden3d" / solid-surface-with-"set hidden3d" could be separated.  That
is, a mesh would be see-through no matter if it is hidden3d or not
hidden3d--the nice thing about gnuplot is that it has a unique color per
side of the mesh that helps comprehend how the surface traverses 3D
space from the viewer's perspective.  The true hidden surface algorithm
would then be capable of obstructing the mesh, it's just that the mesh
doesn't obstruct the view of other things.  [Question, can this
currently be achieved by the use of alpha-blending with a value of 0?
Maybe that is what I should be using rather than "nohidden3d".]  If that
were the way gnuplot behaved, then it would be possible to create the
current behavior by combining a wire mesh and solid surface using the
same formula or data on the same plot.


>    So if there is a bug in what you have shown
> so far, I would say it is the treatment of the points in a "linespoints" plot.
> I would expect them to be treated as part of the surface and hence not
> eligible for "nohidden3d".

Yeah, I think I'm coming around to your way of thinking on this.
"linespoints", "lines", or anything really that has a spatial geometric
relationship to other objects in the plotting space shouldn't be
excluded from hidden3d.  I'm wondering whether hidden3d should simply
always be on by default and we introduce a wire mesh object that does
not obstruct things behind it.  That is, we'd have a "with surface" and
"with mesh" which have striking similarity but subtle difference
regarding hidden3d behavior.  That way, users wouldn't be using the
global "hidden3d" to fine tune hidden behavior, they'd simply be
plotting a different type of object.


> I.e.,  I can understand for example wanting to attach "nohidden3d" to
> labels so that a label is visible even if the node it is attached to is
> considered to be on the back of the surface rather than the front of the
> surface.  Similarly for individual points when they are functioning as
> special markers rather than part of the surface grid.
> But I don't see the validity of excluding whole surfaces.
>
> Basically "nohidden3d" is there to handle special cases like labels.
> I would have expected it to be rarely used in practice.  The more common
> problem has been things that are unexpectedly omitted from the hidden3d
> calculation, e.g. images (hidden3d processing added only recently) or
> individual filled polygons defined via "set object".

We've added some of those, but that's possible because of the flat
surface these have thereby simplifying the hidden3d surface problem.

But yes, for labels, OK.  I mean, I typically am against restricting
some feature.  That is, gnuplot includes bits of code like

-    if (this_plot->plot_style == LINES) {
- this_plot->opt_out_of_hidden3d = FALSE;
-    }

that make me wonder, Why take that flexibility away from the user?  Just
let the user handle that.  But I can see now that this feature extended
to a broader object base would just make a confusing mess of things.

And, again, just for labels this makes sense.  I would think it
shouldn't be allowed for arrows because that too is confusing--rather
than the arrow pointing to something on the hidden side of a solid
surface, it would appear the arrow is pointing to the front of the solid
surface.  Also, what's the exact intent of having this option for
labels?  I would think it isn't for having some completely obscured
arrow/label appearing in front of everything else, but instead something
where if a label is partially visible or its associated arrow is
partially visible, the label should be made completely visible (rather
than possibly not drawn).  Could more clarity be added to the description?

"
   As of gnuplot version 4.6, hidden3d also affects 3D plotting styles
`points`,
   `labels`, `vectors`, and `impulses` even if no surface is present in
the graph.
   Unobscured portions of each vector are drawn as line segments (no
arrowheads).
   Individual plots within the graph may be explicitly excluded from this
   processing by appending the extra option `nohidden3d` to the `with`
specifier.
"

1) Remove the "As of gnuplot version 4.6".  It emphasizes the feature
making me think this is more broad and significant than it is.

2) "Individual plots within the graph": Is it meant "Individual plots
having only a type `points`, `labels`, `vectors`, and `impulses`?  As
opposed to all plots of any type?

3) What does "even if no surface is present in the graph" mean?

4) Might there be a more descriptive word for this option than
"nohidden3d"?  Is the intended purpose for fine-tuning label behavior of
those on the border of being or not being obscured by some other solid
or opaque (i.e., adjusting its drawing order)?

Dan


>
>
> Ethan
>
>
>>
>> The reason I think it should be the following (or no test at all, see below)
>>
>>       /* These are handled elsewhere.  */
>>       if (plot->has_grid_topology && !plot->opt_out_of_hidden3d && hidden3d)
>> return;
>>
>> is that if one looks at where the plot3d_lines_pm3d() function is called
>> in graph3d.c, there's a check on opt_out_of_hidden3d:
>>
>> if (draw_this_surface) {
>>    if (!hidden3d || this_plot->opt_out_of_hidden3d)
>> plot3d_lines_pm3d(this_plot);
>> }
>>
>> So, there is a more stringent test within the subroutine than there is
>> in the calling code without the change I'm suggesting.  Note that the
>> same sort of setup exists for plot3d_points(), and there is no test on
>> the hidden property within that routine.  Similarly, there probably
>> doesn't need to be a test at all within plot3d_lines_pm3d() either.  At
>> least one of the items is already confirmed prior to being called.
>>
>> Well, that's about all the change I would want to make for this.  If the
>> attached changes make things clear and seem worth pursuing, I will
>> create a bug report.
>>
>> Dan
>>
>
>

--

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: 'nohidden3d' option behavior

sfeam
On Wednesday, 25 May, 2016 13:58:32 Daniel J Sebald wrote:
> On 05/24/2016 11:47 AM, Ethan A Merritt wrote:

> > I still do not see the rationale for selecting "hidden3d" and then turning
> > it off for a surface.  (Yeah it's a bit confusing that "lines" really means
> > "surface" in this context).
>
> Yes, and I think this is the source of the problem.  Really, what I'm
> interested in is not technically excluding a mesh "surface" from
> hidden3d processing but more something that doesn't treat isoline
> surfaces as being solid--yet those isolines can be hidden by other solid
> surface elements.  So, that's really what the issue is--i.e., gnuplot
> automatically casts the wire mesh to solid surface in hidden3d mode.

> That is, one can't have a wire mesh in hidden3d mode.

It turns out that you can, so long as you input the lines in such a
way that they are not automatically converted into a surface.

For example:

# This doesn't do what you want - both plot elements are treated as surfaces
set hidden3d
splot x*y, 3


# But if we write out one plot and read it back in as separate lines,
# the result is different because it is no longer treated as a surface.

set hidden3d
set table 'foo'
splot 3
unset table
splot x*y, for [i=0:*] 'foo' every 1:1:0:i::i lt 3 lw 3 notitle

Of course since it is not treated as a surface, no isosample lines
running the other way are generated.  If you want those you have
to do something clever that transposes x and y at some stage.
So here goes an example that does exactly what you want:

%%%%%%%%% mesh.dem %%%%%%%%%%%%

set hidden3d
set xrange [-10:10]
set yrange [-10:10]

f(x,y) = x*y
g(x,y) = 3

set table 'foo'
splot '++' using 1:2:(f($1,$2))
set table 'baz'
splot '++' using 2:1:(f($1,$2))
unset table
unset key

splot for [i=0:*] 'foo' every 1:1:0:i::i with lines lt 1, \
      for [i=0:*] 'baz' every 1:1:0:i::i with lines lt 1, \
      g(x,y) lt 3 lw 3

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

   cheers,

      Ethan

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: 'nohidden3d' option behavior

Daniel J Sebald
On 05/27/2016 03:38 PM, Ethan A Merritt wrote:

> On Wednesday, 25 May, 2016 13:58:32 Daniel J Sebald wrote:
>> On 05/24/2016 11:47 AM, Ethan A Merritt wrote:
>
>>> I still do not see the rationale for selecting "hidden3d" and then turning
>>> it off for a surface.  (Yeah it's a bit confusing that "lines" really means
>>> "surface" in this context).
>>
>> Yes, and I think this is the source of the problem.  Really, what I'm
>> interested in is not technically excluding a mesh "surface" from
>> hidden3d processing but more something that doesn't treat isoline
>> surfaces as being solid--yet those isolines can be hidden by other solid
>> surface elements.  So, that's really what the issue is--i.e., gnuplot
>> automatically casts the wire mesh to solid surface in hidden3d mode.
>
>> That is, one can't have a wire mesh in hidden3d mode.
>
> It turns out that you can, so long as you input the lines in such a
> way that they are not automatically converted into a surface.
>
> For example:
>
> # This doesn't do what you want - both plot elements are treated as surfaces
> set hidden3d
> splot x*y, 3
>
>
> # But if we write out one plot and read it back in as separate lines,
> # the result is different because it is no longer treated as a surface.
>
> set hidden3d
> set table 'foo'
> splot 3
> unset table
> splot x*y, for [i=0:*] 'foo' every 1:1:0:i::i lt 3 lw 3 notitle
>
> Of course since it is not treated as a surface, no isosample lines
> running the other way are generated.  If you want those you have
> to do something clever that transposes x and y at some stage.
> So here goes an example that does exactly what you want:
>
> %%%%%%%%% mesh.dem %%%%%%%%%%%%
>
> set hidden3d
> set xrange [-10:10]
> set yrange [-10:10]
>
> f(x,y) = x*y
> g(x,y) = 3
>
> set table 'foo'
> splot '++' using 1:2:(f($1,$2))
> set table 'baz'
> splot '++' using 2:1:(f($1,$2))
> unset table
> unset key
>
> splot for [i=0:*] 'foo' every 1:1:0:i::i with lines lt 1, \
>        for [i=0:*] 'baz' every 1:1:0:i::i with lines lt 1, \
>        g(x,y) lt 3 lw 3
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
>     cheers,
>
>        Ethan
>

I sort of went down this route implementing a "waterfall" plot (i.e.,
isolines in only one direction).  That is, Octave's setting is

>> set(kids, 'meshstyle')
[ {both} | column | row ]

I used the existing code for the 'both' and then implemented either
column and row by repeating data in pairs (think of a surface having
zero width).  I suppose I could just toss the 'both' case and implement
both column and row if 'both' is selected.  That's effectively your example.

I'm working on something else at the moment, but I was going to send a
short example of waterfall meshes that could be added to the gnuplot
demos.  Add a more interesting function to your example and 'foo' only
for one direction, 'baz' only for the other direction, and that's the
example.

Thanks,

Dan

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: 'nohidden3d' option behavior

Hans-Bernhard Bröker-2
In reply to this post by Daniel J Sebald
Guys,

is it possible you've just totally forgotten about 'set surface explicit'?

It seems 'hidden3d' was never told about it, but in principle, that's
the command that should make the change Dan is looking for, i.e. it
could sensibly be expected that

        set surface explicit
        set hidden3d
        splot x*y w surface, x*sin(y) w lines

should yield a plot where the first graph is a hidden (and hiding)
surface mesh, whereas the second is not just the usual pair of wire grills.



------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: 'nohidden3d' option behavior

Daniel J Sebald
On 05/28/2016 01:55 PM, Hans-Bernhard Bröker wrote:
> Guys,
>
> is it possible you've just totally forgotten about 'set surface explicit'?

Yes.


> It seems 'hidden3d' was never told about it, but in principle, that's
> the command that should make the change Dan is looking for, i.e. it
> could sensibly be expected that
>
>      set surface explicit
>      set hidden3d
>      splot x*y w surface, x*sin(y) w lines
>
> should yield a plot where the first graph is a hidden (and hiding)
> surface mesh, whereas the second is not just the usual pair of wire grills.

The description for "help set surface" does sound like it will result in
a transparent mesh.  So, if this were to work as described, then putting
gnuplot into "set surface explicit" would be close to the behavior I'm
looking for, except there is no color surface control as is gained by
pm3d.  It would be nice to eventually just combine pm3d/surface.

Anyway, as you noted, your example doesn't work, but thanks.  Neither
does pulling the data in from a file:

   set surface explicit
   set hidden3d
   set table 'surfoos'
   splot x*y
   set table 'foomesh'
   splot x*sin(y)
   unset table
   splot 'surfoos' with surface, 'foomesh' with lines

The interesting thing to note about your example and the above is that
the surface orientation, color-wise, is the opposite direction.  One is
magenta and blue on "top" surfaces, the other is magenta and blue on
"bottom" surfaces.  Is that also a bug?

Dan

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: 'nohidden3d' option behavior

sfeam
In reply to this post by Hans-Bernhard Bröker-2
On Saturday, 28 May 2016 08:55:04 PM Hans-Bernhard Bröker wrote:

> Guys,
>
> is it possible you've just totally forgotten about 'set surface explicit'?
>
> It seems 'hidden3d' was never told about it, but in principle, that's
> the command that should make the change Dan is looking for, i.e. it
> could sensibly be expected that
>
> set surface explicit
> set hidden3d
> splot x*y w surface, x*sin(y) w lines
>
> should yield a plot where the first graph is a hidden (and hiding)
> surface mesh, whereas the second is not just the usual pair of wire grills.

I think  Dan was looking for options already present in older versions
of gnuplot so that he could produce Octave scripts that did not require
bleeding edge gnuplot support.  

But yes, if we teach the hidden3d code how to deal with a mesh that is not
actually a solid surface, that would be a logical syntax hook to attach it to.
I don't actually know how to do that, so it's pretty hypothetical at this point.

        Ethan



------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta