On Jan 11, 2013, at 2:48 PM, Anna Kratochvílová wrote: > Hi Michael, > > On Mon, Jan 7, 2013 at 7:57 AM, Michael Barton <michael.bar...@asu.edu> wrote: >> So I found a change that would make volumes visible again a week ago. Anyone >> have any thoughts about this? Do we need the function/procedure that sets >> the memory pointer for volume displays? Or can we simply get rid of it? Is >> it needed for Linux? Windows? Any thoughts about what happens without it? > > I can confirm that removing those two lines does no harm for me > (Linux). However it's clear that we cannot just leave them out without > understanding why they are there. Can anyone (for example Glynn) think > of a reason why this code is crashing on Mac and not on Linux (no idea > about Windows)?
I just tested it on Windows 7 with WinGRASS6.4.3RC2 and I am happy to report that it works OK - both isosurfaces and crossections. However, in the same WinGRASS6.4.3.RC2 there is a problem with the path to cellheader in G3d_read_window, so r3.info and g.region rast3d=myvoxel gives an error that the region is invalid. Also, I finally got a laptop with MacOSX10.8 and I can confirm that in GRASS6.4.3RC2 binary posted Michael isusrfaces crash wxGUI. I will try to compile myself but I expect the result to be the same given that it crashed for William as well. Helena > And why removing of realloc helps? > > Regards, > Anna > >> >> Cheers >> 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 11:22 PM, Michael Barton <michael.bar...@asu.edu> wrote: >> >>> GREAT NEWS! >>> >>> Commenting out both gvl_align_data lines (#684 and #1009) in gvl_calc_c >>> makes this work. Both slices and isosurfaces display and do not crash. I >>> don't know if there would be a problem with larger files or not. But this >>> is finally functional again. >>> >>> BUT the command you sent does NOT work. It gives a segmentation fault error: >>> >>> m.nviz.image elevation_map=JR_2008_ALL_dem@test3d -a mode=fine >>> resolution_fine=6 color_map=JR_2008_ALL_dem@test3d >>> volume=jr_7408MR_2m_t70@test3d volume_shading=gouraud volume_resolution=1 >>> volume_position=0,0,20 isosurf_level=1:18.0 >>> isosurf_color_map=jr_7408MR_2m_t70@test3d 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 >>> Loading raster map <JR_2008_ALL_dem@test3d>... >>> 100% >>> Loading raster map <JR_2008_ALL_dem@test3d>... >>> 100% >>> Translating colors from raster map <JR_2008_ALL_dem@test3d>... >>> 100% >>> Loading 3d raster map <jr_7408MR_2m_t70@test3d>... >>> Segmentation fault: 11 >>> >>> >>> Also, somewhere there is a bug somewhere that is sending progress bar text >>> to the screen for any nviz activity (GRASS_INFO_PERCENT: 0...) >>> >>> So now we have some kind of workaround. I don't know if there are any other >>> down sides to bypassing this memory reallocation, but this is a good start >>> on fixing this finally. Thanks Anna and Helena. >>> >>> 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