Re: Any last-minute fixes or requests for inclusion in 4.6.2?

[Ethan A M. <eam...@gm...>]

On Sunday, 10 March 2013, Daniel J Sebald wrote:
> On 03/10/2013 04:22 PM, Ethan Merritt wrote:
> > On Sunday, 10 March 2013, Daniel J Sebald wrote:
> >> On 03/10/2013 12:14 AM, sfeam (Ethan Merritt) wrote:
> >>> Anyone know of an unresolved 4.6 bug that should be fixed before
> >>> releasing 4.6.2?   If not, I plan to put the usual source tarball
> >>> on SourceForge later this week.
> >>
> >> The one concern is the description for this new item:
> >>
> >>> * NEW hidden3d can handle occlusion by pm3d surfaces (as in hidden2.dem)
> >>
> >> which seems to me like overselling things a bit.  pm3d has always
> >> occluded whatever is behind it, so that is not new.
> >
> > That's not true.  Up until now the non-pm3d lines handled by hidden3d
> > ignored the pm3d surface altogether, so they would appear on top in
> > the rendered image regardless of whether they should have been in front
> > or behind the pm3d surface.  Now the behind portions are correctly
> > not drawn.
> 
> But it is not the pm3d elements that are in the algorithm.  It is the 
> invisible lines that are forcing the behind portions to not be drawn. 

Correct.

> Was there something introduced to the hidden3d algorithm that uses the 
> coordinate-set for the pm3d elements?

Yes.  The same work-around in the hidden2d demo (draw invisble lines
for the same surface as the pm3d version) was moved into the code
itself.

> After running the hidden2.dem demo, type:

The point is that the manual work-around in the the hidden2 demo
is no longer required.  The code does it for you.
It is true that the work-around is still not perfect, whether 
manual or automatic.

> set hidden3d back
> replot
> 
> and it is clear that the difference is the order in which pm3d surface 
> and hidden3d elements are drawn.

The invisible lines approach only works for "set hidden3d front".

> > [snip]
> >> What would really be desirable is the ability to specify which surfaces
> >> should occlude and which shouldn't.  I actually think that is a very
> >> useful feature to have.
> >
> > That would be the existing "nohidden" keyword, if I'm understanding
> > you correctly.
> 
> Maybe, I'm not sure.  I type "help nohidden" which displays the help for 
> "set hidden3d".  So "hidden" is the same as "hidden3d"?  And "set 
> nohidden3d" means to turn off hidden3d?

 set hidden3d
 splot A, B nohidden, C
means to include A and C in the hidden3d calculations but treat
B without regard to hidden3d.

	Ethan

> I would say it is not the same.  "nohidden3d" will just show every mesh 
> line.  What I'm suggesting is that each plot "surface" or "mesh" can 
> have its hiding capability controlled separately.  That would be doable 
> if we have full and complete hidden 3D capability.
> 
> This raises another interesting question.  Say we were to integrate 
> surfaces into the hidden3d capability.  Right now hidden3d removes the 
> mesh pieces that are hidden.  Could it be possible to keep those mesh 
> pieces and somehow combine them with the alpha-mixing of the surface 
> elements?  Might make for an interesting plot.
> 
> Dan
> 
> 
> 
> >
> > 	Ethan
> >
> >
> >
> >> That way one could specify an interior surface
> >> that should always show through, which is what the hidden2d example
> >> effectively doing as observed.  So, here might be how that works:
> >>
> >> set hidden3d
> >> f(x,y) = sin(-sqrt((x+5)**2+(y-7)**2)*0.5)
> >> splot f(x,y) with pm3d solid, \
> >>         x*x-y*y with lines lt 1 lc rgb "#000000" transparent
> >>
> >>
> >> Well, in summary, rather than describing this as a pm3d-related feature,
> >> how about
> >>
> >>    * NEW hidden3d invisible lines for simulated surface occlusion (as in
> >> hidden2.dem)
> >>
> >> Dan
> >>
> >> ------------------------------------------------------------------------------
> >> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> >> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> >> endpoint security space. For insight on selecting the right partner to
> >> tackle endpoint security challenges, access the full report.
> >> http://p.sf.net/sfu/symantec-dev2dev
> >> _______________________________________________
> >> gnuplot-beta mailing list
> >> gnu...@li...
> >> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> >>
> >
> >
> > ------------------------------------------------------------------------------
> > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> > endpoint security space. For insight on selecting the right partner to
> > tackle endpoint security challenges, access the full report.
> > http://p.sf.net/sfu/symantec-dev2dev
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> >
> 
> 


-- 
Tradition is not the worship of ashes, but the preservation of fire.
  - Gustav Mahler