3D surface modeling of a giant redwood trunk

[edfrank]

This volume calculation at 3163.027 ft3 is probably closer to correct than 1.5 mm3.

Ed

[fooman]

Hi Ed,

The 1.5 mm3 for the Stratosphere Giant  was simply a case of GIGO.  The data from the Redwood Creek Giant had been converted into feet by Michael for his spreadsheet.  The 1.5 (unit)3 result is correct, for whatever the raw units in the scanner data is (also note, it was a different tree!).  Without knowing the details of the scanner, I suspect it is some sort of self-scaling dimensionless value (depends on the size of the item being scanned).  Some scanners are able to self-calibrate to obtain actual units in the dimensions.   You'll notice in the image of the RCG mesh, it still has the scale bar in mm.  It doesn't really  matter, because the data was imported in as 1 ft = 1 mm.

Don,

Quite simply, 3d scanning is the same as putting a tape around a tree 10,000 times and recording the position evey inch or so.  To get other information would require different techniques.  At my old university there was a research group my supervisor was involved in, looking at multi-scale modelling wood in an engineering sense, starting from the physical and mechanical properties of the various structures and sizes (one of the students has continued on in the field - he has a presentation here: http://www.ifb.ethz.ch/comphys/woodReliability_2009/talk8) .  I wasn't involved directly, but did help some of my fellow students.  I have fond memories of undertaking some trial tests on measuring the elastic properpties of individual cells from Pinus Radiata samples - half the size of a matchstick.  Deformation was measured super accurately via a laser reflected off the cell and onto a wall.  

Anyway, I digress.  To get an idea of the properties, other than outside bark volume, would require extrapolation based on destructive testing such as coring or population sampling to get the required properties, or other techniques such as low frequency ultrasonics or acoustic emission for density changes (bark/early wood/late wood), conductivities for water content etc.  There are probably much more qualified people on this forum than myself to ask these questions.

Cheers,
Matt

Addendum:

I looked up some more of Jonathon's work and came across this:  http://www.locuscor.net/silvilaser2011/papers/002_Adams.pdf.  Some interesting work on ground-based 3d scanning of plantation trees to assess wood production.

[edfrank]

Matt,

This is amazing stuff.  The amount of detail is incredible on the mesh renderings..

Ed

[Don]

Matt-
Very interesting, your included presentation and paper. Good work from Down Under!
Regarding the paper, my curiosity is piqued...the correlation between wood quality with sweep and dbh was mentioned in the context of a tree growing into a canopy gap. Sweep in excess, diminishes wood quality from the perspective of the mill...presumably an inverse relationship?  That is to say, the less sweep the better the correlation with wood quality?
Kind of works against:
"Sweep exhibits moderate positive correlations with crown area, volume and density.  This would
imply that trees with more foliage are more prone to sweep.  This agrees with the findings of
Suarez et al. (2010) who found that stem straightness was inversely proportional to stand spacing.  
It is well known that canopy size and volume are proportional to stand spacing."

I follow the thought that increased canopy opening (increased stand spacing) allows more photosynthesis opportunity/photosynthate production as the tree fills the space.  But there are two (hmmm, at least...: > ) dynamics here, and the tree growing out (increasing diameter), and the tree growing up (increasing height), both adding volume.  These dynamics typically occur in the order listed, in a canopy opening scenario.  But I'm not sure I follow the 'implication' that "trees with more foliage are more prone to sweep'...that logic if extended would also imply that the greater the sweep, the great the wood quality. Neither timber mills nor the paper industry would want compression wood/tension wood that accompanies excess sweep.

Well, perhaps I've belabored the point, and unfairly extended implications...a thought provoking paper nonetheless!
-Don

[M.W.Taylor]

Matt,

I greatly appreciate you checking my numbers from the Free Form volume solver for RCG. I just noticed a problem with my code where the extrapolation between missing points is very sloppy. I'll re-code the RCG volume solver with the better extrapolation algorithm and then re-post. I know where I went wrong. Let's see how the #'s compare after the change.  Did your RCG shape table originally have only 65k points ? That surface mesh looks fantastic with excellent curvature effects.  The original scan I made of RCG has 197k points but I could only fit 65k on the spreadsheet.

Did you cut and paste the XYZ data from the RCG spreadsheet into a text file for Rapid Form ?  

I do not recall attaching the RCG ply file due to size restrictions. In the new RCG code I will put an outer surface area calculation solution as well.  

How long did the Mesh layer take to create ?  Did Rapid Form decimate the data after Meshing ? Is your Mesh created from the orignal 65k XYZ points from my RCG volume spreadsheet ? Does Rapid Form do a surface volume calculation ?
I would assume yes.

I need to speed up the VBA code in my spreadsheet if it is to solve for the volume of an entire tree. The volume solver as I coded it is trying to do too much at once including extrapolation of surface boundaries, noise filtering and volume calculations. One idea I had for speeding up my slow VBA code was to decimate the data prior to volume solving using another VBA macro to calculate surface boundary density characteristics per cross-section. The idea is to develop an average density for surface points per cross-section.   With that parameter I can then determine (with resonable confidence) all the surface boundaries per each cross-sectional analysis.  And then automatically filter out parasite points and isolate discrete structures for volume solving like the trunk form. From there I should be able to code multiple volume solutions from each cross-section.. i.e. find total volume for trees that have negative taper, multiple trunk iterations and just about any type of complex forest structure with overhanging projections and cavities. Burned out snags ? I'll probably need to use C++ with compiler to make a version fast enough to be of practical use for solving the volume of a big redwood.

I should have a new and improved RCG volume solver for you to test soon if you feel like it. I hope to get within 1% of RapidForm. I am not satisfied with 3%. It should be better. We'll see how the coding goes. I am fairly certain the error is on my end. Thanks again for your help,

Michael

Hi Michael,

Another quick play, to get volumetric data.  Method as below:

Slice of redwood creek giant, 0<z<20ft.  

Imported spreadsheet data containing vertex data with 0<z<20ft as .ply into Radidform.  Automatically mesh.  Filtering of extranous data points, 80% sampling ratio.  Automatically filling holes resulted in smoothed, interpolated surfaces at z<0ft and z>20ft.  Trimmed resultant mesh back to 0<z<20ft.  Global remeshing resulted in slight smoothing of edges.  Volume calculated at ~3076 ft3, with face normals pointing inwards (calculation instantaneous).  Corrected normals to obtain "correct" model display, but unable to obtain a volume calculation.  Mesh shown below:

RCG0-20ft-3076cubicft.jpg

Ran free form volume solver-RGC.xls with the following settings:

Range Filters        # of Points =        61627        127         = # of        Slice Points
Xmin        -10.000        Xmax        11.000                
Ymin        -10.000        Ymax        11.000                
Zmin        -1.000        Zmax        30.000                
Pole XYZ        0.000        0.00        0.000                
Zcookie        0.000        Thickness        0.200                
Ht Start Pt        0.000        Ht End Pt        20.000        Int        20.000
Slice Thickness        1.000        Ray Incº        1.00                
                                       
Took about 10 minutes to get the result:

Total Volume        3163.027

The mesh volume is ~ 97% of the numerical intergration volume.  The difference is likely to be in the filtering/smoothing/filling undertaken on the mesh plus the residuals inherent in the numerical integration method (e.g. as a function of ray angle/slice sizes).

This seems to be a reasonably good result.

Cheers,
Matt

[fooman]

Matt,

Did your RCG shape table originally have only 65k points ? That surface mesh looks fantastic with excellent curvature effects.  The original scan I made of RCG has 197k points but I could only fit 65k on the spreadsheet.

The number of vertices in the 20 ft slice I took from your spreadsheet was ~41k.  Not so sure on the resolution of the final mesh.  EDIT - just checked it - 17k vertices, 34k faces

Did you cut and paste the XYZ data from the RCG spreadsheet into a text file for Rapid Form ?  

I had to add in 3 extra columns of data for the RGB values of the points (used 1,1,1).  A bit of manipulation is requred to remove tab-spaces if copying direct from Excel, but I just exported it as a space-deliminated file (.prn) and copied the data from that.

How long did the Mesh layer take to create ?

Maybe 10 minutes of playing around with various options.  Plus another 2 or three minutes to copy the data over.  If I knew what I was doing, maybe a couple of minutes.  The software is pretty good!

Did Rapid Form decimate the data after Meshing ?

 

The automated meshing process does reduce the number of vertices, to a user-specified amount.  I selected to retain ~80% of the raw information.  Then did a remesh, which applied a gobal resizing of the mesh, but still capturing the volumetric information.

Is your Mesh created from the orignal 65k XYZ points from my RCG volume spreadsheet ?

 

As above, it was created from a selection of ~41k of the XYZ points of the RCG spreadsheet.

Does Rapid Form do a surface volume calculation ?  I would assume yes.

It does - the surface area was ~1600 ft2, but that would have included the top and bottom "cuts" on the slice.  EDIT: Was actually 1268 ft2, with the top face being ~122 ft2, and the bottom face ~322 ft2.

I hope to get within 1% of RapidForm. I am not satisfied with 3%. It should be better. We'll see how the coding goes. I am fairly certain the error is on my end. Thanks again for your help,

Michael

Just be aware that the mesh I created still has the possibility of user bias in some of the parameters I chose, and the tendency to "round off" sharp edges.  E.g. scan and mesh a cube , and there will be rounding errors on the edges of the cube.

The software can actually generate a pointcloud from a mesh - so I can generate one for you to have a play with for your volume solver.  Or maybe some generic volumes for your info.  EDIT:  See attached for the point cloud extracted from the remeshed data.  This was just a straight export into a .ply format, and manually stripping out the polyface data points, leaving in the vertices.  You may wish to delete the data at z=0 and z=20 as these will be the cut surfaces, and may play havoc with your volume solver.

Cheers,
Matt

[fooman]

Matt-
Very interesting, your included presentation and paper. Good work from Down Under!
Regarding the paper, my curiosity is piqued...the correlation between wood quality with sweep and dbh was mentioned in the context of a tree growing into a canopy gap. Sweep in excess, diminishes wood quality from the perspective of the mill...presumably an inverse relationship?  That is to say, the less sweep the better the correlation with wood quality?
Kind of works against:
"Sweep exhibits moderate positive correlations with crown area, volume and density.  This would
imply that trees with more foliage are more prone to sweep.  This agrees with the findings of
Suarez et al. (2010) who found that stem straightness was inversely proportional to stand spacing.  
It is well known that canopy size and volume are proportional to stand spacing."

I follow the thought that increased canopy opening (increased stand spacing) allows more photosynthesis opportunity/photosynthate production as the tree fills the space.  But there are two (hmmm, at least...: > ) dynamics here, and the tree growing out (increasing diameter), and the tree growing up (increasing height), both adding volume.  These dynamics typically occur in the order listed, in a canopy opening scenario.  But I'm not sure I follow the 'implication' that "trees with more foliage are more prone to sweep'...that logic if extended would also imply that the greater the sweep, the great the wood quality. Neither timber mills nor the paper industry would want compression wood/tension wood that accompanies excess sweep.

Well, perhaps I've belabored the point, and unfairly extended implications...a thought provoking paper nonetheless!
-Don

Hi Don,

I can't really add much to what you have said other than to note a few points:

1.  I got the impression that there was less sweep for decreasing spacing, i.e. there was less opportunity to grow anywhere but straight up, the closer the spacing.  The more spacing you get, the greater the potential wood volume, but also the potential the the tree will move from a vertical axis to maximise photosynthesis (i.e. produce canopy skewed away from the vertical axis of the base of the trunk).  But my expertise is in material sciences rather than forestry.

2. The paper noted that due to the sample size (5 trees?), it was proof of concept, rather than of a greater finding.

3.  A lot of NZ's wood production goes into pulp and paper production, either domestically, or abroad (logs are shipped to Asia to processes there).  Sweep may not be such as issue for said usage of the material.

Cheers,
Matt

[Don]

Matt
Good points all!
Re #1,as you go from 9' x 9' spacing (typical USFS grid for western conifers) to say 100' x 100' (open field), all other things being equal, a tree will try to grow up and out until it fills the space (ie, encounters shadows or physical contact).
If it fills the space first, it then focuses on growing up. This often is a tall tree scenario..
If it's in an open field, it continues trying to do both. This is often a big circumference scenario.
There are always exceptions...
-Don

[M.W.Taylor]

Matt,

I notice your Redwood Creek Giant mesh is a bit concave at the top ?

My volume solution for RCG is now about 1% from your RapidForm XOR now using a "best fit" strategy for the missing points (that always arrive in cloud maps).  I used a conservative linear interpolation between closest surface edge points. In my experience I have found that spline interpolation over-estimates tree surfaces so that was not used here.  

Here is my output for the latest code revision using your input numbers. I get 3108 cubic feet and 1212 square feet respectively. Darn close. I am satisfied with these results.

Also, you are measuring the volume and area of the mesh from RapidFormXOR, correct ?  In that case, your surface area should be a little greater because your mesh has 1/2 the points of the cloud set I am processing which has triangular facets too but more of them. I'll run the RapidForm mesh cloud through my custom code and see what happens.

here are the latest results:

Range Filters        # of Points =        6318        347         = # of Slice Points        
Xmin        -9.000        Xmax        9.000                
Ymin        -10.000        Ymax        11.000        Contol-V        Control-C
Zmin        -1.000        Zmax        30.000        To Calculate        To Extract
Pole XYZ        0.000        0.00        0.000        Volume        Cookie
Zcookie        0.000        Thickness        1.000                
Ht Start Pt        0.000        Ht End Pt        20.000        Current Height Int.        20.000
Slice Thickness        1.000        Ray Incº        1.00           Typical Ranges =        1º - 2º - 3º
Forest Form ID:        Redwood Creek Giant                                  
Polygon Area Upper        125.429        Slice Volume        126.543        Total Weight        82682.435
Polygon Area Lower        127.661        Total Volume        3108.362        Surface Area        1212.572


Took an hour + to solve.  I added weight too

The attached is the ForestForm1.6 volume and area calculator for RCG with 30k points in the default table. I truncated the last 35k points of this table to speed the program up a little, but it is still SLOW. The RCG cloud set also has a few parasitic outlier points as well which can add a litle error to the volume solution if not removed. You may want to decimate it or transform into a Mesh again before playing with it.  I just want to make sure we are comparing apple to apples here. I think the attached volume solver has a slightly different embedded RCG cloud set than the one you worked with last time.

At some point I should re-write this code in Visual C+ and compile into machine language.

How much does RapidForm XOR cost ?  I get the feeling it's expensive.

Lastly, this "ForestForm1.6" Solver will work all the way up the trunk to nearly the top, unless the tree has a severe lean or multiple iterations.  In that case, boundary issues will occur. To overcome this in the spreadsheet you would need to solve volumes in parts and re-center the origin of the cloud set higher up before it touches a surface edge.

There is also another solution which would be for me to completely redo the existing code so that it can handle any multiple pair of surface boundaries that arrive when structures have severe leans, negative taper and/or side iterations and multiple trunks. The difficulty level to find these volumes is much great than the current code I have written so far. I am writing this version now and it's slow going. I would prefer to invest my time writing a visual C+ version for commercial use. All ENTS members will get 50% discount on this software"Forest Form" if I should ever bring it to market. I am not sure if it is worth my time yet. We'll see.

Michael Taylor
WNTS VP
http://www.landmarktrees.net

[dham81793]

I have already opened the .ply files and they are awesome, i cannot wait to learn these applications. just wondering what program I should use to open the .xls file? is it just excel? or is there a program that will map the points out graphically that make it easier to read? im not sure if the 2000+ points are supposed to be read in a numerical only format? suggestions would be appreciated!