Re: [GRASS-dev] release planning and no volume display on Mac - Any info on where crash happens?
Markus and others, I just tested this with GRASS trunk r54874 and it is still broken. Removing all reference to lines gvl_align_data (and the function as well) works. AFAICT, this only is called for viewing volumes. Does removing this function break volume viewing for any other platform? 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 Feb 3, 2013, at 5:16 AM, Markus Metz wrote: > I have not commented out both gvl_align_data lines (#684 and #1009) in > gvl_calc.c, but fixed variable initialization in trunk r54866. Please > test. > > Markus M > > On Fri, Jan 11, 2013 at 10:33 PM, Michael Barton > wrote: >> Perhaps Windows and Linux--and earlier versions of OS X--ignore the code. >> >> The header for gvl_calc.c says that the author is Tomas Paudits (February >> 2004). Does anyone know if he is still around to ask? >> >> Michael >> __ >> C. Michael Barton >> Director, Center for Social Dynamics & Complexity >> Professor of Anthropology, School of Human Evolution & Social Change >> Arizona State University >> Tempe, AZ 85287-2402 >> USA >> >> voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) >> fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) >> www:http://csdc.asu.edu, http://shesc.asu.edu >>http://www.public.asu.edu/~cmbarton >> >> On Jan 11, 2013, at 1:18 PM, Helena Mitasova >> wrote: >> >>> >>> 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 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 > 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.00,1.00,0.52,1.00,0.00,1.00,0.25,0.72,0.08,1.00,0.00,1.00 >> slice_transparency=0,0 position=0.84,0.16 height=356 perspective=20 >> twist=0 zexag=5.00 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
Re: [GRASS-dev] release planning and no volume display on Mac - Any info on where crash happens?
I will try to test today if I can. 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 Feb 3, 2013, at 5:16 AM, Markus Metz wrote: > I have not commented out both gvl_align_data lines (#684 and #1009) in > gvl_calc.c, but fixed variable initialization in trunk r54866. Please > test. > > Markus M > > On Fri, Jan 11, 2013 at 10:33 PM, Michael Barton > wrote: >> Perhaps Windows and Linux--and earlier versions of OS X--ignore the code. >> >> The header for gvl_calc.c says that the author is Tomas Paudits (February >> 2004). Does anyone know if he is still around to ask? >> >> Michael >> __ >> C. Michael Barton >> Director, Center for Social Dynamics & Complexity >> Professor of Anthropology, School of Human Evolution & Social Change >> Arizona State University >> Tempe, AZ 85287-2402 >> USA >> >> voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) >> fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) >> www:http://csdc.asu.edu, http://shesc.asu.edu >>http://www.public.asu.edu/~cmbarton >> >> On Jan 11, 2013, at 1:18 PM, Helena Mitasova >> wrote: >> >>> >>> 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 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 > 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.00,1.00,0.52,1.00,0.00,1.00,0.25,0.72,0.08,1.00,0.00,1.00 >> slice_transparency=0,0 position=0.84,0.16 height=356 perspective=20 >> twist=0 zexag=5.00 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 ... >> 100% >> Loading raster map ... >> 100% >> Translating colors from raster map ... >> 100% >> Loading 3d raster map ... >> Segmentation fault: 11 >> >> >>
Re: [GRASS-dev] release planning and no volume display on Mac - Any info on where crash happens?
I have not commented out both gvl_align_data lines (#684 and #1009) in gvl_calc.c, but fixed variable initialization in trunk r54866. Please test. Markus M On Fri, Jan 11, 2013 at 10:33 PM, Michael Barton wrote: > Perhaps Windows and Linux--and earlier versions of OS X--ignore the code. > > The header for gvl_calc.c says that the author is Tomas Paudits (February > 2004). Does anyone know if he is still around to ask? > > Michael > __ > C. Michael Barton > Director, Center for Social Dynamics & Complexity > Professor of Anthropology, School of Human Evolution & Social Change > Arizona State University > Tempe, AZ 85287-2402 > USA > > voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) > fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) > www:http://csdc.asu.edu, http://shesc.asu.edu > http://www.public.asu.edu/~cmbarton > > On Jan 11, 2013, at 1:18 PM, Helena Mitasova > wrote: > >> >> 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 >>> 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 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.00,1.00,0.52,1.00,0.00,1.00,0.25,0.72,0.08,1.00,0.00,1.00 > slice_transparency=0,0 position=0.84,0.16 height=356 perspective=20 > twist=0 zexag=5.00 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 ... > 100% > Loading raster map ... > 100% > Translating colors from raster map ... > 100% > Loading 3d raster map ... > 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 (
Re: [GRASS-dev] release planning and no volume display on Mac - Any info on where crash happens?
Perhaps Windows and Linux--and earlier versions of OS X--ignore the code. The header for gvl_calc.c says that the author is Tomas Paudits (February 2004). Does anyone know if he is still around to ask? Michael __ C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www:http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Jan 11, 2013, at 1:18 PM, Helena Mitasova wrote: > > 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 >> 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 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.00,1.00,0.52,1.00,0.00,1.00,0.25,0.72,0.08,1.00,0.00,1.00 slice_transparency=0,0 position=0.84,0.16 height=356 perspective=20 twist=0 zexag=5.00 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 ... 100% Loading raster map ... 100% Translating colors from raster map ... 100% Loading 3d raster map ... 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 wrote: > Michael, > > what you describe sounds as if you had only one depth lay
Re: [GRASS-dev] release planning and no volume display on Mac - Any info on where crash happens?
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 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 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.00,1.00,0.52,1.00,0.00,1.00,0.25,0.72,0.08,1.00,0.00,1.00 >>> slice_transparency=0,0 position=0.84,0.16 height=356 perspective=20 >>> twist=0 zexag=5.00 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 ... >>> 100% >>> Loading raster map ... >>> 100% >>> Translating colors from raster map ... >>> 100% >>> Loading 3d raster map ... >>> 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 >>> 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. bottom: 0. nsres: 2 nsres3: 2 ewres: 2 ewres3: 2 tbres: 8 rows: 594 rows3: 594 cols: 570 cols3: 570 >>
Re: [GRASS-dev] release planning and no volume display on Mac - Any info on where crash happens?
Hi Michael, On Mon, Jan 7, 2013 at 7:57 AM, Michael Barton 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)? 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 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.00,1.00,0.52,1.00,0.00,1.00,0.25,0.72,0.08,1.00,0.00,1.00 >> slice_transparency=0,0 position=0.84,0.16 height=356 perspective=20 twist=0 >> zexag=5.00 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 ... >> 100% >> Loading raster map ... >> 100% >> Translating colors from raster map ... >> 100% >> Loading 3d raster map ... >> 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 >> 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. >>> bottom: 0. >>> 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.00,1.00,0.52,1.00,0.00,1.00,0.25,0.72,0.08,1.00,0.00,1.00 >>> slice_transparency=0,0 position=0.84,0.16 height=356 perspective=20 >>> twist=0 zexag=5.00 focus=569,593,28 \ >>> light_position=0.68,0.68,0.80 light_brightne
Re: [GRASS-dev] release planning and no volume display on Mac - Any info on where crash happens?
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? 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 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.00,1.00,0.52,1.00,0.00,1.00,0.25,0.72,0.08,1.00,0.00,1.00 > slice_transparency=0,0 position=0.84,0.16 height=356 perspective=20 twist=0 > zexag=5.00 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 ... > 100% > Loading raster map ... > 100% > Translating colors from raster map ... > 100% > Loading 3d raster map ... > 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 > 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. >> bottom: 0. >> 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.00,1.00,0.52,1.00,0.00,1.00,0.25,0.72,0.08,1.00,0.00,1.00 >> slice_transparency=0,0 position=0.84,0.16 height=356 perspective=20 twist=0 >> zexag=5.00 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 wr
Re: [GRASS-dev] release planning and no volume display on Mac - Any info on where crash happens?
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.00,1.00,0.52,1.00,0.00,1.00,0.25,0.72,0.08,1.00,0.00,1.00 slice_transparency=0,0 position=0.84,0.16 height=356 perspective=20 twist=0 zexag=5.00 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 ... 100% Loading raster map ... 100% Translating colors from raster map ... 100% Loading 3d raster map ... 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 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. > bottom: 0. > 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.00,1.00,0.52,1.00,0.00,1.00,0.25,0.72,0.08,1.00,0.00,1.00 > slice_transparency=0,0 position=0.84,0.16 height=356 perspective=20 twist=0 > zexag=5.00 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 t
Re: [GRASS-dev] release planning and no volume display on Mac - Any info on where crash happens?
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 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. > bottom: 0. > 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.00,1.00,0.52,1.00,0.00,1.00,0.25,0.72,0.08,1.00,0.00,1.00 > slice_transparency=0,0 position=0.84,0.16 height=356 perspective=20 twist=0 > zexag=5.00 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 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 any
Re: [GRASS-dev] release planning and no volume display on Mac - Any info on where crash happens?
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. bottom: 0. 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.00,1.00,0.52,1.00,0.00,1.00,0.25,0.72,0.08,1.00,0.00,1.00 slice_transparency=0,0 position=0.84,0.16 height=356 perspective=20 twist=0 zexag=5.00 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 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.00 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,
Re: [GRASS-dev] release planning and no volume display on Mac - Any info on where crash happens?
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 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.00 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á >> wrote: >> >>> Hi Michael, >>> >>> On Tue, Jan 1, 2013 at 8:48 PM, Michael Barton >>> 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 e
Re: [GRASS-dev] release planning and no volume display on Mac - Any info on where crash happens?
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? 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á wrote: > Hi Michael, > > On Tue, Jan 1, 2013 at 8:48 PM, Michael Barton 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á >> wrote: >> >>> Hi Michael, >>> >>> On Wed, Dec 5, 2012 at 11:02 PM, Michael Barton >>> 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
