basic implementation for isosurface, isocolors, isonormals

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

basic implementation for isosurface, isocolors, isonormals

martin_helm
Dear Octave maintainers,

recently I made some preliminary implementation for isocolors, isonormals,
isosurface for my own use which I would like to share (isocaps will follow in
the near future). My first intention was to make a package at octave-forge. As
it turned out in the discussion at the OF mailing list that this functions
should go into octave itself  because these are base matlab functions, I start
this thread to continue the discussion which can be found at

http://sourceforge.net/mailarchive/forum.php?thread_name=200903051754.35446.martin%40mhelm.de&forum_name=octave-
dev

My functions can be found at
http://www.mhelm.de/octave/pkg/visualize3d-0.1.5.tar.gz
and some examples
http://www.mhelm.de/octave/index.html

I try to summarize the previous discussion:

The iso* functions need a graphics backend which is able to visualize filled
3d patches (at least triangle patches) if you want to visualize the results in
a matlab compatible way.

This is at the moment possible with the fltk backend and also with the
jhandles package but not with the gnuplot backend.

As discussed in the mailig list mentioned above there might be a chance to
make filled 3d patches possible also with gnuplot for at least triangle 3d
patches (using pm3d), but it is not completely sure at the moment if this will
work or how fast it can be done.

So I would be glad to receive some thoughts from you if you see this functions
as octave core functions (with the limitation in mind that they cannot be used
with gnuplot in the worst case) or as an addon which belongs to octave-forge.

I would also like to restart the discussion about the possibility to introduce
(a subset of) filled 3d patches with gnuplot backend here.

Regards
Martin Helm


Reply | Threaded
Open this post in threaded view
|

Re: basic implementation for isosurface, isocolors, isonormals

bpabbott
Administrator

On Mar 9, 2009, at 11:24 PM, Martin Helm wrote:

> Dear Octave maintainers,
>
> recently I made some preliminary implementation for isocolors,  
> isonormals,
> isosurface for my own use which I would like to share (isocaps will  
> follow in
> the near future). My first intention was to make a package at octave-
> forge. As
> it turned out in the discussion at the OF mailing list that this  
> functions
> should go into octave itself  because these are base matlab  
> functions, I start
> this thread to continue the discussion which can be found at
>
> http://sourceforge.net/mailarchive/forum.php?thread_name=200903051754.35446.martin%40mhelm.de&forum_name=octave-
> dev
>
> My functions can be found at
> http://www.mhelm.de/octave/pkg/visualize3d-0.1.5.tar.gz
> and some examples
> http://www.mhelm.de/octave/index.html
>
> I try to summarize the previous discussion:
>
> The iso* functions need a graphics backend which is able to  
> visualize filled
> 3d patches (at least triangle patches) if you want to visualize the  
> results in
> a matlab compatible way.
>
> This is at the moment possible with the fltk backend and also with the
> jhandles package but not with the gnuplot backend.
>
> As discussed in the mailig list mentioned above there might be a  
> chance to
> make filled 3d patches possible also with gnuplot for at least  
> triangle 3d
> patches (using pm3d), but it is not completely sure at the moment if  
> this will
> work or how fast it can be done.
>
> So I would be glad to receive some thoughts from you if you see this  
> functions
> as octave core functions (with the limitation in mind that they  
> cannot be used
> with gnuplot in the worst case) or as an addon which belongs to  
> octave-forge.
>
> I would also like to restart the discussion about the possibility to  
> introduce
> (a subset of) filled 3d patches with gnuplot backend here.
>
> Regards
> Martin Helm


Martin,

I'm interested in understanding what needs to be improved in the  
gnuplot backend to support this functionality.

Are 3D patches all that is needed? ... my ignorance might be showing,  
but is there any reason gnuplot's splot can't do the job?

Ben
Reply | Threaded
Open this post in threaded view
|

Re: basic implementation for isosurface, isocolors, isonormals

martin_helm
> On Mar 9, 2009, at 11:24 PM, Martin Helm wrote:
> > Dear Octave maintainers,
> >
> > recently I made some preliminary implementation for isocolors,
> > isonormals,
> > isosurface for my own use which I would like to share (isocaps will
> > follow in
> > the near future). My first intention was to make a package at octave-
> > forge. As
> > it turned out in the discussion at the OF mailing list that this
> > functions
> > should go into octave itself  because these are base matlab
> > functions, I start
> > this thread to continue the discussion which can be found at
> >
> > http://sourceforge.net/mailarchive/forum.php?thread_name=200903051754.354
> >46.martin%40mhelm.de&forum_name=octave- dev
> >
> > My functions can be found at
> > http://www.mhelm.de/octave/pkg/visualize3d-0.1.5.tar.gz
> > and some examples
> > http://www.mhelm.de/octave/index.html
> >
> > I try to summarize the previous discussion:
> >
> > The iso* functions need a graphics backend which is able to
> > visualize filled
> > 3d patches (at least triangle patches) if you want to visualize the
> > results in
> > a matlab compatible way.
> >
> > This is at the moment possible with the fltk backend and also with the
> > jhandles package but not with the gnuplot backend.
> >
> > As discussed in the mailig list mentioned above there might be a
> > chance to
> > make filled 3d patches possible also with gnuplot for at least
> > triangle 3d
> > patches (using pm3d), but it is not completely sure at the moment if
> > this will
> > work or how fast it can be done.
> >
> > So I would be glad to receive some thoughts from you if you see this
> > functions
> > as octave core functions (with the limitation in mind that they
> > cannot be used
> > with gnuplot in the worst case) or as an addon which belongs to
> > octave-forge.
> >
> > I would also like to restart the discussion about the possibility to
> > introduce
> > (a subset of) filled 3d patches with gnuplot backend here.
> >
> > Regards
> > Martin Helm
>
> Martin,
>
> I'm interested in understanding what needs to be improved in the
> gnuplot backend to support this functionality.
>
> Are 3D patches all that is needed? ... my ignorance might be showing,
> but is there any reason gnuplot's splot can't do the job?
>
> Ben

Hi Ben,

in principle gnuplot can do it. But I cannot oversee how it fits into the octave drawing functions at the moment (I need to look into the code later, I have no access to octave now).
The difference between 2d and 3d patches with gnuplot is that it is not possible to use the same syntax (2d uses a filled curve style which does not exist for 3d).

The very trivial example below shows that gnuplot renders a triangle mesh from the isosurface function with a special syntax for the data file without problems, but for sure more details have to be taken into account like EdgeColor (I did not try this at the moment) and FaceVertexCData.

N=30;
x = linspace(0, 4, N);
y = linspace(0, 4, N);
z = linspace(0, 4, N);

[ xx, yy, zz ] = meshgrid(x, y, z);

data = 1./((xx-2).^2 + (yy-2).^2 + (zz-2).^2) + ...
  2./((xx-1).^2 + (yy-1).^2 + (zz-1).^2);
[T, p, c]  = isosurface(xx,yy,zz,data,3, zz);

## workaround for visualization with gnuplot
tmp = tmpnam();
[fid, msg] = fopen(tmp, "w");
if ( fid == -1 )
  error("Could not create temporary data file\n%s", msg);
endif
for ii = 1:size(T, 1)
  fprintf(fid, "%f %f %f %f\n", p(T(ii,1), 1), p(T(ii,1), 2), p(T(ii,1), 3), c(T(ii,1)));
  fprintf(fid, "%f %f %f %f\n\n", p(T(ii,2), 1), p(T(ii,2), 2), p(T(ii,2), 3), c(T(ii,2)));
  fprintf(fid, "%f %f %f %f\n", p(T(ii,3), 1), p(T(ii,3), 2), p(T(ii,3), 3), c(T(ii,3)));
  fprintf(fid, "%f %f %f %f\n\n\n", p(T(ii,3), 1), p(T(ii,3), 2), p(T(ii,3), 3), c(T(ii,3)));
endfor
fclose(fid);
cmd = sprintf("gnuplot -p -e \"set pm3d;set style data pm3d;set pm3d depthorder;splot '%s' using 1:2:3:4\"", tmp);
system(cmd, 0, "async");
Reply | Threaded
Open this post in threaded view
|

Re: basic implementation for isosurface, isocolors, isonormals

David Bateman-2
On Mon, Mar 09, 2009 at 05:34:29PM +0100, Martin Helm wrote:
> in principle gnuplot can do it. But I cannot oversee how it fits into the octave drawing functions at the moment (I need to look into the code later, I have no access to octave now).
> The difference between 2d and 3d patches with gnuplot is that it is not possible to use the same syntax (2d uses a filled curve style which does not exist for 3d).


I have a changeset that partly works to implement 3d triangular patches.
Give me a few hours and I'll send it

D.
Reply | Threaded
Open this post in threaded view
|

Re: basic implementation for isosurface, isocolors, isonormals

David Bateman-2
On Mon, Mar 09, 2009 at 08:33:06PM +0100, [hidden email] wrote:
> On Mon, Mar 09, 2009 at 05:34:29PM +0100, Martin Helm wrote:
> > in principle gnuplot can do it. But I cannot oversee how it fits into the octave drawing functions at the moment (I need to look into the code later, I have no access to octave now).
> > The difference between 2d and 3d patches with gnuplot is that it is not possible to use the same syntax (2d uses a filled curve style which does not exist for 3d).
>
>
> I have a changeset that partly works to implement 3d triangular patches.
> Give me a few hours and I'll send it


Ok the attached patch against the tip adds triaangular 3D patches. Its
not optimal as each patch is drawn individually, and that should be
rewritten, but the example from isosurface works.. The patch will need a
bit more work before commiting it including

* Document new functions in plot.txi and NEWS
* Style fixes in the added functions
* isosurface called with no args doesn't yet plot as expected.

In any case its a start and should allow isosurface and trisurf to be
written.

D.


patch.isosurface.bz2 (13K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: basic implementation for isosurface, isocolors, isonormals

martin_helm
> On Mon, Mar 09, 2009 at 08:33:06PM +0100, [hidden email] wrote:

> > On Mon, Mar 09, 2009 at 05:34:29PM +0100, Martin Helm wrote:
> > > in principle gnuplot can do it. But I cannot oversee how it fits into
> > > the octave drawing functions at the moment (I need to look into the
> > > code later, I have no access to octave now). The difference between 2d
> > > and 3d patches with gnuplot is that it is not possible to use the same
> > > syntax (2d uses a filled curve style which does not exist for 3d).
> >
> > I have a changeset that partly works to implement 3d triangular patches.
> > Give me a few hours and I'll send it
>
> Ok the attached patch against the tip adds triaangular 3D patches. Its
> not optimal as each patch is drawn individually, and that should be
> rewritten, but the example from isosurface works.. The patch will need a
> bit more work before commiting it including
>
> * Document new functions in plot.txi and NEWS
> * Style fixes in the added functions
> * isosurface called with no args doesn't yet plot as expected.
>
> In any case its a start and should allow isosurface and trisurf to be
> written.
>
> D.
Sorry for the late followup.
I changed the iso* functions and the helper functions a little bit (avoiding
assignments of the form [] = [], which can lead to trouble otherwise) and
tried to adjust the style to be more compliant with what I can see in the
contribution section of the octave manual. I am pretty sure that there are
further changes to the style to be done.
The patches include the changes to plot/Makefile.in and add the new functions
isosurface, isocolors, isonormals, __interp_cube__ and __marching_cube__.
Thanks to Thomas Treichl who helps with the documentation and examples for the
functions.
I made the patch from scratch not against your patch. I do not know if this is
ok or not.
Please tell me how to proceede in the correct way.
With the new __go_draw_axes__ (gnuplot backend) I first ran into trouble
because I use gnuplot 4.3 and this has the transparency feature which screws
up the commands sent to gnuplot.
With 4.2 it works with some side effects and without coloring
(FaceVertexCData). It seems to me that something like
unset hidden3d
set pm3d
set pm3d depthorder hidden3d <linestyle> explicit
is neccessary to avoid some strange visual behavior (the patch is opaque but
the axes are visible even if they should be hidden by the patch) the hidden3d
(not the pm3d hidden3d) setting seems to be responsible for that.
Hope I will find time over the weekend to dive deeper into it and understand
the details.

- mh
 

isofunctions.diff.bz2 (13K) Download Attachment
isofunctions_makefile_in.diff.bz2 (694 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: basic implementation for isosurface, isocolors, isonormals

martin_helm
> Sorry for the late followup.

> I changed the iso* functions and the helper functions a little bit
> (avoiding assignments of the form [] = [], which can lead to trouble
> otherwise) and tried to adjust the style to be more compliant with what I
> can see in the contribution section of the octave manual. I am pretty sure
> that there are further changes to the style to be done.
> The patches include the changes to plot/Makefile.in and add the new
> functions isosurface, isocolors, isonormals, __interp_cube__ and
> __marching_cube__. Thanks to Thomas Treichl who helps with the
> documentation and examples for the functions.
> I made the patch from scratch not against your patch. I do not know if this
> is ok or not.
> Please tell me how to proceede in the correct way.
> With the new __go_draw_axes__ (gnuplot backend) I first ran into trouble
> because I use gnuplot 4.3 and this has the transparency feature which
> screws up the commands sent to gnuplot.
> With 4.2 it works with some side effects and without coloring
> (FaceVertexCData). It seems to me that something like
> unset hidden3d
> set pm3d
> set pm3d depthorder hidden3d <linestyle> explicit
> is neccessary to avoid some strange visual behavior (the patch is opaque
> but the axes are visible even if they should be hidden by the patch) the
> hidden3d (not the pm3d hidden3d) setting seems to be responsible for that.
> Hope I will find time over the weekend to dive deeper into it and
> understand the details.
>
> - mh
I forgot the changesets for the empty spaces before the calling parentheses.



isofunctions_2.diff.bz2 (6K) Download Attachment
isofunctions_3.diff.bz2 (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: basic implementation for isosurface, isocolors, isonormals

David Bateman-2
Martin Helm wrote:

>> Sorry for the late followup.
>> I changed the iso* functions and the helper functions a little bit
>> (avoiding assignments of the form [] = [], which can lead to trouble
>> otherwise) and tried to adjust the style to be more compliant with what I
>> can see in the contribution section of the octave manual. I am pretty sure
>> that there are further changes to the style to be done.
>> The patches include the changes to plot/Makefile.in and add the new
>> functions isosurface, isocolors, isonormals, __interp_cube__ and
>> __marching_cube__. Thanks to Thomas Treichl who helps with the
>> documentation and examples for the functions.
>> I made the patch from scratch not against your patch. I do not know if this
>> is ok or not.
>> Please tell me how to proceede in the correct way.
>>    
Hey its your code, yours get precedence over my version.

>> With the new __go_draw_axes__ (gnuplot backend) I first ran into trouble
>> because I use gnuplot 4.3 and this has the transparency feature which
>> screws up the commands sent to gnuplot.
>> With 4.2 it works with some side effects and without coloring
>> (FaceVertexCData). It seems to me that something like
>> unset hidden3d
>> set pm3d
>> set pm3d depthorder hidden3d <linestyle> explicit
>> is neccessary to avoid some strange visual behavior (the patch is opaque
>> but the axes are visible even if they should be hidden by the patch) the
>> hidden3d (not the pm3d hidden3d) setting seems to be responsible for that.
>> Hope I will find time over the weekend to dive deeper into it and
>> understand the details.
>>    
Sigh, I don't really have much time to look at this, but its clear that
we can't include this code till the gnuplot backend works with it

D.


>> - mh
>>    
>
> I forgot the changesets for the empty spaces before the calling parentheses.
>
>
>  


--
David Bateman                                [hidden email]
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)

Reply | Threaded
Open this post in threaded view
|

Re: basic implementation for isosurface, isocolors, isonormals

David Bateman-2
In reply to this post by martin_helm
Martin Helm wrote:
>> Sorry for the late followup.
>> I changed the iso* functions and the helper functions a little bit
>> (avoiding assignments of the form [] = [], which can lead to trouble
>> otherwise) and tried to adjust the style to be more compliant with what I
>> can see in the contribution section of the octave manual. I am pretty sure
>> that there are further changes to the style to be done.
>>    
It doesn't look too bad as is..

>> The patches include the changes to plot/Makefile.in and add the new
>> functions isosurface, isocolors, isonormals, __interp_cube__ and
>> __marching_cube__. Thanks to Thomas Treichl who helps with the
>> documentation and examples for the functions.
>> I made the patch from scratch not against your patch. I do not know if this
>> is ok or not.
>>    
The examples and help text seem to work fine and are parsed correctly by
makeinfo

>> Please tell me how to proceede in the correct way.
>> With the new __go_draw_axes__ (gnuplot backend) I first ran into trouble
>> because I use gnuplot 4.3 and this has the transparency feature which
>> screws up the commands sent to gnuplot.
>> With 4.2 it works with some side effects and without coloring
>> (FaceVertexCData). It seems to me that something like
>> unset hidden3d
>> set pm3d
>> set pm3d depthorder hidden3d <linestyle> explicit
>> is neccessary to avoid some strange visual behavior (the patch is opaque
>> but the axes are visible even if they should be hidden by the patch) the
>> hidden3d (not the pm3d hidden3d) setting seems to be responsible for that.
>> Hope I will find time over the weekend to dive deeper into it and
>> understand the details.
>>    
I don't think the hiding of the axis is a really major issue though I
also see some other artifacts that seem to be due to some weird issue in
gnuplot with the depthorder, and I don't see the fix for it at the
moment. Also it appears that FaceVertexCdata is not really implemented
yet and so these values aren't respected at all. In fact the patch
properties have a number of derived properties that should be treated
specially, like the differences between the [xyz]data and vertices and
faces data.. The derivation of one of these properties from another is
currently handled in the patch function itself.. However this doesn't
make sense as then if the user uses the "set" function to change one of
these properties the others won't be changed appropriately..

The way to fix it is either to treat the issue in the set/get methods of
the patch type or to add callbacks in the patch functions.. Callbacks
are probably the easiest method as we can stay in the scripting
language.. I'll look at this as I'm interested in getting the iso*
functions into Octave..

D.



>
> I forgot the changesets for the empty spaces before the calling parentheses.
>
>
>  


--
David Bateman                                [hidden email]
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)

Reply | Threaded
Open this post in threaded view
|

Re: basic implementation for isosurface, isocolors, isonormals

Thomas Treichl
David Bateman schrieb:

> I don't think the hiding of the axis is a really major issue though I
> also see some other artifacts that seem to be due to some weird issue in
> gnuplot with the depthorder, and I don't see the fix for it at the
> moment. Also it appears that FaceVertexCdata is not really implemented
> yet and so these values aren't respected at all. In fact the patch
> properties have a number of derived properties that should be treated
> specially, like the differences between the [xyz]data and vertices and
> faces data.. The derivation of one of these properties from another is
> currently handled in the patch function itself.. However this doesn't
> make sense as then if the user uses the "set" function to change one of
> these properties the others won't be changed appropriately..
>
> The way to fix it is either to treat the issue in the set/get methods of
> the patch type or to add callbacks in the patch functions.. Callbacks
> are probably the easiest method as we can stay in the scripting
> language.. I'll look at this as I'm interested in getting the iso*
> functions into Octave..

Hi,

I just wanted to know, what the final maintainers' decision about inclusion of
the iso* into the core Octave sources is? I think that I can work on creating a
changeset because I don't want these codes get forgotten...

If you say you currently can't decide or you think it is better to not include
the files right now or whatever then I think we should at least host Martin's
functions at OF right now?

Best regards,

   Thomas

PS. Will my patch for __patch__.m be applied? Cf.
https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-March/011273.html
Reply | Threaded
Open this post in threaded view
|

Re: basic implementation for isosurface, isocolors, isonormals

David Bateman-2
Thomas Treichl wrote:

> David Bateman schrieb:
>> I don't think the hiding of the axis is a really major issue though I
>> also see some other artifacts that seem to be due to some weird issue
>> in gnuplot with the depthorder, and I don't see the fix for it at the
>> moment. Also it appears that FaceVertexCdata is not really
>> implemented yet and so these values aren't respected at all. In fact
>> the patch properties have a number of derived properties that should
>> be treated specially, like the differences between the [xyz]data and
>> vertices and faces data.. The derivation of one of these properties
>> from another is currently handled in the patch function itself..
>> However this doesn't make sense as then if the user uses the "set"
>> function to change one of these properties the others won't be
>> changed appropriately..
>>
>> The way to fix it is either to treat the issue in the set/get methods
>> of the patch type or to add callbacks in the patch functions..
>> Callbacks are probably the easiest method as we can stay in the
>> scripting language.. I'll look at this as I'm interested in getting
>> the iso* functions into Octave..
>
> Hi,
>
> I just wanted to know, what the final maintainers' decision about
> inclusion of the iso* into the core Octave sources is? I think that I
> can work on creating a changeset because I don't want these codes get
> forgotten...
>
> If you say you currently can't decide or you think it is better to not
> include the files right now or whatever then I think we should at
> least host Martin's functions at OF right now?
I'm working on rewriting the __patch__ to add listeners such that
changes to the {x|y|z|c}data properties also changes the faces, vertices
and facevertexcdata properties appropriately. Without this the previous
code was buggy and so not of a quality to be included in Octave.. In
fact I have most of this going now and hopefully will send something
soon (tonight if I'm fast). I also in passing added the trisurf function.

> PS. Will my patch for __patch__.m be applied? Cf.
> https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-March/011273.html 
>
>
Opps, ok in fact I independently reimplemented that in the version I'm
currently working on

D.

--
David Bateman                                [hidden email]
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)

Reply | Threaded
Open this post in threaded view
|

Re: basic implementation for isosurface, isocolors, isonormals

Thomas Treichl
David Bateman schrieb:

> Thomas Treichl wrote:
>> David Bateman schrieb:
>>> I don't think the hiding of the axis is a really major issue though I
>>> also see some other artifacts that seem to be due to some weird issue
>>> in gnuplot with the depthorder, and I don't see the fix for it at the
>>> moment. Also it appears that FaceVertexCdata is not really
>>> implemented yet and so these values aren't respected at all. In fact
>>> the patch properties have a number of derived properties that should
>>> be treated specially, like the differences between the [xyz]data and
>>> vertices and faces data.. The derivation of one of these properties
>>> from another is currently handled in the patch function itself..
>>> However this doesn't make sense as then if the user uses the "set"
>>> function to change one of these properties the others won't be
>>> changed appropriately..
>>>
>>> The way to fix it is either to treat the issue in the set/get methods
>>> of the patch type or to add callbacks in the patch functions..
>>> Callbacks are probably the easiest method as we can stay in the
>>> scripting language.. I'll look at this as I'm interested in getting
>>> the iso* functions into Octave..
>>
>> Hi,
>>
>> I just wanted to know, what the final maintainers' decision about
>> inclusion of the iso* into the core Octave sources is? I think that I
>> can work on creating a changeset because I don't want these codes get
>> forgotten...
>>
>> If you say you currently can't decide or you think it is better to not
>> include the files right now or whatever then I think we should at
>> least host Martin's functions at OF right now?
> I'm working on rewriting the __patch__ to add listeners such that
> changes to the {x|y|z|c}data properties also changes the faces, vertices
> and facevertexcdata properties appropriately. Without this the previous
> code was buggy and so not of a quality to be included in Octave.. In
> fact I have most of this going now and hopefully will send something
> soon (tonight if I'm fast). I also in passing added the trisurf function.

Ah, ok, thanks. And absolutely *don't stress* to make that happen ;)

   Thomas
Reply | Threaded
Open this post in threaded view
|

Re: basic implementation for isosurface, isocolors, isonormals

David Bateman-2
Thomas Treichl wrote:

> David Bateman schrieb:
>> Thomas Treichl wrote:
>>> David Bateman schrieb:
>>>> I don't think the hiding of the axis is a really major issue though
>>>> I also see some other artifacts that seem to be due to some weird
>>>> issue in gnuplot with the depthorder, and I don't see the fix for
>>>> it at the moment. Also it appears that FaceVertexCdata is not
>>>> really implemented yet and so these values aren't respected at all.
>>>> In fact the patch properties have a number of derived properties
>>>> that should be treated specially, like the differences between the
>>>> [xyz]data and vertices and faces data.. The derivation of one of
>>>> these properties from another is currently handled in the patch
>>>> function itself.. However this doesn't make sense as then if the
>>>> user uses the "set" function to change one of these properties the
>>>> others won't be changed appropriately..
>>>>
>>>> The way to fix it is either to treat the issue in the set/get
>>>> methods of the patch type or to add callbacks in the patch
>>>> functions.. Callbacks are probably the easiest method as we can
>>>> stay in the scripting language.. I'll look at this as I'm
>>>> interested in getting the iso* functions into Octave..
>>>
>>> Hi,
>>>
>>> I just wanted to know, what the final maintainers' decision about
>>> inclusion of the iso* into the core Octave sources is? I think that
>>> I can work on creating a changeset because I don't want these codes
>>> get forgotten...
>>>
>>> If you say you currently can't decide or you think it is better to
>>> not include the files right now or whatever then I think we should
>>> at least host Martin's functions at OF right now?
>> I'm working on rewriting the __patch__ to add listeners such that
>> changes to the {x|y|z|c}data properties also changes the faces,
>> vertices and facevertexcdata properties appropriately. Without this
>> the previous code was buggy and so not of a quality to be included in
>> Octave.. In fact I have most of this going now and hopefully will
>> send something soon (tonight if I'm fast). I also in passing added
>> the trisurf function.
>
> Ah, ok, thanks. And absolutely *don't stress* to make that happen ;)
>
>   Thomas
>
Ok, well it was a little bit harder than I thought for a few reasons

1) gnuplot's depth order pm3d code only works for a single surface and
so a set of patches that need to be depth sorted need to be plotted with
a single splot command
2) The gnuplot binary file format doesn't support "index" for splot and
so constraint 1) means the data has to be written as ASCII
3) As pm3d uses the color palette, any fixed color patches need to have
their color added to the colormap, and then the other things plotted
with the colormap need to be treated carefully..

In any  case I committed the attached patch that appears to work fine
for all the tests I ran with the gnuplot CVS version. One issue I have
is with gnuplot 4.2.4 I see the attached for the command
"demo('patch',6); colorbar" for the X11 terminal. This appears to be a
gnuplot bug as it works for other terminals like png, eps, etc and it
works for the CVS version of gnuplot.. Should I care about this bug?

D.

--
David Bateman                                [hidden email]
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)


patch.isosurface.bz2 (22K) Download Attachment
bad2.png (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: basic implementation for isosurface, isocolors, isonormals

Daniel Sebald
David Bateman wrote:

> Thomas Treichl wrote:
>
>> David Bateman schrieb:
>>
>>> Thomas Treichl wrote:
>>>
>>>> David Bateman schrieb:
>>>>
>>>>> I don't think the hiding of the axis is a really major issue though
>>>>> I also see some other artifacts that seem to be due to some weird
>>>>> issue in gnuplot with the depthorder, and I don't see the fix for
>>>>> it at the moment. Also it appears that FaceVertexCdata is not
>>>>> really implemented yet and so these values aren't respected at all.
>>>>> In fact the patch properties have a number of derived properties
>>>>> that should be treated specially, like the differences between the
>>>>> [xyz]data and vertices and faces data.. The derivation of one of
>>>>> these properties from another is currently handled in the patch
>>>>> function itself.. However this doesn't make sense as then if the
>>>>> user uses the "set" function to change one of these properties the
>>>>> others won't be changed appropriately..
>>>>>
>>>>> The way to fix it is either to treat the issue in the set/get
>>>>> methods of the patch type or to add callbacks in the patch
>>>>> functions.. Callbacks are probably the easiest method as we can
>>>>> stay in the scripting language.. I'll look at this as I'm
>>>>> interested in getting the iso* functions into Octave..
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I just wanted to know, what the final maintainers' decision about
>>>> inclusion of the iso* into the core Octave sources is? I think that
>>>> I can work on creating a changeset because I don't want these codes
>>>> get forgotten...
>>>>
>>>> If you say you currently can't decide or you think it is better to
>>>> not include the files right now or whatever then I think we should
>>>> at least host Martin's functions at OF right now?
>>>
>>> I'm working on rewriting the __patch__ to add listeners such that
>>> changes to the {x|y|z|c}data properties also changes the faces,
>>> vertices and facevertexcdata properties appropriately. Without this
>>> the previous code was buggy and so not of a quality to be included in
>>> Octave.. In fact I have most of this going now and hopefully will
>>> send something soon (tonight if I'm fast). I also in passing added
>>> the trisurf function.
>>
>>
>> Ah, ok, thanks. And absolutely *don't stress* to make that happen ;)
>>
>>   Thomas
>>
> Ok, well it was a little bit harder than I thought for a few reasons
>
> 1) gnuplot's depth order pm3d code only works for a single surface and
> so a set of patches that need to be depth sorted need to be plotted with
> a single splot command
> 2) The gnuplot binary file format doesn't support "index" for splot and
> so constraint 1) means the data has to be written as ASCII

It's been a long time since I looked at the binary mode of gnuplot, but my memory is that I implemented almost all the same features and syntax as for ASCII.  There is a binary mode for which "index" doesn't work and that is the original gnuplot matrix format.  (If the data in the file is in a matrix format, "index" makes no sense.)  However, Petr reported some gnuplot problems with binary mode just recently, and he posted a code snippet change related to a matrix flag.  You may be getting an error message when you shouldn't.


> 3) As pm3d uses the color palette, any fixed color patches need to have
> their color added to the colormap, and then the other things plotted
> with the colormap need to be treated carefully..
>
> In any  case I committed the attached patch that appears to work fine
> for all the tests I ran with the gnuplot CVS version. One issue I have
> is with gnuplot 4.2.4 I see the attached for the command
> "demo('patch',6); colorbar" for the X11 terminal. This appears to be a
> gnuplot bug as it works for other terminals like png, eps, etc and it
> works for the CVS version of gnuplot.. Should I care about this bug?

No, but if you have a moment, please post a bug report at:

http://sourceforge.net/tracker/?func=add&group_id=2055&atid=102055

and attach the figure.

Dan
Reply | Threaded
Open this post in threaded view
|

Re: basic implementation for isosurface, isocolors, isonormals

Thomas Treichl
In reply to this post by David Bateman-2
David Bateman schrieb:

> Ok, well it was a little bit harder than I thought for a few reasons
>
> 1) gnuplot's depth order pm3d code only works for a single surface and
> so a set of patches that need to be depth sorted need to be plotted with
> a single splot command
> 2) The gnuplot binary file format doesn't support "index" for splot and
> so constraint 1) means the data has to be written as ASCII
> 3) As pm3d uses the color palette, any fixed color patches need to have
> their color added to the colormap, and then the other things plotted
> with the colormap need to be treated carefully..
>
> In any  case I committed the attached patch that appears to work fine
> for all the tests I ran with the gnuplot CVS version. One issue I have
> is with gnuplot 4.2.4 I see the attached for the command
> "demo('patch',6); colorbar" for the X11 terminal. This appears to be a
> gnuplot bug as it works for other terminals like png, eps, etc and it
> works for the CVS version of gnuplot.. Should I care about this bug?

Hi David,

thanks for this work. However, I've some smaller problems running the new
__patch__.m command. The function "field" you're using in lines 37, 39, 42 and
further is undefined to me. Is this another function file you are using but
maybe forgot to check in?

Next, if I try to run any of the demos from the help texts of isosurface or
isocolors then none does work anymore because of an error that looks like this,
for example

   octave:22> N = 15;    ## Increase number of vertices in each direction
   octave:23> iso = .4;  ## Change isovalue to .1 to display a sphere
   octave:24> lin = linspace (0, 2, N);
   octave:25> [x, y, z] = meshgrid (lin, lin, lin);
   octave:26> c = abs ((x-.5).^2 + (y-.5).^2 + (z-.5).^2);
   octave:27> figure (); ## Open another figure window
   octave:28>
   octave:28> subplot (2, 2, 1); view (-38, 20);
   octave:29> [f, v] = isosurface (x, y, z, c, iso);
   octave:30> p = patch ("Faces", f, "Vertices", v, "EdgeColor", "none");
   error: A(I): Index exceeds matrix dimension.
   error: called from:
   error:   /Users/Thomas/Development/octave/scripts/plot/__patch__.m at
   line 220, column 4
   error:   /Users/Thomas/Development/octave/scripts/plot/__patch__.m at
   line 138, column 12
   error: `tmp' undefined near line 59 column 14
   error: called from:
   error:   /Users/Thomas/Development/octave/scripts/plot/patch.m at line 59,
   column 12

Any ideas? Thanks,

   Thomas
Reply | Threaded
Open this post in threaded view
|

Re: basic implementation for isosurface, isocolors, isonormals

David Bateman-2
Thomas Treichl wrote:

> David Bateman schrieb:
>> Ok, well it was a little bit harder than I thought for a few reasons
>>
>> 1) gnuplot's depth order pm3d code only works for a single surface
>> and so a set of patches that need to be depth sorted need to be
>> plotted with a single splot command
>> 2) The gnuplot binary file format doesn't support "index" for splot
>> and so constraint 1) means the data has to be written as ASCII
>> 3) As pm3d uses the color palette, any fixed color patches need to
>> have their color added to the colormap, and then the other things
>> plotted with the colormap need to be treated carefully..
>>
>> In any  case I committed the attached patch that appears to work fine
>> for all the tests I ran with the gnuplot CVS version. One issue I
>> have is with gnuplot 4.2.4 I see the attached for the command
>> "demo('patch',6); colorbar" for the X11 terminal. This appears to be
>> a gnuplot bug as it works for other terminals like png, eps, etc and
>> it works for the CVS version of gnuplot.. Should I care about this bug?
>
> Hi David,
>
> thanks for this work. However, I've some smaller problems running the
> new __patch__.m command. The function "field" you're using in lines
> 37, 39, 42 and further is undefined to me. Is this another function
> file you are using but maybe forgot to check in?
No it was supposed to be "getfield" and I have a function field in my
path that was basically an alias.

>
> Next, if I try to run any of the demos from the help texts of
> isosurface or isocolors then none does work anymore because of an
> error that looks like this, for example
>
>   octave:22> N = 15;    ## Increase number of vertices in each direction
>   octave:23> iso = .4;  ## Change isovalue to .1 to display a sphere
>   octave:24> lin = linspace (0, 2, N);
>   octave:25> [x, y, z] = meshgrid (lin, lin, lin);
>   octave:26> c = abs ((x-.5).^2 + (y-.5).^2 + (z-.5).^2);
>   octave:27> figure (); ## Open another figure window
>   octave:28>
>   octave:28> subplot (2, 2, 1); view (-38, 20);
>   octave:29> [f, v] = isosurface (x, y, z, c, iso);
>   octave:30> p = patch ("Faces", f, "Vertices", v, "EdgeColor", "none");
>   error: A(I): Index exceeds matrix dimension.
>   error: called from:
>   error:   /Users/Thomas/Development/octave/scripts/plot/__patch__.m at
>   line 220, column 4
>   error:   /Users/Thomas/Development/octave/scripts/plot/__patch__.m at
>   line 138, column 12
>   error: `tmp' undefined near line 59 column 14
>   error: called from:
>   error:   /Users/Thomas/Development/octave/scripts/plot/patch.m at
> line 59,
>   column 12
>
> Any ideas? Thanks,
>
>   Thomas
>
The demo's work as in demo("patch"), but yes effectively there is an
issue with the demo in the help text.. I'll look at that but not today

D.


--
David Bateman                                [hidden email]
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)

Reply | Threaded
Open this post in threaded view
|

Re: basic implementation for isosurface, isocolors, isonormals

martin_helm
> Thomas Treichl wrote:
> > David Bateman schrieb:
> >> Ok, well it was a little bit harder than I thought for a few reasons
> >>
> >> 1) gnuplot's depth order pm3d code only works for a single surface
> >> and so a set of patches that need to be depth sorted need to be
> >> plotted with a single splot command
> >> 2) The gnuplot binary file format doesn't support "index" for splot
> >> and so constraint 1) means the data has to be written as ASCII
> >> 3) As pm3d uses the color palette, any fixed color patches need to
> >> have their color added to the colormap, and then the other things
> >> plotted with the colormap need to be treated carefully..
> >>
> >> In any  case I committed the attached patch that appears to work fine
> >> for all the tests I ran with the gnuplot CVS version. One issue I
> >> have is with gnuplot 4.2.4 I see the attached for the command
> >> "demo('patch',6); colorbar" for the X11 terminal. This appears to be
> >> a gnuplot bug as it works for other terminals like png, eps, etc and
> >> it works for the CVS version of gnuplot.. Should I care about this bug?
> >
> > Hi David,
> >
> > thanks for this work. However, I've some smaller problems running the
> > new __patch__.m command. The function "field" you're using in lines
> > 37, 39, 42 and further is undefined to me. Is this another function
> > file you are using but maybe forgot to check in?
>
> No it was supposed to be "getfield" and I have a function field in my
> path that was basically an alias.
>
> > Next, if I try to run any of the demos from the help texts of
> > isosurface or isocolors then none does work anymore because of an
> > error that looks like this, for example
> >
> >   octave:22> N = 15;    ## Increase number of vertices in each direction
> >   octave:23> iso = .4;  ## Change isovalue to .1 to display a sphere
> >   octave:24> lin = linspace (0, 2, N);
> >   octave:25> [x, y, z] = meshgrid (lin, lin, lin);
> >   octave:26> c = abs ((x-.5).^2 + (y-.5).^2 + (z-.5).^2);
> >   octave:27> figure (); ## Open another figure window
> >   octave:28>
> >   octave:28> subplot (2, 2, 1); view (-38, 20);
> >   octave:29> [f, v] = isosurface (x, y, z, c, iso);
> >   octave:30> p = patch ("Faces", f, "Vertices", v, "EdgeColor", "none");
> >   error: A(I): Index exceeds matrix dimension.
> >   error: called from:
> >   error:   /Users/Thomas/Development/octave/scripts/plot/__patch__.m at
> >   line 220, column 4
> >   error:   /Users/Thomas/Development/octave/scripts/plot/__patch__.m at
> >   line 138, column 12
> >   error: `tmp' undefined near line 59 column 14
> >   error: called from:
> >   error:   /Users/Thomas/Development/octave/scripts/plot/patch.m at
> > line 59,
> >   column 12
> >
> > Any ideas? Thanks,
> >
> >   Thomas
>
> The demo's work as in demo("patch"), but yes effectively there is an
> issue with the demo in the help text.. I'll look at that but not today
>
> D.

First of all,

thank you for your effort David. I can confirm the errors reported by Thomas.
To be precise they happen with the first two examples in the "subplot" example
group which use the syntax

patch ("Faces", f, "Vertices", v, "EdgeColor", whatever)

The other two examples which use "FaceVertexCData" and facecoloring work well.

If I simply add the "FaceColor" attribute with some value to the failing patch
command, the problem disappears, so the bug seems to be trivial (a misssing
default value for "FaceColor")

e.g.

patch ("Faces", f, "Vertices", v, "FaceColor", "blue","EdgeColor", "none")

works well. I'll look through the code.

- mh


Reply | Threaded
Open this post in threaded view
|

Re: basic implementation for isosurface, isocolors, isonormals

David Bateman-2
Martin Helm wrote:

> First of all,
>
> thank you for your effort David. I can confirm the errors reported by Thomas.
> To be precise they happen with the first two examples in the "subplot" example
> group which use the syntax
>
> patch ("Faces", f, "Vertices", v, "EdgeColor", whatever)
>
> The other two examples which use "FaceVertexCData" and facecoloring work well.
>
> If I simply add the "FaceColor" attribute with some value to the failing patch
> command, the problem disappears, so the bug seems to be trivial (a misssing
> default value for "FaceColor")
>
> e.g.
>
> patch ("Faces", f, "Vertices", v, "FaceColor", "blue","EdgeColor", "none")
>
> works well. I'll look through the code.
>
> - mh
>  
The old 3.0.x behavior was that the default facecolor was [0,1,0]. I
presume that is the compatible behavior and so re-established that as
the default with the attached patch. The demo in the help string then
works correctly for the gnuplot CVS. But there appear to be some issue
with colormap with gnuplot 4.2.4 and the x11 terminal in a multiplot
environment.. I suppose I should try 4.2.5 and see if that works

D.


--
David Bateman                                [hidden email]
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)


# HG changeset patch
# User David Bateman <[hidden email]>
# Date 1239736944 -7200
# Node ID 308311b642b2be2c4e171e15b9e8f35ea4615975
# Parent  efac34f78ea49fe3bc624dfc1dd04e5262e95408
Explicitly set the default facecolor of patches

diff --git a/scripts/ChangeLog b/scripts/ChangeLog
--- a/scripts/ChangeLog
+++ b/scripts/ChangeLog
@@ -1,3 +1,7 @@
+2009-04-11  David Bateman  <[hidden email]>
+
+ * plot/__patch__.m: Set default facecolor to [0,1,0].
+
 2009-04-12  Aravindh Krishnamoorthy <[hidden email]>
        * special-matrix/hadamard.m: Fix a documentation mistake.
 
diff --git a/scripts/plot/__patch__.m b/scripts/plot/__patch__.m
--- a/scripts/plot/__patch__.m
+++ b/scripts/plot/__patch__.m
@@ -177,18 +177,23 @@
   else
     vert = args {idx};
   endif
-  idx = find (cellfun (@(x) strcmpi (x, "facecolor"), args)) + 1;
-  if (isempty(idx) || idx > nargs)
-    fc = "flat";
-  else
-    fc = args {idx};
-  endif
   idx = find (cellfun (@(x) strcmpi (x, "facevertexcdata"), args)) + 1;
   if (isempty(idx) || idx > nargs)
     fvc = [];
   else
     fvc = args {idx};
   endif
+  idx = find (cellfun (@(x) strcmpi (x, "facecolor"), args)) + 1;
+  if (isempty(idx) || idx > nargs)
+    if (!isempty (fvc))
+      fc = "flat";
+    else
+      fc = [0, 1, 0];
+    endif
+    args = {"facecolor", fc, args{:}};
+  else
+    fc = args {idx};
+  endif
 
   nr = size (faces, 2);
   nc = size (faces, 1);
@@ -247,18 +252,23 @@
   else
     z = args {idx};
   endif
-  idx = find (cellfun (@(x) strcmpi (x, "facecolor"), args)) + 1;
-  if (isempty(idx) || idx > nargs)
-    fc = "flat";
-  else
-    fc = args {idx};
-  endif
   idx = find (cellfun (@(x) strcmpi (x, "cdata"), args)) + 1;
   if (isempty(idx) || idx > nargs)
     c = [];
   else
     c = args {idx};
   endif
+  idx = find (cellfun (@(x) strcmpi (x, "facecolor"), args)) + 1;
+  if (isempty(idx) || idx > nargs)
+    if (!isempty (c))
+      fc = "flat";
+    else
+      fc = [0, 1, 0];
+    endif
+    args = {"facecolor", fc, args{:}};
+  else
+    fc = args {idx};
+  endif
 
   [nr, nc] = size (x);
   if (!isempty (z))
Reply | Threaded
Open this post in threaded view
|

Re: basic implementation for isosurface, isocolors, isonormals

Thomas Treichl
David Bateman schrieb:

> Martin Helm wrote:
>> First of all,
>>
>> thank you for your effort David. I can confirm the errors reported by
>> Thomas. To be precise they happen with the first two examples in the
>> "subplot" example group which use the syntax
>> patch ("Faces", f, "Vertices", v, "EdgeColor", whatever)
>>
>> The other two examples which use "FaceVertexCData" and facecoloring
>> work well.
>>
>> If I simply add the "FaceColor" attribute with some value to the
>> failing patch command, the problem disappears, so the bug seems to be
>> trivial (a misssing default value for "FaceColor")
>>
>> e.g.
>>
>> patch ("Faces", f, "Vertices", v, "FaceColor", "blue","EdgeColor",
>> "none")
>>
>> works well. I'll look through the code.
>>
>> - mh
>>  
> The old 3.0.x behavior was that the default facecolor was [0,1,0]. I
> presume that is the compatible behavior and so re-established that as
> the default with the attached patch. The demo in the help string then
> works correctly for the gnuplot CVS. But there appear to be some issue
> with colormap with gnuplot 4.2.4 and the x11 terminal in a multiplot
> environment.. I suppose I should try 4.2.5 and see if that works
>
> D.
Hi David, Martin,

thanks again for this work. I'd say that this is really a very cool new feature
that then comes with 3.2...

Some time ago I also was working on the help text of isonormals.m and
__marching_cubes__.m (Martin already knows because I wrote him an email some
time ago offside the lists to preserve double-work ;) David, can you please
apply the attached changeset?

Thanks and best regards,

   Thomas

# HG changeset patch
# User Thomas Treichl <[hidden email]>
# Date 1239739325 -7200
# Node ID 3b810beddfa64d947c1fe399b17f325d70e0eac1
# Parent  308311b642b2be2c4e171e15b9e8f35ea4615975
Added help texts and tests.

diff --git a/scripts/ChangeLog b/scripts/ChangeLog
--- a/scripts/ChangeLog
+++ b/scripts/ChangeLog
@@ -1,4 +1,9 @@
-2009-04-11  David Bateman  <[hidden email]>
+2009-04-14  Thomas Treichl  <[hidden email]>
+
+ * plot/__marching_cube__.m: Add help text.
+ * plot/isonormals.m: Add help text and tests.
+
+2009-04-14  David Bateman  <[hidden email]>
 
  * plot/__patch__.m: Set default facecolor to [0,1,0].
 
diff --git a/scripts/plot/__marching_cube__.m b/scripts/plot/__marching_cube__.m
--- a/scripts/plot/__marching_cube__.m
+++ b/scripts/plot/__marching_cube__.m
@@ -12,52 +12,63 @@
 ##
 ## You should have received a copy of the GNU General Public License
 ## along with this program; if not, see http://www.gnu.org/licenses/gpl.html.
+
+## -*- texinfo -*-
+## @deftypefn  {Function File} {[@var{t}, @var{p}] =} __marching_cube__ (@var{x}, @var{y}, @var{z}, @var{val}, @var{iso})
+## @deftypefn  {Function File} {[@var{t}, @var{p}, @var{c}] =} __marching_cube__ (@var{x}, @var{y}, @var{z}, @var{val}, @var{iso}, @var{col})
 ##
+## Return the triangulation information @var{t} at points @var{p} for
+## the isosurface values resp. the volume data @var{val} and the iso
+## level @var{iso}.  It is considered that the volume data @var{val} is
+## given at the points @var{x}, @var{y} and @var{z} which are of type
+## three--dimensional numeric arrays.  The orientation of the triangles
+## is choosen such that the normals point from the higher values to the
+## lower values.
+##
+## Optionally the color data @var{col} can be passed to this function
+## whereas computed vertices color data @var{c} is returned as third
+## argument.
+##
+## The marching cube algorithm is well known and described eg. at
+## Wikipedia. The triangulation lookup table and the edge table used
+## here are based on Cory Gene Bloyd's implementation and can be found
+## beyond other surface and geometry stuff at Paul Bourke's website
+## @uref{http://local.wasp.uwa.edu.au/~pbourke/geometry/polygonise}.
+##
+## For example,
+## @example
+## N = 20;
+## lin = linspace(0, 2, N);
+## [x, y, z] = meshgrid (lin, lin, lin);
+##
+## c = (x-.5).^2 + (y-.5).^2 + (z-.5).^2;
+## [t, p] = __marching_cube__ (x, y, z, c, .5);
+##
+## figure ();
+## trimesh (t, p(:,1), p(:,2), p(:,3));
+## @end example
+##
+## Instead of the @command{trimesh} function the @command{patch}
+## function can be used to visualize the geometry. For example,
+##
+## @example
+## figure (); view (-38, 20);
+## pa = patch ("Faces", t, "Vertices", p, "FaceVertexCData", p, \
+##             "FaceColor", "interp", "EdgeColor", "none");
+##
+## ## Revert normals
+## set (pa, "VertexNormals", -get(pa, "VertexNormals"));
+##
+## ## Set lightning (available with the JHandles package)
+## # set (pa, "FaceLighting", "gouraud");
+## # light( "Position", [1 1 5]);
+## @end example
+##
+## @end deftypefn
+
 ## Author: Martin Helm <[hidden email]>
 
-## -*- texinfo -*-
-## @deftypefn {Function File} {[@var{t}, @var{p}, @var{col}] =} __marching_cube__ (@var{x}, @var{y}, @var{z}, @var{c}, @var{iso}, @var{color})
-## Undocumented internal function.
-## @end deftypefn
-
-## usage: [T, P] = marching_cube( XX, YY, ZZ, C, ISO)
-## usage: [T, P, COL] = marching_cube( XX, YY, ZZ, C, ISO, COLOR)
-##
-## Calculates the triangulation T with points P for the isosurface
-## with level ISO. XX, YY, ZZ are meshgrid like values for the
-## cube and C holds the scalar values of the field,
-## COLOR holds additinal scalar values for coloring the surface.
-## The orientation of the triangles is choosen such that the
-## normals point from the lower values to the higher values.
-##
-## edgeTable and triTable are taken from Paul Bourke
-## (http://local.wasp.uwa.edu.au/~pbourke/geometry/polygonise/)
-## Based on tables by Cory Gene Bloyd
-##
-## Example:
-##
-## x = linspace(0, 2, 20);
-## y = linspace(0, 2, 20);
-## z = linspace(0, 2, 20);
-##
-## [ xx, yy, zz ] = meshgrid(x, y, z);
-##
-## c = (xx-.5).^2 + (yy-.5).^2 + (zz-.5).^2;
-## [T, p] = marching_cube(xx, yy, zz, c, 0.5);
-## trimesh(T, p(:, 1), p(:, 2), p(:, 3));
-##
-## with jhandles you can also use the patch function to visualize
-##
-## clf
-## pa = patch('Faces',T,'Vertices',p,'FaceVertexCData',p, ...
-## 'FaceColor','interp', 'EdgeColor', 'none');
-## set(pa, "VertexNormals", -get(pa, "VertexNormals")) # revert normals
-## view(-30, 30)
-## set(pa, "FaceLighting", "gouraud")
-## light( "Position", [1 1 5])
-##
-
-function [T, p, col] = __marching_cube__( xx, yy, zz, c, iso, colors)
+function [T, p, col] = __marching_cube__ (xx, yy, zz, c, iso, colors)
   
   persistent edge_table=[];
   persistent tri_table=[];
@@ -502,4 +513,4 @@
   0, 9, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1;
   0, 3, 8, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1;
   -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 ] + 1;
-endfunction
\ No newline at end of file
+endfunction
diff --git a/scripts/plot/isonormals.m b/scripts/plot/isonormals.m
--- a/scripts/plot/isonormals.m
+++ b/scripts/plot/isonormals.m
@@ -12,17 +12,83 @@
 ##
 ## You should have received a copy of the GNU General Public License
 ## along with this program; if not, see http://www.gnu.org/licenses/gpl.html.
+
+## -*- texinfo -*-
+## @deftypefn  {Function File} {[@var{n}] =} isonormals (@var{val}, @var{v})
+## @deftypefnx {Function File} {[@var{n}] =} isonormals (@var{val}, @var{p})
+## @deftypefnx {Function File} {[@var{n}] =} isonormals (@var{x}, @var{y}, @var{z}, @var{val}, @var{v})
+## @deftypefnx {Function File} {[@var{n}] =} isonormals (@var{x}, @var{y}, @var{z}, @var{val}, @var{p})
+## @deftypefnx {Function File} {[@var{n}] =} isonormals (@dots{}, "negate")
+## @deftypefnx {Function File} isonormals (@dots{}, @var{p})
 ##
+## If called with one output argument and the first input argument
+## @var{val} is a three--dimensional array that contains the data for an
+## isosurface geometry and the second input argument @var{v} keeps the
+## vertices of an isosurface then return the normals @var{n} in form of
+## a matrix with the same size than @var{v} at computed points
+## @command{[x, y, z] = meshgrid (1:l, 1:m, 1:n)}.  The output argument
+## @var{n} can be taken to manually set @var{VertexNormals} of a patch.
+##
+## If called with further input arguments @var{x}, @var{y} and @var{z}
+## which are three--dimensional arrays with the same size than @var{val}
+## then the volume data is taken at those given points.  Instead of the
+## vertices data @var{v} a patch handle @var{p} can be passed to this
+## function.
+##
+## If given the string input argument "negate" as last input argument
+## then compute the reverse vector normals of an isosurface geometry.
+##
+## If no output argument is given then directly redraw the patch that is
+## given by the patch handle @var{p}.
+##
+## For example,
+## @example
+## function [] = isofinish (p)
+##   set (gca, "DataAspectRatioMode","manual","DataAspectRatio",[1 1 1]);
+##   set (p, "VertexNormals", -get(p,"VertexNormals")); ## Revert normals
+##   set (p, "FaceColor", "interp");
+##   ## set (p, "FaceLighting", "phong");
+##   ## light ("Position", [1 1 5]); ## Available with JHandles
+## endfunction
+##
+## N = 15;    ## Increase number of vertices in each direction
+## iso = .4;  ## Change isovalue to .1 to display a sphere
+## lin = linspace (0, 2, N);
+## [x, y, z] = meshgrid (lin, lin, lin);
+## c = abs ((x-.5).^2 + (y-.5).^2 + (z-.5).^2);
+## figure (); ## Open another figure window
+##
+## subplot (2, 2, 1); view (-38, 20);
+## [f, v, cdat] = isosurface (x, y, z, c, iso, y);
+## p = patch ("Faces", f, "Vertices", v, "FaceVertexCData", cdat, \
+##   "FaceColor", "interp", "EdgeColor", "none");
+## isofinish (p); ## Call user function isofinish
+##
+## subplot (2, 2, 2); view (-38, 20);
+## p = patch ("Faces", f, "Vertices", v, "FaceVertexCData", cdat, \
+##   "FaceColor", "interp", "EdgeColor", "none");
+## isonormals (x, y, z, c, p); ## Directly modify patch
+## isofinish (p);
+##
+## subplot (2, 2, 3); view (-38, 20);
+## p = patch ("Faces", f, "Vertices", v, "FaceVertexCData", cdat, \
+##   "FaceColor", "interp", "EdgeColor", "none");
+## n = isonormals (x, y, z, c, v); ## Compute normals of isosurface
+## set (p, "VertexNormals", n);    ## Manually set vertex normals
+## isofinish (p);
+##
+## subplot (2, 2, 4); view (-38, 20);
+## p = patch ("Faces", f, "Vertices", v, "FaceVertexCData", cdat, \
+##   "FaceColor", "interp", "EdgeColor", "none");
+## isonormals (x, y, z, c, v, "negate"); ## Use reverse directly
+## isofinish (p);
+## @end example
+##
+## @seealso {isosurface, isocolors, isocaps, marching_cube}
+##
+## @end deftypefn
+
 ## Author: Martin Helm <[hidden email]>
-
-## usage: NORMALS = isonormals(X,Y,Z,V,VERT)
-## usage: NORMALS = isonormals(V,VERT)
-## usage: NORMALS = isonormals(V,P)
-## usage: NORMALS = isonormals(X,Y,Z,V,P)
-## usage: NORMALS = isonormals(...,'negate')
-## usage: isonormals(V,P)
-## usage: isonormals(X,Y,Z,V,P)
-##
 
 function varargout = isonormals(varargin)
   na = nargin;
@@ -75,4 +141,18 @@
     otherwise
       print_usage ();
   endswitch
-endfunction
\ No newline at end of file
+endfunction
+
+%!test
+%!  [x, y, z] = meshgrid (0:.5:2, 0:.5:2, 0:.5:2);
+%!  c = abs ((x-.5).^2 + (y-.5).^2 + (z-.5).^2);
+%!  [f, v, cdat] = isosurface (x, y, z, c, .4, y);
+%!  n = isonormals (x, y, z, c, v);
+%!  assert (size (v), size (n));
+%!test
+%!  [x, y, z] = meshgrid (0:.5:2, 0:.5:2, 0:.5:2);
+%!  c = abs ((x-.5).^2 + (y-.5).^2 + (z-.5).^2);
+%!  [f, v, cdat] = isosurface (x, y, z, c, .4, y);
+%!  np = isonormals (x, y, z, c, v);
+%!  nn = isonormals (x, y, z, c, v, "negate");
+%!  assert (all (np == -nn));
Reply | Threaded
Open this post in threaded view
|

Re: basic implementation for isosurface, isocolors, isonormals

martin_helm
> David Bateman schrieb:
> > Martin Helm wrote:
> >> First of all,
> >>
> >> thank you for your effort David. I can confirm the errors reported by
> >> Thomas. To be precise they happen with the first two examples in the
> >> "subplot" example group which use the syntax
> >> patch ("Faces", f, "Vertices", v, "EdgeColor", whatever)
> >>
> >> The other two examples which use "FaceVertexCData" and facecoloring
> >> work well.
> >>
> >> If I simply add the "FaceColor" attribute with some value to the
> >> failing patch command, the problem disappears, so the bug seems to be
> >> trivial (a misssing default value for "FaceColor")
> >>
> >> e.g.
> >>
> >> patch ("Faces", f, "Vertices", v, "FaceColor", "blue","EdgeColor",
> >> "none")
> >>
> >> works well. I'll look through the code.
> >>
> >> - mh
> >
> > The old 3.0.x behavior was that the default facecolor was [0,1,0]. I
> > presume that is the compatible behavior and so re-established that as
> > the default with the attached patch. The demo in the help string then
> > works correctly for the gnuplot CVS. But there appear to be some issue
> > with colormap with gnuplot 4.2.4 and the x11 terminal in a multiplot
> > environment.. I suppose I should try 4.2.5 and see if that works
> >
> > D.
>
> Hi David, Martin,
>
> thanks again for this work. I'd say that this is really a very cool new
> feature that then comes with 3.2...
>
> Some time ago I also was working on the help text of isonormals.m and
> __marching_cubes__.m (Martin already knows because I wrote him an email
> some time ago offside the lists to preserve double-work ;) David, can you
> please apply the attached changeset?
>
> Thanks and best regards,
>
>    Thomas

Strange,
I posted Thomas changes two days ago, but looking at this thread I see now
that it never arrived. Seems I need to check my email settings when I write
offline. Thank you Thomas for posting it.
There is one function still missing - "isocaps". I cannot promise at the
moment when I can finish it. It is only 50% ready.

- mh

12