Aha. You were right. The tbres and top bound was set to 1. Odd since I use set the region to match the 3d map.
So I'll try it again and with the command and report back. Michael ____________________ C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Jan 2, 2013, at 10:45 PM, Helena Mitasova <hmit...@ncsu.edu> wrote: > Michael, > > what you describe sounds as if you had only one depth layer so let us check > first that the 3D region is right. > If the 3d region is set to the provided 3d raster given here > http://skagit.meas.ncsu.edu/~helena/grasswork/JR_7408MR_2m_t70.asci > http://skagit.meas.ncsu.edu/~helena/grasswork/JR_2008_ALL.asci (reference 2d > raster) > it should look like this > > GRASS 6.4.3svn (nc_spm_05):~ > g.region -p3 > projection: 99 (Lambert Conformal Conic) > zone: 0 > datum: nad83 > ellipsoid: a=6378137 es=0.006694380022900787 > north: 250690 > south: 249502 > west: 912791 > east: 913931 > top: 64.00000000 > bottom: 0.00000000 > nsres: 2 > nsres3: 2 > ewres: 2 > ewres3: 2 > tbres: 8 > rows: 594 > rows3: 594 > cols: 570 > cols3: 570 > depths: 8 > > can you then try to run the following command (please adjust the names of the > 2d and 3d rasters to your actual names) > > m.nviz.image elevation_map=JR_2008_ALL@Baseline_JR -a mode=fine > resolution_fine=6 color_map=JR_2008_ALL@Baseline_JR \ > volume=JR_7408MR_2m_t70@Baseline_JR volume_shading=gouraud > volume_resolution=1 volume_position=0,0,20 isosurf_level=1:18.0 > isosurf_color_map=JR_7408MR_2m_t70@Baseline_JR isosurf_transparency_value=0 > slice=1:x,1:z > slice_position=0.000000,1.000000,0.520000,1.000000,0.000000,1.000000,0.250000,0.720000,0.080000,1.000000,0.000000,1.000000 > slice_transparency=0,0 position=0.84,0.16 height=356 perspective=20 twist=0 > zexag=5.000000 focus=569,593,28 \ > light_position=0.68,0.68,0.80 light_brightness=80 light_ambient=20 > light_color=255:255:255 \ > output=jrvoltest format=tif size=798,545 > > it should generate an image with isosurfaces and a tilted crossection - it is > not quite what I have on the screen, because > it apparently uses some default values instead of actual values (e.g. for > toggle normal direction and crossection) but it should have some > isosurfaces. Let us know whether the command line works and we can go from > there. > > Helena > > On Jan 3, 2013, at 12:08 AM, Michael Barton wrote: > >> When I put in values between 15 and 20 I can see the horizontal outline of a >> rectangle but not the 3D shape of a box. No isosurfaces display. No crash >> either. >> >> I un-commented line 684 and commented line 1009 in gvl_calc_c to see what >> happens to slices >> >> /* gvl_align_data(pos, slice->data); */ >> >> A horizontal slice displays and I can manipulate it in the X and Y >> direction. But I cannot manipulate it in the Z direction. Also, a Z >> dimension slice shows up only as a line. Also, isosurfaces do not display. >> But there is no crash for either isosurfaces or slices when I comment out >> this line. On the face of it, a memory issue related to display in the Z >> dimension is causing a crash. Commenting out calls to gvl_align_data in >> gvl_calc_c stops the crash and stops display in the Z dimension. There is >> also something called gvl_calc2_c in this folder. Its code is very similar >> to gvl_calc_c >> >> I'm guessing that Martin and Helena know the most about the relevant C code >> for lib/ogsf/*. Glynn may have some insight into this too. Anyone else is >> welcome to chime in. >> >> FWIW, the last time gvl_calc_c was touched was by Glynn 4 years ago (glynn: >> Fix char/char* mismatch (merge from trunk, r32757)). >> >> Volume display worked as recently as fall 2011 AFAIK. >> >> Michael >> ____________________ >> C. Michael Barton >> Director, Center for Social Dynamics & Complexity >> Professor of Anthropology, School of Human Evolution & Social Change >> Arizona State University >> >> voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) >> fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) >> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu >> >> >> >> >> On Jan 2, 2013, at 10:21 AM, Helena Mitasova <hmit...@ncsu.edu> wrote: >> >>> >>> >>> On Jan 2, 2013, at 1:34 AM, Michael Barton wrote: >>> >>>> Testing with GRASS 6.4.3RC2 >>>> >>>> Rem-ing out line 684 in gvl_calc_c >>>> >>>> /* gvl_align_data(dbuff[i].ndx_new, dbuff[i].new); */ >>>> >>>> prevents crashing. But I don't see an isosurface. >>>> >>>> >>>> >>>> Helena, >>>> >>>> I'm using your test data (jr_7408MR_2m_t70) >>>> >>>> What is a good value to set for an isosurface to see anything? >>> >>> anything between 15 to 20 should work. >>> You can move the volume a little bit above the surface to see the entire >>> isosurface >>> Here is an example of settings that I have used (the name of the volume >>> raster is slightly different >>> but it is the same data). >>> >>>> m.nviz.image elevation_map=JR_2008_ALL -a mode=fine resolution_fine=1 >>>> color=243:243:243 volume=JR_7408MR_2m volume_shading=gouraud >>>> volume_resolution=1 volume_position=0,0,20 isosurf_level=1:17.0 >>>> isosurf_color_map=JR_7408MR_2m isosurf_transp_value=0 position=0.11,0.07 >>>> height=243 perspective=13 twist=0 zexag=6.000000 focus=569,593,17 >>>> light_position=0.26,-0.30,0.61 light_brightness=94 light_ambient=55 >>>> light_color=255:255:255 output=nviz_output format=ppm size=798,545 >>> >>> This volume includes no-data because the original rasters were masked, I >>> think it would be useful to start with a volume without no-data - >>> just use r3.null to replace no-data with 0. >>> >>> Let me know if it would be useful for me to run same thing in MacOSX 10.6 >>> (I still don't have 10.8 machine quite ready), >>> (see the slides 12 and 13 here for the isosurfaces at different levels, I >>> have the isosurfaces colored by year - I don't think I gave you >>> that raster, so your isosurfaces should be just a single color). >>> http://skagit.meas.ncsu.edu/~helena/publwork/AGU2012lidar6.pptx >>> >>> Helena >>> >>>> Slices still crash because they still call gvl_align_data. As before, >>>> though initially displaying a slice works fine. It only crashes when I try >>>> to change something about the slice and it wants to redraw. >>>> >>>> Michael >>>> ____________________ >>>> C. Michael Barton >>>> Director, Center for Social Dynamics & Complexity >>>> Professor of Anthropology, School of Human Evolution & Social Change >>>> Arizona State University >>>> >>>> voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) >>>> fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) >>>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Jan 1, 2013, at 1:24 PM, Anna Kratochvílová <kratocha...@gmail.com> >>>> wrote: >>>> >>>>> Hi Michael, >>>>> >>>>> On Tue, Jan 1, 2013 at 8:48 PM, Michael Barton <michael.bar...@asu.edu> >>>>> wrote: >>>>>> Hi Anna, >>>>>> >>>>>> On the slim chance that you are online today, can you tell me where >>>>>> gvl_align_data in gvl_calc.c reside in either the source code or >>>>>> compiled code? I have a bit of down time and thought I'd see what I >>>>>> could find out about the volume display breaking. I don't know C but can >>>>>> selectively rem out some things and see what happens. >>>>> >>>>> It should be here >>>>> http://trac.osgeo.org/grass/browser/grass/trunk/lib/ogsf/gvl_calc.c#L685 >>>>> >>>>> Also, you could try debugging with QtCreator [1] (as an user-friendly >>>>> interface to the debugger), it is quite easy, here [2] is some help >>>>> for setting up the project. I don't know what method you would like to >>>>> use but this is the easiest I know. I suppose it should work on Mac, >>>>> too. >>>>> >>>>> Regards, >>>>> Anna >>>>> >>>>> [1] http://qt-project.org/downloads >>>>> [2] >>>>> http://grasswiki.osgeo.org/wiki/Using_QtCreator_for_GRASS_C_development#Debugging >>>>> >>>>> >>>>>> >>>>>> >>>>>> Thanks >>>>>> Michael >>>>>> ____________________ >>>>>> C. Michael Barton >>>>>> Director, Center for Social Dynamics & Complexity >>>>>> Professor of Anthropology, School of Human Evolution & Social Change >>>>>> Arizona State University >>>>>> >>>>>> voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) >>>>>> fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) >>>>>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Dec 6, 2012, at 12:07 AM, Anna Kratochvílová <kratocha...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Hi Michael, >>>>>>> >>>>>>> On Wed, Dec 5, 2012 at 11:02 PM, Michael Barton >>>>>>> <michael.bar...@asu.edu> wrote: >>>>>>>> Any suggestions yet on where the crash I documented in >>>>>>>> http://trac.osgeo.org/grass/ticket/1736 actually happens in the code >>>>>>>> so that >>>>>>>> I can take a look at it and see if there is something fixable for the >>>>>>>> Mac? I >>>>>>>> posted what I hope is the relevant debug output to help identify this. >>>>>>>> >>>>>>>> While we may need to think about wxPython 2.9, it seems best to first >>>>>>>> look >>>>>>>> at what line is actually causing the crash and see if there is a fix or >>>>>>>> workaround. >>>>>>> >>>>>>> The crash occurs probably in gvl_align_data in gvl_calc.c. The error >>>>>>> message 'pointer being realloc'd was not allocated' is quite clear, >>>>>>> however it's not clear why it happens on Mac only. Maybe someone with >>>>>>> better knowledge of C could understand it more. >>>>>>> >>>>>>> Anna >>>>>>> >>>>>>>> >>>>>>>> Michael >>>>>>>> ____________________ >>>>>>>> C. Michael Barton >>>>>>>> Director, Center for Social Dynamics & Complexity >>>>>>>> Professor of Anthropology, School of Human Evolution & Social Change >>>>>>>> Arizona State University >>>>>>>> >>>>>>>> voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) >>>>>>>> fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) >>>>>>>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>> >>> >> > _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev