Re: basic implementation for isosurface, isocolors, isonormals

[David Bateman]

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                                address@hidden
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)