Menu
▾
▴
plplot-devel
|
From: Alan W. I. <ir...@be...> - 2002-01-21 17:59:42
|
On Mon, 21 Jan 2002, Joao Cardoso wrote:
> ! Displays the plotter
> AND,CMP,COMPLEX,DREAL,FALSE,IMAG,IMPLICIT_REAL,INCLUDED_FMACS,NO,OFF,ON,OR,REAL,REAL_FUN,SYSTEM,TRUE,YES,__file__,__gnu__,__line__,__m4_version__,__unix__,builtin,cdefine,cexpand,changecom,changequote,changesyntax,concat,debugfile,debugmode,decr,define,defn,divert,divnum,dnl,dumpdef,errprint,esyscmd,eval,format,getstring,if_aix,if_bsd,if_dbl,if_dgux,if_false,if_hpux,if_linux,if_sunos,if_sx,if_sysv,if_true,if_ultrix,ifdef,ifelse,ifndef,ignore,implicit_none,include,incr,index,indir,len,m4exit,m4wrap,macro_do,maketemp,patsubst,popdef,pushdef,regexp,shift,sinclude,substr,symbols,syncoutput,syscmd,sysval,traceoff,traceon,translit,undef,undefine,undivert
> for PLPOIN <--- from the comment until here is a one comment line!
It appears the SuSe m4 is interpreting "symbols" as an m4 command. I have
just committed some *.fm4 changes that change symbols ==> {symbols}. The
curly braces mean that m4 ignores what is inside and passes it on untouched
to *.f. The *.f results here are identical, and I hope this fix solves your
problem.
I am anxious to hear whether my fixup worked for you.
Alan
|
|
From: Maurice L. <mj...@ga...> - 2002-01-18 08:46:46
|
Alan W. Irwin writes: > I don't care that much about version numbers except that I don't want to go > through them too rapidly. My understanding is the major number should be > incremented for huge changes, the minor number should be incremented for > fairly large changes, and the patch number incremented for smaller changes. > I absolutely agree with you there have been some fairly large changes made > since 5.0.4. Thus, I assumed it was appropriate to increment the minor > number and move on to 5.1.0. But if the developers here feel that 5.0.5 is > more appropriate, that is certainly fine with me! I think that 5.1.0 is a fine choice. -- Maurice LeBrun mj...@ga... |
|
From: Maurice L. <mj...@ga...> - 2002-01-18 09:36:16
|
Maurice LeBrun writes: > Alan W. Irwin writes: > > I don't care that much about version numbers except that I don't want to go > > through them too rapidly. My understanding is the major number should be > > incremented for huge changes, the minor number should be incremented for > > fairly large changes, and the patch number incremented for smaller changes. > > I absolutely agree with you there have been some fairly large changes made > > since 5.0.4. Thus, I assumed it was appropriate to increment the minor > > number and move on to 5.1.0. But if the developers here feel that 5.0.5 is > > more appropriate, that is certainly fine with me! > > I think that 5.1.0 is a fine choice. One question -- will dyndrivers be turned on by default? Right now it's not. -- Maurice LeBrun mj...@ga... |
|
From: Maurice L. <mj...@ga...> - 2002-01-18 09:42:35
|
Maurice LeBrun writes: > Maurice LeBrun writes: > > Alan W. Irwin writes: > > > I don't care that much about version numbers except that I don't want to go > > > through them too rapidly. My understanding is the major number should be > > > incremented for huge changes, the minor number should be incremented for > > > fairly large changes, and the patch number incremented for smaller changes. > > > I absolutely agree with you there have been some fairly large changes made > > > since 5.0.4. Thus, I assumed it was appropriate to increment the minor > > > number and move on to 5.1.0. But if the developers here feel that 5.0.5 is > > > more appropriate, that is certainly fine with me! > > > > I think that 5.1.0 is a fine choice. > > One question -- will dyndrivers be turned on by default? Right now it's not. BTW, would anyone mind if I changed the configure option from: --enable-dynamic-drivers to --enable-dyndrivers ? The extra hyphen make it confusing IMO when trying to figure out what the corresponding configure variable is (in this case, it's enable_dynamic_drivers rather than enable_dynamic-drivers). -- Maurice LeBrun mj...@ga... |
|
From: Alan W. I. <ir...@be...> - 2002-01-18 16:51:14
|
On Fri, 18 Jan 2002, Maurice LeBrun wrote: > > > I think that 5.1.0 is a fine choice. OK. I will stick with it. > > > > One question -- will dyndrivers be turned on by default? Right now it's not. My tests indicate that dynamic drivers are fine so I am comfortable with turning them on by default. However, I am getting quite pressed for time so please make the configuration changes yourself. > > BTW, would anyone mind if I changed the configure option from: > > --enable-dynamic-drivers > > to > > --enable-dyndrivers > > ? Sounds fine to me. |
|
From: Joao C. <jc...@fe...> - 2002-01-18 13:10:55
|
On Friday 18 January 2002 1:28 am, I wrote wrote: =2E.. > (And sgml was "made" because xml was too complicated for everyday > usage.) This is wrong, it is exactly the reverse. I just mixed it in my mind, aft= er=20 reading "The Latex Web Companion". Joao |
|
From: Maurice L. <mj...@ga...> - 2002-01-18 08:40:49
|
Alan W. Irwin writes: > Branches are useful for the really big changes > such as dynamic drivers, but I personally lost weeks of work on the tea > branch because there wasn't a critical mass of interested developers at the > time. Just BTW, I'm still benefitting from it, so it wasn't lost work from my perspective. I'm just getting to it piecemeal. -- Maurice LeBrun mj...@ga... |
|
From: Geoffrey F. <fu...@ga...> - 2002-01-17 19:25:54
|
Joao Cardoso writes: > What is the purpose of the "new" directory and its "bogus" file? Mmmm. Well, cvs log just about says it all. Or so it would seem. <wink> :-). > And the bindings/python/1.4b3 subdir? Stuff that was needed to get PLplot working with python 1.4 beta 3. I haven't touched the python binding recently, so do not really have an up to date and first hand perspective on the current issues for the python binding, beyond what is gleaned by reading Alan's various emails on the subject. -- Geoffrey Furnish fu...@ga... |
|
From: Maurice L. <mj...@ga...> - 2002-01-18 08:38:44
|
Joao Cardoso writes: > The ToDo and PROBLEMS file also needs an update, as some users can have the > expertise and mood to do/solve it. WE *should* use it, also! The problem with todo files is that if associated with a project they never reflect your personal priorities so I end up keeping a personal todo file. Always. Now, if we shared our todo files, then maybe we'd have something. That way if I did something that was on everyone's todo, I'd be a hero; if I saw that two of us had the same item, we could work something out, etc.. Even then I tend to separate it into short term, medium term, and gee it'd be nice categories. -- Maurice LeBrun mj...@ga... |
|
From: <jca...@in...> - 2002-01-18 00:56:46
|
On Thursday 17 January 2002 19:25, Geoffrey Furnish wrote: | Joao Cardoso writes: | > What is the purpose of the "new" directory and its "bogus" file? | | Mmmm. Well, cvs log just about says it all. | | Or so it would seem. <wink> You are right, of course. The 'bogus' file is for "testing",...,"Just=20 a test", "foo". ;) | :-). | : | > And the bindings/python/1.4b3 subdir? | | Stuff that was needed to get PLplot working with python 1.4 beta 3. | | I haven't touched the python binding recently, so do not really | have an up to date and first hand perspective on the current issues | for the python binding, beyond what is gleaned by reading Alan's | various emails on the subject. Again CVS logs don't lie: the files in that subdir (Setup and=20 _tkinter.c) are a "Complete sample of files edited according to the=20 prescription in bindings/python/README". They must be leftovers from=20 the static python building, I guess. My concern with unknow source or configuration files in cvs is...=20 concern. New people may lose time looking what they are for, there=20 might be configuartion support for them, turning configuration issues=20 more complicated, there might be side-effects, etc. Joao |
|
From: Geoffrey F. <fu...@ga...> - 2002-01-18 05:13:37
|
Jo=E3o Cardoso writes: > Again CVS logs don't lie: the files in that subdir (Setup and=20 > _tkinter.c) are a "Complete sample of files edited according to the=20= > prescription in bindings/python/README". They must be leftovers from= =20 > the static python building, I guess. >=20 > My concern with unknow source or configuration files in cvs is...=20= > concern. New people may lose time looking what they are for, there=20= > might be configuartion support for them, turning configuration issue= s=20 > more complicated, there might be side-effects, etc. Mmm, well, I wouldn't call them "leftovers", in thee sense of having become obsolete or something. I personally don't use the PLplot python binding any other way than by using the static binding, because that gives me access to the plframe widget, which is not yet available any other way. So I do not want to see stuff pertaining to the static plplot python binding removed, until we recover plframe via TEA inside python/Tk. I figure that's still a ways out. |
|
From: Joao C. <jc...@fe...> - 2002-01-18 13:25:36
|
On Friday 18 January 2002 5:13 am, Geoffrey Furnish wrote: > Jo=E3o Cardoso writes: > > Again CVS logs don't lie: the files in that subdir (Setup and > > _tkinter.c) are a "Complete sample of files edited according to the > > prescription in bindings/python/README". They must be leftovers from > > the static python building, I guess. > > > > My concern with unknow source or configuration files in cvs is... > > concern. New people may lose time looking what they are for, there > > might be configuartion support for them, turning configuration issue= s > > more complicated, there might be side-effects, etc. > > Mmm, well, I wouldn't call them "leftovers", in thee sense of having > become obsolete or something. I personally don't use the PLplot > python binding any other way than by using the static binding, because > that gives me access to the plframe widget, which is not yet available > any other way. So I do not want to see stuff pertaining to the static > plplot python binding removed, until we recover plframe via TEA inside > python/Tk. I figure that's still a ways out. OK, I understand it now. Are the following statements in bindings/python/README still true? "How to build yourself a python with PLplot support ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There are two possibilities. You can try to build a dynamically loadable python module, or you can modify the python build to include the plplot module. The former is what configure will try to do if you use --enable-python (which is the default). Currently this does not work very well. I have had some success with this plan on Linux, but not on other Unices yet. So, I suggest, and this document describes, to modify the python and rebuild it."=09 Joao |
|
From: Alan W. I. <ir...@be...> - 2002-01-18 17:05:55
|
On Fri, 18 Jan 2002, Joao Cardoso wrote: > Are the following statements in bindings/python/README still true? .... They need some revision. Just like some of the other README files we have scattered around as you have also rightly pointed out. This is a long-standing problem that we are slowly getting right, but since the same problem occurred for 5.0.4, it is definitely not release critical for 5.1.0. |
|
From: Alan W. I. <ir...@be...> - 2001-12-13 21:53:53
|
On Thu, 13 Dec 2001, Joao Cardoso wrote: > On Tuesday 11 December 2001 23:50, Alan W. Irwin wrote: > | (12) IMO, the most egregious bug for the plplot library shows up for x08c > | with the non-smooth edges (missing triangles) to the hidden parts of the > | plot for pages 5 through 8 (the 3D shade plot demonstration). If a C expert > | here is wondering how they can chip in, it would be *wonderful* to finally > | get rid of this bug. > > > Yes, this worries me too, but it is not a matter of C expertise. I think that > Geoffrey has already tried to correct it, and if I remember correctly he said > "better to write it from the begining" I believe the problem is actually pretty simple. Just from looking at the results, the current 3D shaded logic apparently makes a decision about which (relatively large) triangle is hidden and which not, and has no facility to refine the triangles shape and size so that they can smoothly follow the line marking the edge of hidden regions. We were up against a similar problem for the excluded regions of 2D shade plots, but (see the last page of x16c) Rafael found a working solution that involved a binary search (IIRC) to refine the triangles so they smoothly followed the edge of the excluded region. Although he has stated his code cannot be directly used in the 3D shading case, I am hoping his general idea can be used. If so, it should be a matter of a reasonably short effort to fix this with much thanks for whoever came up with the solution. > | > | (13) dynamic tk and xwin driver. (probably Joao). My impression from > | commented out parts of the code that I reviewed for the cgm driver is this > | might be ready to go now that we understand exactly what is required in > | the gd and cgm cases. Every dynamic driver requires a link to libplplot > | and some require additional links to their own special libraries. Wouldn't > | those special libraries just be the Tk library for the tk driver and the X > | libraries for the xwin driver? > > > The xwin and tk drivers can't be made dynamic. > > There is no problem with the xwin driver alone, but the tk driver (either > static or dynamic) won't work with a dynamic xwin driver. The tk driver needs > some functions that are in the xwin driver. > > The only solution, which is not elegant, would be to link tk.o and xwin.o to > make tk.drv. Would you please implement this solution? > > | I have probably forgotten some things so feel free to add to this list so > | long as the project is reasonably short (a few days or less). > > > This is an issue that worries me. You make a beatifull job testing plplot > regularly, and you post your conclusions/bugs/requests. But we might be busy > at the time, and your conclusions/requests becomes lost. I always archive > your testing requests for latter usage, but most of the time I just forgot to > use them. > > I think that we should start using some mechanism to correct this. A > possibility will be using the "tasks manager", > http://sourceforge.net/pm/?group_id=2915 , creating an entry for each driver > and language binding. What do you think? Probably that is a good idea for open-ended projects, but for this release wishlist I am trying to to stick to short projects that can be finished with a burst of concentrated effort. BTW, I now regret my phrasing above where I said "I have probably forgotten some things...." . I (like many here, I assume) have a long "ToDo" list of possible fixups and issues we have discussed on this list. So I never forget, and I do come back to nag you again....;-) Actually, what has happened with the wishlist is I made a judgement call about what subset of the ToDo list involves projects that are short and predictable enough (as opposed to open-ended) that it seems possible to squeeze it in before the release. Others may have different views and I welcome more discussion of this. For example, I will take the 3D shaded plot bug (as shown by x08c) off the list if the general conclusion is the fix is too tough to do in a short amount of time for a knowledgable C programmer. If others want to add more to the list, that's fine as well. The whole point of the (amended) list though is these are the items the group feels we should concentrate on before the release. The wishlist I presented in my e-mail was just the first stab at this priority list. Alan |
|
From: <jca...@in...> - 2001-12-15 03:11:24
|
On Thursday 13 December 2001 21:53, Alan W. Irwin wrote: | On Thu, 13 Dec 2001, Joao Cardoso wrote: | > On Tuesday 11 December 2001 23:50, Alan W. Irwin wrote: =2E.. | > | (13) dynamic tk and xwin driver. (probably Joao). My | > | impression from commented out parts of the code that I reviewed | > | for the cgm driver is this might be ready to go now that we | > | understand exactly what is required in the gd and cgm cases.=20 | > | Every dynamic driver requires a link to libplplot and some | > | require additional links to their own special libraries.=20 | > | Wouldn't those special libraries just be the Tk library for the | > | tk driver and the X libraries for the xwin driver? | > | > The xwin and tk drivers can't be made dynamic. | > | > There is no problem with the xwin driver alone, but the tk driver | > (either static or dynamic) won't work with a dynamic xwin driver. | > The tk driver needs some functions that are in the xwin driver. | > | > The only solution, which is not elegant, would be to link tk.o | > and xwin.o to make tk.drv. | | Would you please implement this solution? I'm sorry, I have forgot other details. I had already deeply=20 investigated this, and it is *not possible* to make the tk driver=20 dyn-loadable without serious changes in the library itself. That's=20 one of the reasons why I started the (not yet funtional) ntk driver. =2E.. Joao |
|
From: Maurice L. <mj...@ga...> - 2001-12-15 07:24:03
|
Jo=E3o Cardoso writes: > On Thursday 13 December 2001 21:53, Alan W. Irwin wrote: > | On Thu, 13 Dec 2001, Joao Cardoso wrote: > | > On Tuesday 11 December 2001 23:50, Alan W. Irwin wrote: > ... >=20 > | > | (13) dynamic tk and xwin driver. (probably Joao). My > | > | impression from commented out parts of the code that I reviewe= d > | > | for the cgm driver is this might be ready to go now that we > | > | understand exactly what is required in the gd and cgm cases.=20= > | > | Every dynamic driver requires a link to libplplot and some > | > | require additional links to their own special libraries.=20 > | > | Wouldn't those special libraries just be the Tk library for th= e > | > | tk driver and the X libraries for the xwin driver? > | > > | > The xwin and tk drivers can't be made dynamic. > | > > | > There is no problem with the xwin driver alone, but the tk drive= r > | > (either static or dynamic) won't work with a dynamic xwin driver= . > | > The tk driver needs some functions that are in the xwin driver. > | > > | > The only solution, which is not elegant, would be to link tk.o > | > and xwin.o to make tk.drv. > | > | Would you please implement this solution? >=20 > I'm sorry, I have forgot other details. I had already deeply=20 > investigated this, and it is *not possible* to make the tk driver=20= > dyn-loadable without serious changes in the library itself. That's=20= > one of the reasons why I started the (not yet funtional) ntk driver.= > ... >=20 > Joao And I'd planned to defer those "serious changes" to when the TEA branch= gets merged in, after AM/LT (or perhaps at the same time). I really am goin= g to work on this :), but not till next month. --=20 Maurice LeBrun mj...@ga... |
|
From: Alan W. I. <ir...@be...> - 2001-12-15 18:34:35
|
Thanks for these clarifications of the status of dynamic Tk driver. I will drop this from the release wish list. Alan email: ir...@be... phone: 250-727-2902=09FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ On Sat, 15 Dec 2001, Maurice LeBrun wrote: > Jo=E3o Cardoso writes: > > On Thursday 13 December 2001 21:53, Alan W. Irwin wrote: > > | On Thu, 13 Dec 2001, Joao Cardoso wrote: > > | > On Tuesday 11 December 2001 23:50, Alan W. Irwin wrote: > > ... > > > > | > | (13) dynamic tk and xwin driver. (probably Joao). My > > | > | impression from commented out parts of the code that I reviewed > > | > | for the cgm driver is this might be ready to go now that we > > | > | understand exactly what is required in the gd and cgm cases. > > | > | Every dynamic driver requires a link to libplplot and some > > | > | require additional links to their own special libraries. > > | > | Wouldn't those special libraries just be the Tk library for the > > | > | tk driver and the X libraries for the xwin driver? > > | > > > | > The xwin and tk drivers can't be made dynamic. > > | > > > | > There is no problem with the xwin driver alone, but the tk driver > > | > (either static or dynamic) won't work with a dynamic xwin driver. > > | > The tk driver needs some functions that are in the xwin driver. > > | > > > | > The only solution, which is not elegant, would be to link tk.o > > | > and xwin.o to make tk.drv. > > | > > | Would you please implement this solution? > > > > I'm sorry, I have forgot other details. I had already deeply > > investigated this, and it is *not possible* to make the tk driver > > dyn-loadable without serious changes in the library itself. That's > > one of the reasons why I started the (not yet funtional) ntk driver. > > ... > > > > Joao > > And I'd planned to defer those "serious changes" to when the TEA branch g= ets > merged in, after AM/LT (or perhaps at the same time). I really am going = to > work on this :), but not till next month. > > -- > Maurice LeBrun mj...@ga... > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
|
From: Joao C. <jc...@fe...> - 2001-12-19 18:13:24
|
Hi My wish "list": a cookbook (a README will be OK :) on how to setup java,=20 python, pyqt... I have tested the current plplot cvs snapshot on a suse-7= =2E2=20 (not a clean one, but upgraded from suse-7.0) and I had the "usual" probl= ems=20 with environment variables. The good news is that python (2.0), java (1.1.8), gd (1.8.4) and pyqt (ha= d to=20 compile sip-3.0 and PyQt-3.0) worked OK at first sight. Of course the mor= e=20 conservative drivers/bindings also worked OK. Joao |
|
From: Alan W. I. <ir...@be...> - 2001-12-19 19:34:46
|
On Wed, 19 Dec 2001, Joao Cardoso wrote: > > Hi > > My wish "list": a cookbook (a README will be OK :) on how to setup java, > python, pyqt... That is a good idea, and I will add it to the list probably above the line.... :( . > I have tested the current plplot cvs snapshot on a suse-7.2 > (not a clean one, but upgraded from suse-7.0) and I had the "usual" problems > with environment variables. > > The good news is that python (2.0), java (1.1.8), gd (1.8.4) and pyqt (had to > compile sip-3.0 and PyQt-3.0) worked OK at first sight. Of course the more > conservative drivers/bindings also worked OK. Good news, indeed! Alan |
|
From: Rafael L. <ra...@ic...> - 2001-12-14 11:49:51
|
* Alan W. Irwin <ir...@be...> [2001-12-13 13:53]: > I believe the problem is actually pretty simple. Just from looking at the > results, the current 3D shaded logic apparently makes a decision about > which (relatively large) triangle is hidden and which not, and has no > facility to refine the triangles shape and size so that they can smoothly > follow the line marking the edge of hidden regions. We were up against a > similar problem for the excluded regions of 2D shade plots, but (see the > last page of x16c) Rafael found a working solution that involved a binary > search (IIRC) to refine the triangles so they smoothly followed the edge of > the excluded region. Although he has stated his code cannot be directly > used in the 3D shading case, I am hoping his general idea can be used. If > so, it should be a matter of a reasonably short effort to fix this with > much thanks for whoever came up with the solution. From my recollection, the algorithms have completely different implementations, athough the problems addressed are quite similar. I am afraid that the effort needed will be not that short, but who knows? -- Rafael |
|
From: Maurice L. <mj...@ga...> - 2001-12-15 07:21:17
|
Rafael Laboissiere writes: > * Alan W. Irwin <ir...@be...> [2001-12-13 13:53]: > > > I believe the problem is actually pretty simple. Just from looking at the > > results, the current 3D shaded logic apparently makes a decision about > > which (relatively large) triangle is hidden and which not, and has no > > facility to refine the triangles shape and size so that they can smoothly > > follow the line marking the edge of hidden regions. We were up against a > > similar problem for the excluded regions of 2D shade plots, but (see the > > last page of x16c) Rafael found a working solution that involved a binary > > search (IIRC) to refine the triangles so they smoothly followed the edge of > > the excluded region. Although he has stated his code cannot be directly > > used in the 3D shading case, I am hoping his general idea can be used. If > > so, it should be a matter of a reasonably short effort to fix this with > > much thanks for whoever came up with the solution. > > >From my recollection, the algorithms have completely different > implementations, athough the problems addressed are quite similar. I am > afraid that the effort needed will be not that short, but who knows? When I looked into this last spring (fixing several bugs in the process), I concluded we might be better off with a new algorithm. The original algorithm only follows lines, not regions. If one endpoint of the line is hidden but the other is not, it merely calculates the intersection point and draws from that point. Extending this to 2D and getting it right does not look easy to me. The existing shade extension is clever but I found the boundary conditions too messy to be able to make solid headway without considerable effort. -- Maurice LeBrun mj...@ga... |
|
From: Alan W. I. <ir...@be...> - 2001-12-15 18:32:47
|
On Sat, 15 Dec 2001, Maurice LeBrun wrote: > When I looked into this last spring (fixing several bugs in the process), I > concluded we might be better off with a new algorithm. The original algorithm > only follows lines, not regions. If one endpoint of the line is hidden but > the other is not, it merely calculates the intersection point and draws from > that point. Extending this to 2D and getting it right does not look easy to > me. The existing shade extension is clever but I found the boundary > conditions too messy to be able to make solid headway without considerable > effort. Maurice, I am having trouble interpreting your words here since the previous posts in this thread discussed both 2D and 3D shading which have separate algorithms. I believe (although I am not sure) that part of your paragraph may refer to a better algorithm for the 2D shading (which might be a good idea, but there is currently no bug in that case), and part of the paragraph to 3D shading (which does have a bug). Could you please clarify? I am particularly interested in whether you think a new 3D shading algorithm is required to fix the 3D shading bug. If so, I will drop it from the release wish list. Alan |
|
From: Maurice L. <mj...@ga...> - 2001-12-15 21:29:10
|
Alan W. Irwin writes: > On Sat, 15 Dec 2001, Maurice LeBrun wrote: > > > When I looked into this last spring (fixing several bugs in the process), I > > concluded we might be better off with a new algorithm. The original algorithm > > only follows lines, not regions. If one endpoint of the line is hidden but > > the other is not, it merely calculates the intersection point and draws from > > that point. Extending this to 2D and getting it right does not look easy to > > me. The existing shade extension is clever but I found the boundary > > conditions too messy to be able to make solid headway without considerable > > effort. > > Maurice, I am having trouble interpreting your words here since the previous > posts in this thread discussed both 2D and 3D shading which have separate > algorithms. I believe (although I am not sure) that part of your paragraph > may refer to a better algorithm for the 2D shading (which might be a good > idea, but there is currently no bug in that case), and part of the paragraph > to 3D shading (which does have a bug). Could you please clarify? I am > particularly interested in whether you think a new 3D shading algorithm is > required to fix the 3D shading bug. If so, I will drop it from the release > wish list. I'm talking about the 3d shading algorithm, which is bolted on top of the 3d perspective (surface) plot. Not the 2d shade-exclusion problem that was fixed previously. These are way different problems. The 3d perspective algorithm follows lines of a constant coordinate. It decides to draw or not-draw based on the condition: is it visible. If it crosses from visible to not-visible or vice versa in one segment, the intersection point is calculated and the segment drawn from there. Once that coordinate line is finished, the next one is started. So you see, the original algorithm has no concept of "regions" at all. The new shading code that is bolted on top of this only worked if the triangle to be shaded is entirely visible. If any of the three vertices is not visible, the triangle is not plotted at all, which gives rise to the visual effects you see in the demo. I was able to work out boundary conditions for some cases and thereby eliminate some of the unshaded areas, but not all. It turns out to be surprisingly complex -- after a few initial successes I had lots of spectacular failures with spiky triangles drawn all over the screen, and had to give up. At that point I concluded it might be simpler to start from scratch with a published 3d shading algorithm. -- Maurice LeBrun mj...@ga... |
|
From: Alan W. I. <ir...@be...> - 2001-12-15 23:01:24
|
Thanks, Maurice, for that clarification. This project (as well as my wish for dynamic tk and xwin drivers) is gone from the release wish list. So here is the revised list with some additional comments where progress has already been made. (1) Solve the python 2.1 segfault bug for example 9. Probably release critical. (2) Get documentation to build on my new Debian system. Release critical. (3) Document what I did recently for the cgm driver configuration. Hopefully, this will be the start of a new cookbook for the dynamic (and static) driver configuration. (4) Finish python examples and modify them to be exact replicas of the C examples as a consistency check on the python front end. (4a) Do the same for the tcl examples. (5) gdimage extended example including all the things to make a colour image work. (6) Finish Java examples (with commented out API when that is not available). Everything above this line is my responsibility. Everything below is someone else's responsibility, but I am willing to help with testing. **************************************** (7) Perfect cgm driver. DONE (thanks Andrew) except for some rare colour and width bugs that will probably have to wait for the next release for solution. (8) Finish W98 and W2000 changes. Apparently, Olof has made great progress here (in fact he is now completely satisfied with the driver), and he therefore intends to send me the definitive patch early next week. (9) Get command-line parameter parsing to work for octave x examples. DONE (Thanks, Joao). (10) Java API (Geoffrey, once I get some more examples ready for him). (11) Some refinement of the pyqt GUI. Allesandro has made some progress on the paging, but our discussion continues. (12) There may be some more plimage changes Joao has in mind, but I am not sure. I very much appreciate how everybody has responded for projects below the line (either by making excellent progress toward finishing them or else by making good arguments why these projects shouldn't be on the wish list for the release). If anybody has other short projects in mind which they would like to see done before the release, please feel free to add them to the list (below the line, of course....;-)) Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ On Sat, 15 Dec 2001, Maurice LeBrun wrote: > I'm talking about the 3d shading algorithm, which is bolted on top of the 3d > perspective (surface) plot. Not the 2d shade-exclusion problem that was fixed > previously. These are way different problems. > > The 3d perspective algorithm follows lines of a constant coordinate. It > decides to draw or not-draw based on the condition: is it visible. If it > crosses from visible to not-visible or vice versa in one segment, the > intersection point is calculated and the segment drawn from there. Once > that coordinate line is finished, the next one is started. So you see, the > original algorithm has no concept of "regions" at all. > > The new shading code that is bolted on top of this only worked if the triangle > to be shaded is entirely visible. If any of the three vertices is not > visible, the triangle is not plotted at all, which gives rise to the visual > effects you see in the demo. I was able to work out boundary conditions for > some cases and thereby eliminate some of the unshaded areas, but not all. > It turns out to be surprisingly complex -- after a few initial successes I had > lots of spectacular failures with spiky triangles drawn all over the screen, > and had to give up. At that point I concluded it might be simpler to start > from scratch with a published 3d shading algorithm. > > -- > Maurice LeBrun mj...@ga... > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X