[Q] Generate Report - Retrieve areas by material of a selection?


#1

Hi Guys,

Since the new generate report as been around and with all the updates it has had, I’ve been trying to generate a report of face areas per material.

The idea is to have a simple and updateable table of areas of the project I’m developing with:

  • Gross Floor Areas;
  • Covered Outdoor Areas;
  • Outdoor Water Proof Pavements;
  • Outdoor Permeable Pavements.

I don’t need any kind of price or cost estimate yet I cannot retrieve the report in simple m2 units.

In the example below you can see how I generated the face areas:

  • Model;
  • Section Cut Face;
  • Draw Areas group on top of Section Cut Face;
  • Each Material corresponds to one of the above area types.

This seems simple enough yet I can’t do it, is it possible? It would be so handy. Thanks!


#2

I agree @JQL
Calculating AREA is fundamental to Architecture, Engineering and Construction.
One might say it’s a large part of the ‘I’ in BIM.


@eneroth3’s plugin does what Generate Report should do, but doesn’t.

Eneroth Material Area Counter — Extension Warehouse
https://extensions.sketchup.com/en/content/eneroth-material-area-counter


#3

Thanks for the support and link. I will investigate Ene’s plugin.

EDIT: That’s pretty simple and probably more effective than using the Entity Info Dialog with TT’s Selection toys.

However it would still be so handy that the generate report could do this. An excel could then be linked to a Layout file and keep synced. It’s the kind of functionality that breaks workflows or creates workflows and seems rather basic.

Let’s hope it’s going to be included in a near future.


#4

Ene’s plugin seems very useful but gets areas from all the model.

It also seems to add the materials that are applied to front and back side of the faces and that causes some issues with, for example, transparent materials which apply themselves to both sides of a face.

I have yet to investigate if having a face painted with no material, gets double area if a component is painted with another material (overriding the no material face). In this situation the material that you use to paint the component gets on the back and front faces duplicating it’s area.


#5

I am not familiar with the plugin, but natively SketchUp’s material area calculation works the same, You can get the area for a material by right-clicking on it in the Material browser (In Model section) and selecting Area from the context menu.


#6

You can attach a dc calculation via script to a group or component then the report writer can “read” it.
A DC can report its surface by using FACEAREA("")/2.
rather than add this manually to your newly created group, you would use a ruby script.
Something like

sel = Sketchup.active_model.selection 

sel.grep(Sketchup::Group).each do |s|

    s.set_attribute "dynamic_attributes","area", "0"
    s.set_attribute "dynamic_attributes", "_area_access","VIEW"
    s.set_attribute "dynamic_attributes","_area_formlabel","Roof Area (sq m)" 
    s.set_attribute "dynamic_attributes","_area_formula", "ROUND(FACEAREA("")*2.54/2/10000,0)"
    
    
$dc_observers.get_latest_class.redraw_with_undo(s)
   
 end

then you could then attach the script to Aerillus “toolbar editor”


#7

Data can be copied from the plugin window pasted into Excel where it can be sorted and tallied.
That is, provided one gives each material a meaningful name.
Adopting a naming schema that sorts logically will yield more intelligible results.


Obtaining accurate results requires accurate input … GIGO
Obviously, painting groups from outside would yield inaccurate results.
Dividing translucent material areas by two is little challenge for Excel.


#8

All the solutions you guys provide are worth using, however I’ve cycled a bit through all and I can’t get a workflow that solves all the work I have to do.

@Anssi
I have tried right-clicking and retrieving area, but as I might have made mistakes and painted a backface or a group, I can never trust the results. My work is never linear. Selecting faces by material and retrieving areas from Entity info doesn’t give double areas as it only counts front faces, ignoring the back faces. It’s, therefore accurate but tedious. I have to manually redo all the work every week and several times if I find something is wrong with the drawing.

@pcmoor
If I divide the resulting area by 2, I’ll always get half the area measured in sketchup. Isn’t it?
That way, if I have correctly painted faces, the area will be half than what I needed.
As I might have some correct painted faces and some wrong I cannot trust the results, or can I?

Maybe it would be possible to simply exclude backfaces from calculations. Most of us are careful to orient faces while modeling as they create all sorts of issues on rendering and even on sketchup display. There are a lot of plugins to easily fix these faces and we architects also use some styles that do require them to be correctly oriented.

We do require painting components so we get variations on the color/textures of multiple instances of the same component.

So in a lot of required situations materials are correctly painted on the component.

You’re right on translucent materials but sometimes even those have errors as backfaces are always hard to check.

My naming schema is quite tidy:

  • I have materials for display and work that always render nicelly - No prefix
  • I have materials for hatching X Prefix
  • I have materials for symbology Y Prefix
  • I have materials for area counting Z Prefix

It’s the modelling that requires a lot of different uses and so it’s always confusing and hard to follow leading to some workflows that are not as ideal as you correctly point out:

  • Arch Modelling;
  • Rendering;
  • Drafting;
  • Consultants/Engineer Overlays;
  • Photogrametry importing/exporting…

Please don’t get me wrong, I can’t thank you enough for the interest and help you guys are giving this issue of mine.


#9

In a DC, facearea("") returns both faces (front and back) in inches, so its independent of the material painted. If put a value into the formula, like facearea(“red”) then it will return any red painted face within the DC whether front or back, if there are “blue” or any other, they are ignored. Your workflow suggests you make separate groups, so if these are of the same material, then facearea("")/2 returns the total of faces (front and back) divided by two, which is the area you require in square inches. The conversion, should be 2.54*2.54 (I missed the square before) /10000 to change to square meters.
The option dialog will show the value, so initially you can check via the info dialog, then can rely on the results when proven after an acceptable number of checks,

If you are using multiple areas within the same DC, you could nominate any of the defined and set a DC to suit otherwise you would need a swatch to make sure the material is loaded.

Then you would write the required formulas, first try a DC, before building a script.


#10

@pcmoor

I will definitely test DC’s. I think I can be careful enough to have backfaces unpainted on any Areas DC and it’s a cool idea.

I never tried reporting DC’s before but is it possible to have Sketchup reporting recursively on selected DC’s?

I feel that I can find the right workflow I can pass it on to other people in the office here. I will finish this project manually and invest some time on it later.

Thanks so much!


#11

Maybe you could use TIGs AreaTextTag plugin. TAGs can be updated when you change faces, and they can be exported as table to CSV file. CSV could be imported to Layout.


#12

There’s also Fredo tools report areas.

Even so, generate report shouldn’t make this complicated, it’s not the SU way to have such a limited scope on reports.