[Plugin] Export Vertices to CSV

TIG

Robert

Just so I don't go down a blind alley here...

What I think you'd like is that you make a 'selection of things'.
If that selection includes raw geometry you get a 'modelname_verts.csv' file with all of those vertices in [as now].
If its a selection within another context - e.g. a component edit, then the file's name is 'defnname_verts.csv'.
Next, if any items selected are groups or component-instances then we 'mine down' into those and get the raw geometry's vertices in those.
These sets of vertices' locations go into separate files as 'groupname_verts.csv' or 'defnname_verts.csv' as appropriate - the vertices' positions XYZ will be 'transformed' from their actual locations inside their context to the model coordinate system, so that all 'points' are then in the correct relationship if 'overlaid'.
Do you need to process groups/compos inside groups/compos etc ? if you do then those transformations might get painfully convoluted but doable...
This is all quite doable, I just want to ensure I don't do it twice...

You speak of 'drilling' no centers will be made this way.
You could perhaps have another tool that adds cpoints at the center-points of all arcs/circles and exports a separate CSV list of those these

charly2008

Hi TIG,

maybe a stupid question of the practical purpose for this plugin. I have no idea at the moment. Maybe you can even give an example please.

Charly

TIG

@charly2008 said:

Hi TIG,

maybe a stupid question of the practical purpose for this plugin. I have no idea at the moment. Maybe you can even give an example please.

Charly

One example - if you have a mesh you can export all of its vertices as a CSV and import them into another app as a triangulated mesh.
Another - you can export the CSV list of points into an app that uses them to cut, drill etc...

charly2008

HI TIG,

thanks for your quick response. Now I understand it.

Charly

robertWan

I'm sending .skp file and an example of SCV file.
Drill mark has 3 vertices.
Vertices---line---vertices---line---vertices.
Hinge cylinder and plate aren't needed (many vertices) in SCV file. That is why i would like to be able to choose components. Filter? Precision of vertices' position 0.000. Now they are only integre.

Robert

exaple CSV

example cabinet

TIG

@unknownuser said:

I'm sending .skp file and an example of SCV file.
Drill mark has 3 vertices.
Vertices---line---vertices---line---vertices.
Hinge cylinder and plate aren't needed (many vertices) in SCV file. That is why i would like to be able to choose components. Filter? Precision of vertices' position 0.000. Now they are only integer.
Robert

Correct me if I misunderstand you...
First what looks like each 'drill mark' in your SKP seems to made from two lines - so they can then have 3 vertices ?
Does your drilling machine then know the 'vector' of the drilling from some of those and then the start or end of a pair is the point it drills at whilst the second line's vertex gives the depth to drill - how are 'we' to 'know' which vertex is which when it's written into the CSV file ?
Are they vertices always 'drawn' in the same order ?
It might be a lot easier if you have a few standard drill-points to simply use a component instance that has some attributes that we read - when you add the drill-point at a point [used for the drilling] you set a diameter and depth - later when the CSV is compiled we can get the drill-points location and direction from its own transformation in 3D and then read the attributes to get its diameter and depth... The nesting of the drill-point then has to be applied to the location/direction to set it into the model's coordinates - unless of course you really want these applying to a particular panel's transformation - I assume the drilling machine is fixed and the panels passed beneath it - so it's little use knowing if the hole's direction is 'left' when actually it's 'down' on the jig ?

To choose particular 'types' of component would be possible but how would you do this ? A list would quickly become unwieldy. In your example - shown above - we have:
Three 'Hinge 35' instances in the model and each
'Hinge 35' contains
'Hinge' which contains
'two drill mark 2mm' which itself contains two instances of
'Drill Mark 2mm'
AND
'two drill mark 5mm' which itself contains two instances of
'Drill Mark 5mm'

So you only wants this starting with 'Drill Mark' AND the side/door reporting in the CSV ?
Or put another way anything starting with 'Hinge' is ignored in the CSV report, BUT things within 'Hinges' are reported if they are 'Drill Marks'....

This nesting of drill marks within the Hinge components makes getting the transformations of each drill-point awkward but not impossible... We have to get the transformation of each instance of the Hinge 35, and the transformation of each Hinge within that instance's definition and the transformation of the 'two drill mark...' instances within that instance's definition and finally the transformation of each 'Drill Mark...' instance within each of those instances

I have to think about how to iterate all of this...
Can you write a simple step sheet on how you would hope to use this... For example
I open the SKP
I select the assembled cabinet
I run the reporter
I specify what parts are to be reported [or perhaps ignored?]
A CSV file is written... etc

The tolerance of the reported CSV numbers should be the same as you have set in your Model Info > Units, so if you work in mm and only report dims etc to the nearest mm then that's what the CSV has in it too. It could be possible to remember you current setting then temporarily rewrite them to say 3 d.p. [1.234] while the CSV is made and reset back again afterwards... using Sketchup.active_model.options["UnitsOptions"]["LengthPrecision"]
I notice your example SKP has 0.00mm set. So you should get 1.23 in the CSV if the length actually is 1mm it should still format to 1.00 ? If it isn't doing that it can certainly be made to. Read the CSV in Notepad to check - if you open it in Excel it will usually not display trailing zeros or unneeded decimal-points in its cells?

robertWan

@tig said:

First what looks like each 'drill mark' in your SKP seems to made from two lines - so they can then have 3 vertices ?

Only because that one vertice's components can't be created. At least 3 vertices and 2 lines.
Drill mark

@tig said:

Does your drilling machine then know the 'vector' of the drilling from some of those and then the start or end of a pair is the point it drills at whilst the second line's vertex gives the depth to drill - how are 'we' to 'know' which vertex is which when it's written into the CSV file ?
Are they vertices always 'drawn' in the same order ?
It might be a lot easier if you have a few standard drill-points to simply use a component instance that has some attributes that we read - when you add the drill-point at a point [used for the drilling] you set a diameter and depth - later when the CSV is compiled we can get the drill-points location and direction from its own transformation in 3D and then read the attributes to get its diameter and depth...

It will be like that. Only a vertice in the middle will be used. If there are less thank 3 vertices a component can't be created.

@tig said:

The nesting of the drill-point then has to be applied to the location/direction to set it into the model's coordinates - unless of course you really want these applying to a particular panel's transformation - I assume the drilling machine is fixed and the panels passed beneath it - so it's little use knowing if the hole's direction is 'left' when actually it's 'down' on the jig ?

So you only wants this starting with 'Drill Mark' AND the side/door reporting in the CSV ?

Yes. Only those which have in the beginning of a name some phrase. For instance Drill, Door, etc.
Or every that beginns with some character, e.g. "*".
So as in the file there are no unnecessary components, like lamp, floor, ceiling, dishwasher etc.

@tig said:

Or put another way anything starting with 'Hinge' is ignored in the CSV report, BUT things within 'Hinges' are reported if they are 'Drill Marks'....

This nesting of drill marks within the Hinge components makes getting the transformations of each drill-point awkward but not impossible... We have to get the transformation of each instance of the Hinge 35, and the transformation of each Hinge within that instance's definition and the transformation of the 'two drill mark...' instances within that instance's definition and finally the transformation of each 'Drill Mark...' instance within each of those instances

I have to think about how to iterate all of this...
Can you write a simple step sheet on how you would hope to use this... For example
I open the SKP
I select the assembled cabinet
I run the reporter
I specify what parts are to be reported [or perhaps ignored?]
A CSV file is written... etc

After thinking it over
Open SKP
run the plugin
only parts beginning with, for example "*" will be reported.
a CSV file is written

@tig said:

The tolerance of the reported CSV numbers should be the same as you have set in your Model Info > Units, so if you work in mm and only report dims etc to the nearest mm then that's what the CSV has in it too. It could be possible to remember you current setting then temporarily rewrite them to say 3 d.p. [1.234] while the CSV is made and reset back again afterwards... using Sketchup.active_model.options["UnitsOptions"]["LengthPrecision"]
I notice your example SKP has 0.00mm set. So you should get 1.23 in the CSV if the length actually is 1mm it should still format to 1.00 ? If it isn't doing that it can certainly be made to. Read the CSV in Notepad to check - if you open it in Excel it will usually not display trailing zeros or unneeded decimal-points in its cells?

In SU 500,6 but in CSV 500,0
box 500,6 x 500,6 x 100,6

box 500,6 x 500,6 x 100,6

Thank you for your help and involvement.

Robert

ACP

Dear Sir:

How do I make Exportvertices2csv.new work on Sketchup Pro 8....?
Is it not supposed to work on version *, or what is the problem with the script.
I am new using Rubi Scripts, but it seems like there is something wrong with the script. here is the message I get on the Rubi Console:

exportvertices2csv
Error: #<NameError: undefined local variable or method `exportvertices2csv' for main:Object>
(eval)

I very much appreciate an answer either here on this forum or by email at:
antonio @ synergyamericas.com

Thank you very much!
Antonio

TIG

@ACP

The way to make it run is - in a saved SKP, select faces/edges etc that you want to export the vertices from, then in the Ruby Console bottom line type [OR copy/paste]:
Exportvertices2csv.new
then press <enter>
It must be written exactly as written above.
It must start with a capital 'E' and end with '.new'
Your example shows you are using a 'lowercase' version, with no terminating '.new' - so only a miracle would make it work in any version of Sketchup !

pichuneke

Tig, sorry to say that, but I have the same problem as the rest of some people here.

I am trying to export the points to import them with a software of topography, and I have this csv (sample):

142.0 120.0 -0.0
142.0 122.0 -0.0
143.0 120.0 -0.0
140.0 120.0 -1.0
140.0 122.0 -0.0
141.0 122.0 -0.0
138.0 120.0 -2.0
137.0 121.0 -2.0
137.0 122.0 -2.0

As you see, no decimals at all. I have chosen meters, "decimal" and precision 0,000 . No 0,000m extension.

I don't know what to do. I've read this thread and other similar to this: ExportCpointstoCSV (http://sketchucation.com/forums/viewtopic.php?f=323&t=40061). I don't like to ask for help and importunate you, but... can you help me?

TIG

What format does your Topo software need.
The format:
137.0 122.0 -2.0
Looks to have the standard '.' as the decimal-point NOT ',' as you might use in Spain... and is separated by a space OR a TAB ? Using a ',' wouldn't work with that in the numbers too !
Also what units are expected etc?
The numbers after the decimal point truncate to .0 if there are no more ?
There are various ways of exporting things like this around the forums.
For example, do you really want to export 'vertices' ?

pichuneke

@tig said:

What format does your Topo software need.
The format:
137.0 122.0 -2.0
Looks to have the standard '.' as the decimal-point NOT ',' as you might use in Spain... and is separated by a space OR a TAB ? Using a ',' wouldn't work with that in the numbers too !
Also what units are expected etc?
The numbers after the decimal point truncate to .0 if there are no more ?
There are various ways of exporting things like this around the forums.
For example, do you really want to export 'vertices' ?

It's separated by a ","; and the '.' is the decimal separator. Anyway the software used to read it it's not a problem. I mean, I have copied the text numbers from a text editor. Anyway, if you want, you have here from notepad:

142.0,120.0,-0.0
142.0,122.0,-0.0
143.0,120.0,-0.0
140.0,120.0,-1.0
140.0,122.0,-0.0

So the text editor is not a problem. Sketchup generated that file as you read it.

I would like something like 142.24, 129.89, -0.025 (at least 2 decimals, or cm). It's for a topographical map I made by photogrametry. I am experimenting, to be honest, trying to find if this way of making maps is useful for my work.

I have to leave to go to lunch in 20 minutes, see you this evening. (The spanish lunch, a lot of food. But no siesta.)

TIG

If I load the original .rb from the first post of this thread and then type Exportvertices2csv.new etc; then with the Model Info > Units set as 'meters', with 0.000 and no 'm' suffix etc, it works fine on the selected geometry's vertices.
Vertices with exact 'm' values report as whole numbers
1,2,3
but when with 'mm' parts they appear as
1.234,5.67,8.9
etc...
So I don't see how you are getting these results
With the same Model Units setting as above, as a test preselect a simple face [but one that is NOT 'flat' in 3d] and copy/paste this code-snippet into the Ruby Console + <enter> and report the output.

Sketchup.active_model.selection[0].vertices.each{|v|puts v.position.x.to_s.gsub(/^~ /,'').to_f.to_s+','+v.position.y.to_s.gsub(/^~ /,'').to_f.to_s+','+v.position.z.to_s.gsub(/^~ /,'').to_f.to_s}

Are the values as you might measure 'on screen' ???

pichuneke

Before doing what you told me (copy and paste your code), and after reading you, I selected mm instead of m.

These were the results for the first 5 lines:

142416.0 120527.0 -532.0
142416.0 122200.0 -13.0
143444.0 120527.0 -13.0
140002.0 120527.0 -1720.0
140002.0 122941.0 -965.0

After that, I selected again "m" (meters), and these were the results:

142.0 120.0 -0.0
142.0 122.0 -0.0
143.0 120.0 -0.0
140.0 120.0 -1.0
140.0 122.0 -0.0

A workaround would be to obtain the results in millimetres, and divide them by 1000, so I can obtain 142.416 and so on.

Now I am going to do what you told me.

With "meters" as the selected unit, I choose a face (a triangle):

@unknownuser said:

Sketchup.active_model.selection[0].vertices.each{|v|puts v.position.x.to_s.gsub(/^~ /,'').to_f.to_s+','p+v.position.y.to_s.gsub(/^~ /,'').to_f.to_s+','+v.position.z.to_s.gsub(/^~ /,'').to_f.to_s}
Error: #<SyntaxError: (eval):155: compile error
(eval):155: syntax error, unexpected tIDENTIFIER, expecting '}'
....gsub(/^~ /,'').to_f.to_s+','p+v.position.y.to_s.gsub(/^~ /,...
^>
(eval):155

With "millimetres" as the selected unit:

@unknownuser said:

Sketchup.active_model.selection[0].vertices.each{|v|puts v.position.x.to_s.gsub(/^~ /,'').to_f.to_s+','p+v.position.y.to_s.gsub(/^~ /,'').to_f.to_s+','+v.position.z.to_s.gsub(/^~ /,'').to_f.to_s}
Error: #<SyntaxError: (eval):155: compile error
(eval):155: syntax error, unexpected tIDENTIFIER, expecting '}'
....gsub(/^~ /,'').to_f.to_s+','p+v.position.y.to_s.gsub(/^~ /,...
^>
(eval):155

Hope it helps.

Dave R

Out of curiosity, to what is 'Precision' set when you are using metres as the units?

TIG

The precision for 'meters' MUST be 0.000 ! to get up to 3dps reported...

Sorry but there was a typo in the line of code.
Retry copying it again from the earlier post.
It should return a list of values:

Please also try this line too

    Sketchup.active_model.selection[0].vertices.each{|v|puts v.position.x.to_s+','+v.position.y.to_s+','+v.position.z.to_s}

It might be down to you using a ',' as a decimal-point rather than a '.' ?

pichuneke

@dave r said:

Out of curiosity, to what is 'Precision' set when you are using metres as the units?

@unknownuser said:

The precision for 'meters' MUST be 0.000 ! to get up to 3dps reported...

As a curiosity, some of Mars Curiosity instruments were tested in the place I am trying to make the topographic map (and thanks for teaching me the meaning of the expression "Out of curiosity")

I attach you a capture with the settings I've been using. In spanish, but you'll understand it. And yes, I've been using a precision of 0,000 , as you can see in the attached image.

Image Capture of the settings

Tig, with the new code, the results are:

@unknownuser said:

Exportvertices2csv.new
#Exportvertices2csv:0x1a8911dc
Sketchup.active_model.selection[0].vertices.each{|v|puts v.position.x.to_s+','+v.position.y.to_s+','+v.position.z.to_s}
-141,225,-82,242,-19,325
-142,207,-82,242,-20,532
[#Sketchup::Vertex:0x1a4423d8, #Sketchup::Vertex:0x1a42d8e8]

I think you are right, Tig. Now I am trying to find way to change it in my preferences (although you know that the use of "," and "." varies a lot between countries). It's always been a problem, for example I use Libreoffice in Spanish and the use of the numeric punctuation in Libreoffice Calc is problematic, Mexicans use a system, here in Spain we use another...

TIG

I see the issue now.
It is related to ',' versus '.'
I'll post an update...

TIG

Here's v1.2 http://sketchucation.com/forums/viewtopic.php?p=298614#p298614
A ',' can now be used as a decimal-point, as well as a '.'... AND keep the d.p. values set in Model Units...

This fixes pichuneke's problem

pichuneke

@tig said:

Here's v1.2 http://sketchucation.com/forums/viewtopic.php?p=298614#p298614
A ',' can now be used as a decimal-point, as well as a '.'... AND keep the d.p. values set in Model Units...

This fixes pichuneke's problem

Thanks a lot, I'll send you a private message with a image of the results of my experiments