Hi,
I'd like to propose adding a SHADES keyword to the mplot3D routines where you can supply your own colors for each polygon. There are cases where I do not want the surfaces to be shaded by the Z value, so this cannot be achieved with colormaps. This would also allow light-source shading if LightSource.shade is upgraded to 3D (my next goal). I already have this patch for axes3D.plot_surface written, but would like some discussion about it before I submit an enhancement request/patch.
As of right now I have a demo that works as follows:
l = LightSource(azdeg=100)
t = l.shade(Z, cm.jet)
ax.plot_surface(X, Y, Z, rstride=1, cstride=1, shades=t)
I would also like to add a linewidth keyword to specify the width of the wireframe in the 3dSurface command.
I'd be interested in hearing anyone's comments about this. I've attached a pre-lim version of this code.. (still has to be cleaned up and variable names changed).
The other thing that would be really nice is to have smooth
interpolation along each face. Michael, do you have a sense how hard
it would be in agg (and other backends) to do a linear gradient
interpolation over a quadrilateral with one RGBA at each vertex?
···
On Thu, Aug 6, 2009 at 11:51 AM, Ryan Wagner<rwagner@...735...> wrote:
Hi,
I'd like to propose adding a SHADES keyword to the mplot3D routines where you can supply your own
I looked into this a while ago wrt 2D quad meshes, and it didn't look like there was anything built-in to do something like that. All the gradients are 1-dimensional (i.e. between two colors, or a 1-dimensional lookup table of colors). There's nothing to do a 4-way blend like this. So it would have to be from scratch, at least for the colored part -- we can still use Agg to render the quad shapes themselves.
Mike
John Hunter wrote:
···
On Thu, Aug 6, 2009 at 11:51 AM, Ryan Wagner<rwagner@...735...> wrote:
Hi,
I'd like to propose adding a SHADES keyword to the mplot3D routines where you can supply your own
The other thing that would be really nice is to have smooth
interpolation along each face. Michael, do you have a sense how hard
it would be in agg (and other backends) to do a linear gradient
interpolation over a quadrilateral with one RGBA at each vertex?
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net matplotlib-devel List Signup and Options
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
What about for other backends (PS, PDF, SVG)? If there was support in
the gradient spec for these, it might be worth it to try and write a
custom gradient function in agg, as suggested by Maxim at the end of
this tutorial:
On Thu, Aug 6, 2009 at 1:06 PM, Michael Droettboom<mdroe@...31...> wrote:
I looked into this a while ago wrt 2D quad meshes, and it didn't look like
there was anything built-in to do something like that. All the gradients
are 1-dimensional (i.e. between two colors, or a 1-dimensional lookup table
of colors). There's nothing to do a 4-way blend like this. So it would
have to be from scratch, at least for the colored part -- we can still use
Agg to render the quad shapes themselves.
I looked into this a while ago wrt 2D quad meshes, and it didn't look like
there was anything built-in to do something like that. All the gradients
are 1-dimensional (i.e. between two colors, or a 1-dimensional lookup table
of colors). There's nothing to do a 4-way blend like this. So it would
have to be from scratch, at least for the colored part -- we can still use
Agg to render the quad shapes themselves.
What about for other backends (PS, PDF, SVG)? If there was support in
the gradient spec for these, it might be worth it to try and write a
custom gradient function in agg, as suggested by Maxim at the end of
this tutorial:
Even with this, the gradient infrastructure in Agg assumes a one-dimensional map, and here we need to at least interpolate between the three points of a triangle. It's not impossible, as it's easy enough to make a custom shader, it's just that the gradient code won't help us.
That is, rather than doing a single Gourad triangle interpolation, just overlap three linear gradient patches with alpha blending. At the very least it presents a way to support this in SVG which doesn't currently have Gourad interpolation.
PDF and PS support Gourad triangles directly, though supporting it looks -- um -- "fun".
Cheers,
Mike
···
On Thu, Aug 6, 2009 at 1:06 PM, Michael Droettboom<mdroe@...31...> wrote:
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
Hi Mike and John,
I've got a question about the functionality about axes3d.plot_surface:
When I set the linewidths to 0 (in the patch I'm working on) I get an image looking like this:
Would you agree that this should be the expected functionality or should I leave this alone, or should it be a new keyword?
WRT to the previous conversation about the gradients, I have been wishing for that for a while myself, but I understand the difficulty in doing the interpolations. In my own work I end up interpolating the data much finer and it looks better since the polygons are so small you can't notice the single colored polys:
Perhaps leaving it as it is today for lw=0, but having your behavior
be the result for lw=None? I can see people wanting the very fine
grid that lw=0 gives today, and lw=None to me seems to be very
explicitly saying 'no lines'.
Just an idea...
Cheers,
f
ps - Congrats to all on the release! You've all done an absolutely
terriffic job, and the benefits are already becoming obvious with
these new ideas and contributions. We'll have to celebrate at scipy
···
On Thu, Aug 6, 2009 at 4:11 PM, Ryan Wagner<rwagner@...735...> wrote:
When I set the linewidths to 0 (in the patch I'm working on) I get an image looking like this:
Would you agree that this should be the expected functionality or should I leave this alone, or should it be a new keyword?
Perhaps leaving it as it is today for lw=0, but having your behavior
be the result for lw=None? I can see people wanting the very fine
grid that lw=0 gives today, and lw=None to me seems to be very
explicitly saying 'no lines'.
Except that in typical mpl usage, None means use a default.
For colors, 'none' (a string) means no color, so a line should not be drawn. Elsewhere in mpl, lw=0 also means "don't draw it at all", so it seems right to me that it should do the same for 3-D.
Eric
···
On Thu, Aug 6, 2009 at 4:11 PM, Ryan Wagner<rwagner@...735...> wrote:
Just an idea...
Cheers,
f
ps - Congrats to all on the release! You've all done an absolutely
terriffic job, and the benefits are already becoming obvious with
these new ideas and contributions. We'll have to celebrate at scipy
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net matplotlib-devel List Signup and Options
I don't think this looks correct to me, as I can still see the grid. I have a workaround in place so if linewidth=0 then the image looks like this:
Does your workaround work for all supported backends, and with alpha
less than 1? If so, what is it?
I believe it will... it is to set the edgecolors (RGBA) of the polygons to that of the facecolors. I will certainly test it on all backends and with several test cases before submitting anything, but it looks promising so far!
Would you agree that this should be the expected functionality or should I leave this alone, or should it be a new keyword?
Perhaps leaving it as it is today for lw=0, but having your behavior
be the result for lw=None? I can see people wanting the very fine
grid that lw=0 gives today, and lw=None to me seems to be very
explicitly saying 'no lines'.
Except that in typical mpl usage, None means use a default.
For colors, 'none' (a string) means no color, so a line should not be
drawn. Elsewhere in mpl, lw=0 also means "don't draw it at all", so it
seems right to me that it should do the same for 3-D.
Seems like we need more discussion about this... anyone else want to chime in? I do like Fernando's idea if only to not break backwards compatability...
···
On Thu, Aug 6, 2009 at 4:11 PM, Ryan Wagner<rwagner@...735...> wrote:
Eric
Just an idea...
Cheers,
f
ps - Congrats to all on the release! You've all done an absolutely
terriffic job, and the benefits are already becoming obvious with
these new ideas and contributions. We'll have to celebrate at scipy
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net matplotlib-devel List Signup and Options
I agree with Eric that lw=0 should mean draw no line at all. In
postscript, linewidth=0 means "draw the thinnest line you can" but
early on we overrode this behavior to make the postscript backend
consistent with other mpl backends, so that linewidth=0 means draw no
line at all. I think 3D should be consistent with this. But setting
the edgecolors=facecolors should be fine too -- either of these or
both can be tested to see what gives the best behavior at the edges.
JDH
···
On Thu, Aug 6, 2009 at 11:31 PM, Ryan Wagner<rwagner@...735...> wrote:
Does your workaround work for all supported backends, and with alpha
less than 1? If so, what is it?
I believe it will... it is to set the edgecolors (RGBA) of the polygons to that of the facecolors. I will certainly test it on all backends and with several test cases before submitting anything, but it looks promising so far!
On Thu, Aug 6, 2009 at 1:53 PM, Michael Droettboom<mdroe@...31...> wrote:
Even with this, the gradient infrastructure in Agg assumes a one-dimensional
map, and here we need to at least interpolate between the three points of a
triangle. It's not impossible, as it's easy enough to make a custom shader,
it's just that the gradient code won't help us.
Ah -- I didn't look at Agg 2.5 at all because of the licensing issues. Isn't this a no-go for us because it's GPL'd?
Cheers,
Mike
John Hunter wrote:
···
On Thu, Aug 6, 2009 at 1:53 PM, Michael Droettboom<mdroe@...31...> wrote:
Even with this, the gradient infrastructure in Agg assumes a one-dimensional
map, and here we need to at least interpolate between the three points of a
triangle. It's not impossible, as it's easy enough to make a custom shader,
it's just that the gradient code won't help us.
I checked in with the antigrain mailing list, as was pointed to
examples/gouraud.cpp. This looks like what we want, no?
Nevermind -- this is in Agg 2.4 as well. Don't know why I missed it yesterday. I'll have a look into this to see how well we can integrate it.
Cheers,
Mike
Michael Droettboom wrote:
···
Ah -- I didn't look at Agg 2.5 at all because of the licensing issues. Isn't this a no-go for us because it's GPL'd?
Cheers,
Mike
John Hunter wrote:
On Thu, Aug 6, 2009 at 1:53 PM, Michael Droettboom<mdroe@...31...> wrote:
Even with this, the gradient infrastructure in Agg assumes a one-dimensional
map, and here we need to at least interpolate between the three points of a
triangle. It's not impossible, as it's easy enough to make a custom shader,
it's just that the gradient code won't help us.
I checked in with the antigrain mailing list, as was pointed to
examples/gouraud.cpp. This looks like what we want, no?
This looks great! I'd be happy to try and work on this for mplot3d as well.
Ryan: as for your patch, I'll look at it over the weekend or next week
and see if I can apply it to trunk.
Regards,
Reinier
···
On Fri, Aug 7, 2009 at 3:02 PM, Michael Droettboom<mdroe@...31...> wrote:
Nevermind -- this is in Agg 2.4 as well. Don't know why I missed it
yesterday. I'll have a look into this to see how well we can integrate it.
Cheers,
Mike
Michael Droettboom wrote:
Ah -- I didn't look at Agg 2.5 at all because of the licensing issues.
Isn't this a no-go for us because it's GPL'd?
Cheers,
Mike
John Hunter wrote:
On Thu, Aug 6, 2009 at 1:53 PM, Michael Droettboom<mdroe@...31...> wrote:
Even with this, the gradient infrastructure in Agg assumes a one-dimensional
map, and here we need to at least interpolate between the three points of a
triangle. It's not impossible, as it's easy enough to make a custom shader,
it's just that the gradient code won't help us.
I checked in with the antigrain mailing list, as was pointed to
examples/gouraud.cpp. This looks like what we want, no?
On Thu, Aug 6, 2009 at 11:31 PM, Ryan Wagner<rwagner@...735...> wrote:
Does your workaround work for all supported backends, and with alpha
less than 1? If so, what is it?
I believe it will... it is to set the edgecolors (RGBA) of the polygons to that of the facecolors. I will certainly test it on all backends and with several test cases before submitting anything, but it looks promising so far!
I agree with Eric that lw=0 should mean draw no line at all. In
postscript, linewidth=0 means "draw the thinnest line you can" but
early on we overrode this behavior to make the postscript backend
consistent with other mpl backends, so that linewidth=0 means draw no
line at all. I think 3D should be consistent with this. But setting
the edgecolors=facecolors should be fine too -- either of these or
both can be tested to see what gives the best behavior at the edges.
JDH
edgecolors=facecolors may cause artifacts with alpha < 1; at least that was the experience when we last experimented with similar problems in filled contours.
I have experimental support for Gouraud-shaded pcolormeshes with the Agg backend only in SVN trunk. The backend interface will likely change to better support PDF, where doing multiple triangles at a time is much more efficient. This is just the easiest and far from optimal way to do it.
I'm not sure if Gouraud triangles (as supported by Agg, PDF and PS) are really sufficient for drawing interpolated quad meshes, because of the effect described here:
Running quadmesh_demo.py, you can see some sharp edges between triangles in the same quad, but it's not too bad in all places. If anyone has any ideas about how to ameliorate that effect, feel free to have a crack at it. I just wanted to get a proof-of-concept starting point in before heading on vacation for a few days.
Cheers,
Mike
Reinier Heeres wrote:
···
Hi,
This looks great! I'd be happy to try and work on this for mplot3d as well.
Ryan: as for your patch, I'll look at it over the weekend or next week
and see if I can apply it to trunk.
Regards,
Reinier
On Fri, Aug 7, 2009 at 3:02 PM, Michael Droettboom<mdroe@...31...> wrote:
Nevermind -- this is in Agg 2.4 as well. Don't know why I missed it
yesterday. I'll have a look into this to see how well we can integrate it.
Cheers,
Mike
Michael Droettboom wrote:
Ah -- I didn't look at Agg 2.5 at all because of the licensing issues.
Isn't this a no-go for us because it's GPL'd?
Cheers,
Mike
John Hunter wrote:
On Thu, Aug 6, 2009 at 1:53 PM, Michael Droettboom<mdroe@...31...> wrote:
Even with this, the gradient infrastructure in Agg assumes a one-dimensional
map, and here we need to at least interpolate between the three points of a
triangle. It's not impossible, as it's easy enough to make a custom shader,
it's just that the gradient code won't help us.
I checked in with the antigrain mailing list, as was pointed to
examples/gouraud.cpp. This looks like what we want, no?
Wow -- hat tip to you! With productivity like this, how can we afford
to lose you for a few days to vacation
I had to run the example with mpl99 to appreciate the changes, since
you decreased the n from 56 to 12 to show off the effects of the
interpolation, and the interpolation with n=12 is about as visually
good as the grid w/o with n=56. Very nice.
I don't have time to dig into the code now since I have some pressing
work stuff, but I look forward to doing a read-through over the
weekend. Enjoy your vacation, but don't forget your computer graphics
texts and laptop -- I think lighting, shadows and several shaders
should get you through a few days on the beach <wink>
BTW, it looks like the edges of the polys are aliased in the "masked"
side of the figure. Have you noticed this?
JDH
···
On Fri, Aug 7, 2009 at 1:39 PM, Michael Droettboom<mdroe@...31...> wrote:
I'm not sure if Gouraud triangles (as supported by Agg, PDF and PS) are
really sufficient for drawing interpolated quad meshes, because of the
effect described here:
Running quadmesh_demo.py, you can see some sharp edges between triangles in
the same quad, but it's not too bad in all places. If anyone has any ideas
about how to ameliorate that effect, feel free to have a crack at it. I
just wanted to get a proof-of-concept starting point in before heading on
vacation for a few days.
Wow, no kidding John, what a difference! Great work Mike!
···
-----Original Message-----
From: John Hunter [mailto:jdh2358@…149…]
Sent: Friday, August 07, 2009 12:54 PM
To: Michael Droettboom
Cc: Reinier Heeres; Ryan Wagner; matplotlib-devel@lists.sourceforge.net
Subject: Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.
On Fri, Aug 7, 2009 at 1:39 PM, Michael Droettboom<mdroe@...31...> wrote:
I'm not sure if Gouraud triangles (as supported by Agg, PDF and PS) are
really sufficient for drawing interpolated quad meshes, because of the
effect described here:
Running quadmesh_demo.py, you can see some sharp edges between triangles in
the same quad, but it's not too bad in all places. If anyone has any ideas
about how to ameliorate that effect, feel free to have a crack at it. I
just wanted to get a proof-of-concept starting point in before heading on
vacation for a few days.
Wow -- hat tip to you! With productivity like this, how can we afford
to lose you for a few days to vacation
I had to run the example with mpl99 to appreciate the changes, since
you decreased the n from 56 to 12 to show off the effects of the
interpolation, and the interpolation with n=12 is about as visually
good as the grid w/o with n=56. Very nice.
I don't have time to dig into the code now since I have some pressing
work stuff, but I look forward to doing a read-through over the
weekend. Enjoy your vacation, but don't forget your computer graphics
texts and laptop -- I think lighting, shadows and several shaders
should get you through a few days on the beach <wink>
BTW, it looks like the edges of the polys are aliased in the "masked"
side of the figure. Have you noticed this?
-----Original Message-----
From: Michael Droettboom [mailto:mdroe@…31…]
Sent: Friday, August 07, 2009 1:00 PM
To: John Hunter
Cc: Reinier Heeres; Ryan Wagner; matplotlib-devel@lists.sourceforge.net
Subject: Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.
John Hunter wrote:
BTW, it looks like the edges of the polys are aliased in the "masked"
side of the figure. Have you noticed this?
Yeah -- the right hand side is still using the old code path, which is
aliased by default.
Cheers,
Mike
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
