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

[Daniel J S. <dan...@ie...>]

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. 
Was there something introduced to the hidden3d algorithm that uses the 
coordinate-set for the pm3d elements?

After running the hidden2.dem demo, type:

set hidden3d back
replot

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

It's a creative way of simulating what we actually want, which is true 
hidden surface behavior.  But if it becomes too manually configurable 
and meticulous, the user will likely find other ways to accomplish the 
same thing via function definitions or whatnot.

All I'm saying is that I think this is more of a hidden3d feature than 
it is a pm3d feature.  The hidden3d -2 surface is creating a hole in the 
mesh to allow whatever is behind it to show through.  It requires the 
user to think through things a bit.


> [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?

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
>

-- 

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