> søn, 08 03 2009 kl. 01:04 +0100, skrev Martin Helm: > > thank you for your responses. I have no strong opinion about the right > > place for the functions. There are reasons to put it into the core (in > > matlab these are core functions), but there are also good reasons not to > > do that now. My main reason to put it into octave forge first is exactly > > that the default graphics backend of octave does not support the > > visualization which is needed for the iso* functions. If they are in OF > > they are at least accessible to everyone who uses jhandles with octave > > 3.0.x, but cannot work with the development version. > > Assuming that Octave 3.2 will be released in a couple of months then I > don't think we need to think too much about the 3.0.x series. But that's > just my opinion. >
Ok, I simply did not know when 3.2 will be released, so it seems to me that it is not a problem skipping the 3.0.x version and focus on 3.2. > > For the users who are working with gnuplot there is still a possibility > > to make use of that functions if they use some workaround like the one > > shown as attachment. Since this works I am pretty sure that there will be > > a possibility to enhance the patch faunction in octave also for gnuplot > > to show filled 3d patches. > > Just to make sure I understand: if the backend supports 3D filled > patches, then your code works, right? > That's correct. There is one functionality (isonormals) which simply has no visual effect if the backend has no support for defining lights. But I hope this restriction is acceptable. The function isonormals itself does not depend on the fact whether there is a light function. Maybe a warning should be shown or at least it needs to be documented that there is no visual benefit using it with gnuplot. But you can still use it to calculate the normal vectors for a vertex list this is completely independent of any graphics backend (like the other iso* functions, you can use it also for analytical reasons without any graphics backend). > I get the impression that you have an idea of how to make 3D patches > work in the gnuplot backend. If this is true, then I think it would be > wonderful if you could be persuaded into helping out implementing that > in the gnuplot backend. > Give me some time to look through the octave source code where these things are implemented, I need a proper understanding how it works before I can try to propose an enhancement and create a patch. > If 3D patches are possible in the gnuplot backend, then I really think > you should try to push your code into Octave core. If 3D patches are > unrealistic in gnuplot, then I think it would be best to have a package > here at Octave-Forge until the FLTK backend stabilises. > The 3d patches with gnuplot should be possible in octave, but I need to understand how to put it into octave without producing unwanted side effects for other 3d functions with gnuplot (in the worst case this can be a reason which makes it impossible). If I cannot manage it, I will ask for help. What is the right place for that (help list, maintainer ...)? > At this point I think you should start a thread about these issues at > the [email protected] list. Is that okay with you? > > Søren That's ok with me, thank you. - mh ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Octave-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
