gnuplot-beta — Developers and beta testers of new gnuplot code

Re: [Gnuplot-info] maxima + gnupolot: 3D rendering bug?

[Alexandre F. <o.a...@gm...>]

When i said some test i was very vague, excuse-me, the test is a sequence of
triples (x,y,z), of several triangles, it's not a triangle strip, if you
send some different data please explain how i should interpret it.

Fwd: [Gnuplot-info] maxima + gnupolot: 3D rendering bug?

[Alexandre F. <o.a...@gm...>]

input:
-0.5    -0.5    1
1.2     1       3
1.2     -1      3
0.5     0.5     0.9
-1.2    -1      3.3
-1.2    1       3
e
output:
0.013636        -0.046791       1.6043
1.2     -1      3
0.05122 -0.66212        1.6485

-1.2    1       3
0.013636        -0.046791       1.6043
0.05122 -0.66212        1.6485

0.05122 -0.66212        1.6485
-0.5    -0.5    1
0.013636        -0.046791       1.6043

0.013636        -0.046791       1.6043
1.2     1       3
1.2     -1      3

0.5     0.5     0.9
0.05122 -0.66212        1.6485
0.013636        -0.046791       1.6043

0.05122 -0.66212        1.6485
-1.2    -1      3.3
-1.2    1       3
e

Re: [Gnuplot-info] maxima + gnupolot: 3D rendering bug?

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

Alexandre Felipe wrote:
> In Reply to Daniel:
> 
> Hiperplane? i think planes are enough, because any representation will be
> 3D, ignoring colors and any extra data, the only thing we do here is copy
> that data (and eventually interpolate it as mentioned above). Or we can call
> some function which will process the data such as colors.

A hyperplane is simply a general method of representing an N-1 dimensioned surface in a N dimensional space.  As an example, say we want to represent a line in 2D space.  We could pick two points to represent that line.  We could use the formula y = mx + b.  Or we could represent the line as w'v = b, where w = [1 -m]' and v = [y x]'.  Convenience more than anything.


> If we concern with the 3D problem i'd discovered fighting with my PC that
> matrixe algebra is not the better aproach. It's very good for
> transformations, or vectors with to many components, or even dynamic
> programming, but for geometric problems is better to use geometric solution.

For me, three dimensions is already too many components.  :-)

Dan

Re: [Gnuplot-info] maxima + gnupolot: 3D rendering bug?

[Hans-Bernhard B. <HBB...@t-...>]

On 12.12.2010 20:10, Ethan Merritt wrote:

> Is it possible that instead of modifying the pm3d code, one could modify
> the hidden-surface removal code in hidden3d?   The hidden3d code is
> already finding all the relevant lines of intersection and occlusion.

Actually, no.  hidden3d deals with hidden _line_ removal, only.  It has 
no code whatsoever for either sorting or splitting triangles.

> At the end of the hidden3d calculation there is a collection of edges,
> each of which is either all or part of an edge from the original set
> of polygons or an intersection of two polygons.  At that point the code
> walks through the list and draws all the edges.

Again, not really.  hidden3d draws individual surviving segments 
immediately when they're discovered (in_front() calls draw_edge() 
itself).  There is no complete list of visible edge fragments in memory 
at any time.

> Does it track enough information to also call term->filled_polygon()
> for each facet?

It doesn't even try to track facets.  It tracks edge fragments, not 
polygon fragments.

> If not, could the data structures be expanded to hold that tracking
> information?

"Expanding" wouldn't really do describing the job justice. It'd be more 
of a complete rewrite.

Re: [Gnuplot-info] maxima + gnupolot: 3D rendering bug?

[Alexandre F. <o.a...@gm...>]

In Reply to Daniel:

Hiperplane? i think planes are enough, because any representation will be
3D, ignoring colors and any extra data, the only thing we do here is copy
that data (and eventually interpolate it as mentioned above). Or we can call
some function which will process the data such as colors.

If we concern with the 3D problem i'd discovered fighting with my PC that
matrixe algebra is not the better aproach. It's very good for
transformations, or vectors with to many components, or even dynamic
programming, but for geometric problems is better to use geometric solution.

regarding the licence of the 3D class, there is no problem, since i writen
it from 0Byte, using pure C++, the only thing i didn't wrote was sqrt
function.

Re: [Gnuplot-info] maxima + gnupolot: 3D rendering bug?

[Ethan M. <merritt@u.washington.edu>]

On Sunday, December 12, 2010, Hans-Bernhard Bröker wrote:
> On 12.12.2010 16:51, Alexandre Felipe wrote:
> 
> > Find all the triangle pairs for wich the nearest vertex of firstis
> > nearer than the farthest of the vertexes of the second triangle, and the
> > farthest vertex of first is farther than the nearest of the vertexes of
> > the second triangle.
> [...]
> 
> You've pretty much re-invented the Newell-Newell-Sancha algorithm that 
> I've mentioned before, except that their textbook algorithm doesn't 
> split the job into two passes (first splitting, second sorting) like you 
> did.  That avoids a good deal of unnecessary splitting.

Is it possible that instead of modifying the pm3d code, one could modify
the hidden-surface removal code in hidden3d?   The hidden3d code is
already finding all the relevant lines of intersection and occlusion.
At the end of the hidden3d calculation there is a collection of edges,
each of which is either all or part of an edge from the original set
of polygons or an intersection of two polygons.  At that point the code
walks through the list and draws all the edges.  

Does it track enough information to also call term->filled_polygon()
for each facet?

If not, could the data structures be expanded to hold that tracking
information? 

Re: [Gnuplot-info] maxima + gnupolot: 3D rendering bug?

[Hans-Bernhard B. <HBB...@t-...>]

On 12.12.2010 16:51, Alexandre Felipe wrote:

> Find all the triangle pairs for wich the nearest vertex of firstis
> nearer than the farthest of the vertexes of the second triangle, and the
> farthest vertex of first is farther than the nearest of the vertexes of
> the second triangle.
[...]

You've pretty much re-invented the Newell-Newell-Sancha algorithm that 
I've mentioned before, except that their textbook algorithm doesn't 
split the job into two passes (first splitting, second sorting) like you 
did.  That avoids a good deal of unnecessary splitting.

> After proceeding in this way you can use any criteria to sort the
> triangles, i think this is the minimal algorithm, it takes about 1 days
> to be coded ant two or three to get working :D

If only.  You would be amazed at the kind of precision problems you'll 
run into with this algorithm in practice.  Just for starters, consider 
what all those tests will do with a pair of triangles that just so 
happen to share a vertex, or an edge.

Re: [Gnuplot-info] maxima + gnupolot: 3D rendering bug?

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

Alexandre Felipe wrote:
> "I had reached the conclusion that implementing the rendering by determining
> intersections of surfaces pretty much as defined might be the best place to
> put effort." - Daniel J Sebald
> 
> 
> Find all the triangle pairs for wich the nearest vertex of firstis nearer
> than the farthest of the vertexes of the second triangle, and the farthest
> vertex of first is farther than the nearest of the vertexes of the second
> triangle.
> 
> these are the ones who may need to be splited.
> 
> then take the planes containing the two triangles, intersect them, it can
> result an line (say Li), or a null intersection, in case of being a line,
> find all the intersections of Li with the triangles edges.
> it must be in the following sequence
> 
> enter triangle 1, exit triangle 1
> enter triangle 2, exit triangle 2
> 
> in all other cases, the triangles are splited in the line Li
> 
> After proceeding in this way you can use any criteria to sort the triangles,
> i think this is the minimal algorithm, it takes about 1 days to be coded ant
> two or three to get working :D

Yes, that is the main idea.  But this is a two week project, I believe.  The number of cases balloons when going from 2D to 3D.  First, one has to represent the triangles as planes (a hyperplane is always convenient).  There is some linear algebra associated with computing that.  Those would have to be saved with the triangle representations.  Then there is determining the line of interestection (probably an easy matrix inversion).  But there is the possibility of a singular matrix, which probably corresponds to the two planes being parallel.  So, one computes the line of intersection of the plane, then there is still the issue determining exactly where the intersection is in terms of the original triangles.  There is complete coverage, partial coverage, triangle broken into two pieces, etc.  And when the split occurs, a four sided polygon could result, which means that four sided polygon would have to be represented as two triangles.

It's easy envisioning how it would work, but doing it nicely is another issue.  Not something to embark on without a good plan and mathematical representation of the problem.


> I have a C++ 3D geometry class. but it uses overloaded operators
> (everywhere), with this class I am able to implement, i think, what i
> described above. if one want to translate the C++ to C and compile it i can
> spend some time for writing it, and send yet this week.

It would need proper licensing if it is a completed work.  Theory of operation is just as good.

Dan

Re: [Gnuplot-info] maxima + gnupolot: 3D rendering bug?

[Stanislav M. <sta...@gm...>]

Hello,

On Fri, Dec 10, 2010 at 10:06:52PM +0100, Petr Mikulik wrote:
> > > I suggest that a better approach would be to add a pass that splits large
> > > triangles into smaller pieces before sorting and rendering.
> > > The only tricky part is how to define "large".
> > 
> > I was thinking about exactly the same thing, but then realized that
> > there is already the "interpolate" option that does (almost) the same.
> 
> Does "pm3d interpolate x,y" works for you?

You mean, for that dataset that I submitted together with the patch?

I just tested it with "interpolate 0,0". As expected, interpolation
smoothens the surface and produces a better figure, but it still has
very noticeable artefacts (see the attached default.png). If I add
"corners2depth c3" the result is much better (c3.png). 

> Yes, this interpolation is some kind of smoothing because you add new 
> objects.
> 
> > of 4 corners, instead, it introduces a new pm3d option "corners2depth"
> > that allows for configurability of the depth sorting in a similar manner
> > as already existing "corners2color" option adds configurability
> 
> I think this option is useful.

Yes, with the curent rendering algorithm it is for sure useful.

--
Stanislav

Re: [Gnuplot-info] maxima + gnupolot: 3D rendering bug?

[Alexandre F. <o.a...@gm...>]

"I had reached the conclusion that implementing the rendering by determining
intersections of surfaces pretty much as defined might be the best place to
put effort." - Daniel J Sebald


Find all the triangle pairs for wich the nearest vertex of firstis nearer
than the farthest of the vertexes of the second triangle, and the farthest
vertex of first is farther than the nearest of the vertexes of the second
triangle.

these are the ones who may need to be splited.

then take the planes containing the two triangles, intersect them, it can
result an line (say Li), or a null intersection, in case of being a line,
find all the intersections of Li with the triangles edges.
it must be in the following sequence

enter triangle 1, exit triangle 1
enter triangle 2, exit triangle 2

in all other cases, the triangles are splited in the line Li

After proceeding in this way you can use any criteria to sort the triangles,
i think this is the minimal algorithm, it takes about 1 days to be coded ant
two or three to get working :D

I have a C++ 3D geometry class. but it uses overloaded operators
(everywhere), with this class I am able to implement, i think, what i
described above. if one want to translate the C++ to C and compile it i can
spend some time for writing it, and send yet this week.

FAQ: obsolete "gset" command in Octave

[Guido T. <gu...@tr...>]

Hello,

the Octave command "gset" that is mentioned in the Gnuplot's FAQ has
become obsolete (at least in Octave version 3.2.4). Unfortunately, I
still need to figure out how to "set terminal" and "set output", however
the FAQ probably needs to be updated (at paragraph 5.6).

Also the link to (faq.tex) in http://www.gnuplot.info/faq/index.html
does not work.

Thanks.

GT

Re: [Gnuplot-info] maxima + gnupolot: 3D rendering bug?

[Petr M. <mi...@ph...>]

> > I suggest that a better approach would be to add a pass that splits large
> > triangles into smaller pieces before sorting and rendering.
> > The only tricky part is how to define "large".
> 
> I was thinking about exactly the same thing, but then realized that
> there is already the "interpolate" option that does (almost) the same.

Does "pm3d interpolate x,y" works for you? 
Yes, this interpolation is some kind of smoothing because you add new 
objects.

> of 4 corners, instead, it introduces a new pm3d option "corners2depth"
> that allows for configurability of the depth sorting in a similar manner
> as already existing "corners2color" option adds configurability

I think this option is useful.

---
PM

Re: [Gnuplot-info] maxima + gnupolot: 3D rendering bug?

[Ethan M. <merritt@u.washington.edu>]

On Friday, December 10, 2010 03:17:16 am Stanislav Maslovski wrote:
> > I suggest that a better approach would be to add a pass that splits large
> > triangles into smaller pieces before sorting and rendering.
> > The only tricky part is how to define "large".
> 
> I was thinking about exactly the same thing, but then realized that
> there is already the "interpolate" option that does (almost) the same.
> But sometimes we want to look at a dataset without smoothing it,
> right?

Splitting an existing triangle into sub-triangles would not create
any smoothing.  In the absence of occluding objects, the rendered
image of the new set of smaller triangles is indistiguishable from that
of the original single triangle.

The issue of interpolation only arises if you need to  assign a color to
the newly created vertex based on differing colors belonging to the
existing vertices.

Re: [Gnuplot-info] maxima + gnupolot: 3D rendering bug?

[Stanislav M. <sta...@gm...>]

On Thu, 2010-12-09 at 12:11 -0800, Ethan Merritt wrote:
> On Thursday, December 09, 2010 07:53:12 am Stanislav Maslovski wrote:
> > > Replying to myself: actually, after reading some docs (and the code) I
> > > realized that it was a limitation of the rendering algorithm used by the
> > > gnuplot (a variant of painter's algorithm). So, I solved this issue by
> > > patching pm3d.c:pm3d_depth_queue_flush() so that sorting of quadrangles
> > > was done based on the average depth of 4 corners.
> 
> I don't think this is the best way to approach the problem.
> As Hans-Bernhard pointed out, _any_ simple-minded sorting on a 
> single Z value is going to fail for some configuration of triangles.
> The bigger the triangle, the more likely that any single Z value is not
> right for the whole thing.

BTW, just a little clarification in case if someone reading this has not
looked into the patch: the patch does more than just averaging the depth
of 4 corners, instead, it introduces a new pm3d option "corners2depth"
that allows for configurability of the depth sorting in a similar manner
as already existing "corners2color" option adds configurability to the
coloring.

--
Stanislav

Re: [Gnuplot-info] maxima + gnupolot: 3D rendering bug?

[Stanislav M. <sta...@gm...>]

Hello,

On Thu, 2010-12-09 at 12:11 -0800, Ethan Merritt wrote:
> On Thursday, December 09, 2010 07:53:12 am Stanislav Maslovski wrote:
> > > Replying to myself: actually, after reading some docs (and the code) I
> > > realized that it was a limitation of the rendering algorithm used by the
> > > gnuplot (a variant of painter's algorithm). So, I solved this issue by
> > > patching pm3d.c:pm3d_depth_queue_flush() so that sorting of quadrangles
> > > was done based on the average depth of 4 corners.
> 
> I don't think this is the best way to approach the problem.
> As Hans-Bernhard pointed out, _any_ simple-minded sorting on a 
> single Z value is going to fail for some configuration of triangles.
> The bigger the triangle, the more likely that any single Z value is not
> right for the whole thing.

Yes, I agree. That was just the first thing I tried and it worked for my
task. However, until a better rendering algorithm is available, I still
suggest including my patch because it makes the depth sorting
configurable which certainly helps in some cases (while keeping the same
default behavior). The reasoning behind this is purely practical: 1)
configurability of depth sorting can be useful with sparse datasets; 2)
all the infrastructure that my patch relies upon is already in the code
(in the realization of corners2color option).

> I suggest that a better approach would be to add a pass that splits large
> triangles into smaller pieces before sorting and rendering.
> The only tricky part is how to define "large".

I was thinking about exactly the same thing, but then realized that
there is already the "interpolate" option that does (almost) the same.
But sometimes we want to look at a dataset _without_ smoothing it,
right?

--
Stanislav

Re: Compiling

[Alexandre F. <o.a...@gm...>]

>
> What about a proper combination of sampling and clipping? Compare these
>

It's new for me, now i'm not so sure of the benefits of implementing that...

Re: Compiling

[Tatsuro M. <tma...@ya...>]

Hello

--- Peter Juhasz  wrote:
> 
> You may be better off with installing and learning to use a linux
> system where you don't have to shoot yourself in the foot if you want
> to compile anything.


Another option to build gnuplot on windows is to use the cygwin.
Unfortunately the wxt terminal cannot be built with libraries installed with cygwin setup.exe but
almost all terminals can be implemented far easier than on native windows.

Lacking of wxt terminal on the cygwin can be covered if you use the pngcairo terminal. (Of course it
it cannot be used interactively but quality of the bitmap image is the almost the same as that made by
wxt terminal.)

Regards

Tatsuro  

--------------------------------------
Let's write special new year cards!
- Yahoo! JAPAN  Nengajo 2011 Special Site -
http://pr.mail.yahoo.co.jp/nenga2011/

Re: Compiling

[Petr M. <mi...@ph...>]

> Yes, I know that increase the number of samples and plot with dots may work.
> this could resolve the problem until the user zoom the chart.
> 
> The user defined functions is not so arbitrary. and my analisis is for
> simple functions
> supose that i know f(x) and g(x)

What about a proper combination of sampling and clipping? Compare these 
plots:

set yrange [-500:500]
plot tan(x)

and

set samples 10000
set clip one
set yrange [-500:500]
plot tan(x)


> I'd like very much linux, but between linux and internet i chose internet,

???

---
PM

Re: [Gnuplot-info] maxima + gnupolot: 3D rendering bug?

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

Ethan Merritt wrote:
> On Thursday, December 09, 2010 07:53:12 am Stanislav Maslovski wrote:
> 
>>Hello,
>>
>>On Tue, 2010-12-07 at 15:42 +0000, Stanislav Maslovski wrote:
>>
>>>On Tue, 2010-12-07 at 11:51 +0000, Stanislav Maslovski wrote:
>>>
>>>>Hello,
>>>>
>>>>Can anyone advise me on how can I workaround the problem with 3D
>>>>rendering in the plot [1]? The problem is that the surfaces that must be
>>>>hidden are seen in this plot (to clearly see them,
>>>>load "maxout.gnuplot" and try rotating the plot).
>>>>
>>>>The plot was generated in maxima, using the draw3d command. Any help
>>>>will be very much appreciated!
>>>>
>>>>[1] http://zalil.ru/30094104 (wait 10 secs, and download will start)
>>>
>>>Replying to myself: actually, after reading some docs (and the code) I
>>>realized that it was a limitation of the rendering algorithm used by the
>>>gnuplot (a variant of painter's algorithm). So, I solved this issue by
>>>patching pm3d.c:pm3d_depth_queue_flush() so that sorting of quadrangles
>>>was done based on the average depth of 4 corners.
> 
> 
> I don't think this is the best way to approach the problem.
> As Hans-Bernhard pointed out, _any_ simple-minded sorting on a 
> single Z value is going to fail for some configuration of triangles.
> The bigger the triangle, the more likely that any single Z value is not
> right for the whole thing.
> 
> I suggest that a better approach would be to add a pass that splits large
> triangles into smaller pieces before sorting and rendering.
> The only tricky part is how to define "large".   
> [OK, there's potentially another tricky part if you are coloring by
> something other than Z since you have to decide how to assign colors
> to the newly created vertices.]
> 
> You can probably find sample code for this kind of divide-and-conquer
> approach in a textbook or article, but it should be simple enough to
> work it out from scratch.

The rendering of the 3D surfaces doesn't cut it.  I tried very hard myself to come up with a good compromise, but it seemed there was no good approach for the general case.  (Some examples would look good, others not.)  What Ethan is suggesting might help (or not, depending on the example perhaps), but that still isn't the answer.

I had reached the conclusion that implementing the rendering by determining intersections of surfaces pretty much as defined might be the best place to put effort.  It was just after I had looked at the 2D mesh code that had some boundary issues.  The 2D code looks for intersections of lines and then breaks those lines up.  If one thinks in terms of vectors and matrices (i.e., linear algebra formulas), keeping things straight is not too difficult.  The same would apply for 3D surfaces.  Look for intersecting surfaces and then break those up--being 3D there are a lot of cases and the result will be a growth in code, but one just has to be organized about it.

The "painter algorithm" works for a first pass, i.e., if there is not intersection along the depth, (or width or height) for two particular triangles, then there is no way there can be intersections and no need to check.  That will speed processing significantly.

Actual 3D rendering would be a nice addition.  Might make for a good little project one of these days.

Dan

Re: Compiling

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

Alexandre Felipe wrote:
> Yes, I know that increase the number of samples and plot with dots may 
> work. this could resolve the problem until the user zoom the chart.
> Whatever is the GNU tarball it appeared with the source code.
> 
> /Finding discontinuities (or determining whether a function
> is continuous in a given interval) is quite hard for an arbitrary
> function./
> /How exactly do you intend to do this?/
> 
> The user defined functions is not so arbitrary. and my analisis is for 
> simple functions
> supose that i know f(x) and g(x)
> 
> if(c = discontinuity of f){
>   if((g(x1) < c) != (g(x2) < c)) {
>     an treat it or only break the line betwen x1 and x2
>     or find the closer x3 of the discontinuity and plot two points there
>     one with the limit(f(x), x -> x3+) and other with limit(f(x), x -> x3-)
>     i don't know how the gnuplot handles it internaly but it handles
>          
>           plot '-' with lines
>                 1 2
>                 2 2
> 
>                 2 1
>                 2 1
>          e
>   }
> }else if(c = discontinuity of g betwen x1 and x2){
>    plot the function in c with the two lateral limits
> }
> 
> 
> it's easy to implement it recursively less than 1000 lines i think :D
> 
> discontinuities that i know
> 1/x - x = 0
> x < 0, x = 0
> gamma(x), x integer < 0
> floor(x), x integer
> it there are others is only specify
> so the returning value in each evaluation should carry information about 
> the discontinuity only for the
> working interval, 

If you know the limit points of your functions then there are ways to construct plots of multiple segments and achieve what you are looking for.  Take a look at some of the examples in the demos:

http://gnuplot.sourceforge.net/demo_4.4

In particular, the statistical distributions have some good examples:

http://gnuplot.sourceforge.net/demo_4.4/prob.html

Check out the gamma function plot.

Dan

Re: Compiling

[Alexandre F. <o.a...@gm...>]

Yes, I know that increase the number of samples and plot with dots may work.
this could resolve the problem until the user zoom the chart.
Whatever is the GNU tarball it appeared with the source code.

*Finding discontinuities (or determining whether a function
is continuous in a given interval) is quite hard for an arbitrary
function.*
*How exactly do you intend to do this?*

The user defined functions is not so arbitrary. and my analisis is for
simple functions
supose that i know f(x) and g(x)

if(c = discontinuity of f){
  if((g(x1) < c) != (g(x2) < c)) {
    an treat it or only break the line betwen x1 and x2
    or find the closer x3 of the discontinuity and plot two points there
    one with the limit(f(x), x -> x3+) and other with limit(f(x), x -> x3-)
    i don't know how the gnuplot handles it internaly but it handles

          plot '-' with lines
                1 2
                2 2

                2 1
                2 1
         e
  }
}else if(c = discontinuity of g betwen x1 and x2){
   plot the function in c with the two lateral limits
}


it's easy to implement it recursively less than 1000 lines i think :D

discontinuities that i know
1/x - x = 0
x < 0, x = 0
gamma(x), x integer < 0
floor(x), x integer
it there are others is only specify
so the returning value in each evaluation should carry information about the
discontinuity only for the
working interval,

this will work for functions with a limited number of discontinuities, say
n(discontinuities) <= samples

this will increase the evaluation complexity by something about 3 times,
wich i think is not a problem, since rendering is in most cases much more
costly

> and then improve the automatic
> choose for ploting range in fundamental singularities points

I can't follow this at all.

it's only a different way of determining xmin and xmax, in the configuration
of the plot is determine as the values can be out of the image, plot loss,
say 5%, meaning that if the [tx]range is of lenght L, only 0.05*L can be
represented out of the chart area.

first i evaluate all points in the curve.
when i find a singularity i assign it's value like is the lateral limits
if is(finite or zero){
  adjust yrange to contain this discontinuity
}
if it's not a discontinuity but is a critical point
adjust the yrange to contain this discontinuity

all +inf -inf are disqualified to be range delimiters
but are placed in a list priority_queue would be fine

yrange_m is this range
if yrange don't contains (100% - char_loss) it's needed to increase it
for this it can be taken every neighbor of +inf or -inf and include it

yrange_max = yrange_m * inf_importance
while(yrange_max < yrange){
  xrange_p = xrange
  include the nearest y that is out of yrange
}
if(yrange_max / yrange_p < yrange / yrange_max){
  yrange = yrange_p;
}

i particularly don't think is important represent ifinitum, i would assign
inf_importance something like 2.0

complexity O(N Log N) in respect to samples, because for the second stage
it's not a simple investigation, but a
inclusion by priority.

There are still another approach that is:
positive_attractiveness = sum(1/derivative(outgoing point) -
derivative(1/incoming point) at ymax))
negative_attractiveness = sum(-1/derivative(outgoing point) +
derivative(1/incoming point) at ymin))

ymax +=
(increase*positive_attractiveness/(positive_attractiveness+negative_attractiveness))
ymin -=
(increase*negative_attractiveness/(positive_attractiveness+negative_attractiveness))

as the function is interpolated by straight lines derivative is the angular
coefficient
it can be used in the last step when i know that derivative will not change,
there after the while

while(yrange_max < yrange){
  xrange_p = xrange
  include the nearest y that is out of yrange
}
increase = yrange - yrange_max;

it fit the range to exactly yrange_max.

Other thing that would be fine is to ensure that all inflection points are
inside the chart, but it is a quite complex to explain here and now, since i
took more than half hour to write this kkk


I'd like very much linux, but between linux and internet i chose internet,
moreover, with linux at least you change information only with people with
linux it's needed to face so many compability problems.

other linguistic and grammatical corrections are welcome in English to join
this mailing list I just read.

Re: [Gnuplot-info] maxima + gnupolot: 3D rendering bug?

[Ethan M. <merritt@u.washington.edu>]

On Thursday, December 09, 2010 07:53:12 am Stanislav Maslovski wrote:
> Hello,
> 
> On Tue, 2010-12-07 at 15:42 +0000, Stanislav Maslovski wrote:
> > On Tue, 2010-12-07 at 11:51 +0000, Stanislav Maslovski wrote:
> > > Hello,
> > > 
> > > Can anyone advise me on how can I workaround the problem with 3D
> > > rendering in the plot [1]? The problem is that the surfaces that must be
> > > hidden are seen in this plot (to clearly see them,
> > > load "maxout.gnuplot" and try rotating the plot).
> > > 
> > > The plot was generated in maxima, using the draw3d command. Any help
> > > will be very much appreciated!
> > > 
> > > [1] http://zalil.ru/30094104 (wait 10 secs, and download will start)
> > 
> > Replying to myself: actually, after reading some docs (and the code) I
> > realized that it was a limitation of the rendering algorithm used by the
> > gnuplot (a variant of painter's algorithm). So, I solved this issue by
> > patching pm3d.c:pm3d_depth_queue_flush() so that sorting of quadrangles
> > was done based on the average depth of 4 corners.

I don't think this is the best way to approach the problem.
As Hans-Bernhard pointed out, _any_ simple-minded sorting on a 
single Z value is going to fail for some configuration of triangles.
The bigger the triangle, the more likely that any single Z value is not
right for the whole thing.

I suggest that a better approach would be to add a pass that splits large
triangles into smaller pieces before sorting and rendering.
The only tricky part is how to define "large".   
[OK, there's potentially another tricky part if you are coloring by
something other than Z since you have to decide how to assign colors
to the newly created vertices.]

You can probably find sample code for this kind of divide-and-conquer
approach in a textbook or article, but it should be simple enough to
work it out from scratch.

	Ethan


> > 
> > It would be nice if this could be made configurable. I will probably
> > come out with a patch in the next couple of days to enable this feature.
> 
> Just in case: the patch with an example is available from here
> http://sourceforge.net/tracker/?func=detail&aid=3132649&group_id=2055&atid=302055
> 
> Cheers,
> --
> Stanislav

Re: Compiling

[Peter J. <pet...@gm...>]

On Thu, Dec 9, 2010 at 1:06 PM, Alexandre Felipe
<o.a...@gm...> wrote:
> I downloaded the source in a zip file from the web-based svn in the
> sourceforge.
> The purpose to build gnuplot for windows is that i want include a feature
> there. It is a simple
> one, predict discontinuities on function interavals, would you tried
> plotting 1/x with lines?

Umm, have you ever tried plotting 1/x with a fixed yrange and a large
sample size?
(e.g. "set yrange [-10:10]; set sample 1000; plot 1/x")

 my intention is create some stuff to handle
> discontinuities,

How exactly do you intend to do this? Gnuplot doesn't have any
capabilities for function analysis. All it does is evaluating the
function at regular intervals, then connecting the x,y pairs with line
segments. Finding discontinuities (or determining whether a function
is continuous in a given interval) is quite hard for an arbitrary
function.

and then improve the automatic
> choose for ploting range in fundamental singularities points, since it
> should be not be
> displayed anyway, it's not smart grow the range to view every points, more
> over, if the
> function have mor than one singularity in usually one of then determines the
> plotting range
> and the other are not ocuppying all the chart area.

I can't follow this at all.

 When this issue is
> resolved, is time to hack 3D charts.

The 3D code doesn't need any more hacks, it needs a thorough
rethinking and rewriting.

> The main problem i am facing is that i have a little experience on
> conpilling projects from
> source, i would like to learn more about, but my time is sparse, my use of
> open source
> where run the compiled programs, or learn some programming tecnics to apply
> in my
> programs, that are generaly for particular use.
> I still don't know  how it works but what i will need is only one terminal
> say wxt (i have
> already the wxWidgets configured in my machine). For my purpose i could
> disable all-1
> terminals, and plot only 1d functions in 2d space, because my first change
> is in the valuation of functions. Could someone having a windows compiling
> version send-me only the important archives preferably reducing the
> dependency from other souces, i repeat, i'm not a compiler expert, please be
> understanding, I use code::blocks, if some can create a code::blocks project
> and put it working, even if with limited features, i would be grateful.
> In the "binary" dir there are several .dll, using it in some way with the
> linker is not enough?

You may be better off with installing and learning to use a linux
system where you don't have to shoot yourself in the foot if you want
to compile anything.

Péter Juhász

Re: [Gnuplot-info] maxima + gnupolot: 3D rendering bug?

[Stanislav M. <sta...@gm...>]

Hello,

On Tue, 2010-12-07 at 15:42 +0000, Stanislav Maslovski wrote:
> On Tue, 2010-12-07 at 11:51 +0000, Stanislav Maslovski wrote:
> > Hello,
> > 
> > Can anyone advise me on how can I workaround the problem with 3D
> > rendering in the plot [1]? The problem is that the surfaces that must be
> > hidden are seen in this plot (to clearly see them,
> > load "maxout.gnuplot" and try rotating the plot).
> > 
> > The plot was generated in maxima, using the draw3d command. Any help
> > will be very much appreciated!
> > 
> > [1] http://zalil.ru/30094104 (wait 10 secs, and download will start)
> 
> Replying to myself: actually, after reading some docs (and the code) I
> realized that it was a limitation of the rendering algorithm used by the
> gnuplot (a variant of painter's algorithm). So, I solved this issue by
> patching pm3d.c:pm3d_depth_queue_flush() so that sorting of quadrangles
> was done based on the average depth of 4 corners.
> 
> It would be nice if this could be made configurable. I will probably
> come out with a patch in the next couple of days to enable this feature.

Just in case: the patch with an example is available from here
http://sourceforge.net/tracker/?func=detail&aid=3132649&group_id=2055&atid=302055

Cheers,
--
Stanislav

Re: Compiling

[Petr M. <mi...@ph...>]

> I downloaded the source in a zip file from the web-based svn in the
> sourceforge.

I wonder about this ... I can only see "Download GNU tarball" (i.e. .tar.gz) 
at http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/

> The purpose to build gnuplot for windows is that i want include a feature 
> there. It is a simple one, predict discontinuities on function interavals, 
> would you tried plotting 1/x with lines? my intention is create some stuff 
> to handle discontinuities, and then improve the automatic choose for 
> ploting range in fundamental singularities points, since it should be not 
> be displayed anyway, it's not smart grow the range to view every points, 
> more over, if the function have mor than one singularity in usually one of 
> then determines the plotting range and the other are not ocuppying all the 
> chart area. When this issue is resolved, is time to hack 3D charts. The 
> main problem i am facing is that i have a little experience on conpilling 
> projects from source, i would like to learn more about, but my time is 
> sparse, my use of open source where run the compiled programs, or learn 
> some programming tecnics to apply in my programs, that are generaly for 
> particular use. I still don't know how it works but what i will need is 
> only one terminal say wxt (i have already the wxWidgets configured in my 
> machine). For my purpose i could disable all-1 terminals, and plot only 1d 
> functions in 2d space, because my first change is in the valuation of 
> functions. Could someone having a windows compiling version send-me only 
> the important archives preferably reducing the dependency from other 
> souces, i repeat, i'm not a compiler expert, please be understanding, I 
> use code::blocks, if some can create a code::blocks project and put it 
> working, even if with limited features, i would be grateful. In the 
> "binary" dir there are several .dll, using it in some way with the linker 
> is not enough?

The most easy way to compile win32 binary is to get MingW32 and use
"make -f Makefile.mgw". You will get the traditional windows terminal,
not wxt, but you don't have to deal with all the dependencies.

---
PM