[Plugin] Export Vertices to CSV

Gaieus

Thank you, TIG!

takesh h

I was wondering why such a plugin doesn't exist... it must be awfully hard to code, I imagined.
Then I opened TIG's latest script - what? a little more than 30 lines can do this?
TIG must be a genius (maybe I didn't have to tell you that). Thanx!

Jim

I really wish you would namespace this stuff.

What's the difference for the user between typing exportvertices2csv and TIG.exportvertices2csv

TIG

@jim said:

I really wish you would namespace this stuff.
What's the difference for the user between typing exportvertices2csv and TIG.exportvertices2csv

To be flippant it's the "TIG."
But seriously though folks... I do use classes etc for much of more recent complex stuff and I know that if it's to run off a menu item then it is even less hassle... This was just a few lines of code that you could almost type into the Ruby Console, it it took more that one line at a time... What is the difference between typing code into the console and having a few lines load from a script as a new base-class method ?

BUT perhaps to turn it around... please explain clearly why TIG.exportvertices2csv would be S_O__M_U_C_H better than exportvertices2csv ? It's highly unlikely that 'exportvertices2csv' will 'clash' with anything else and adding extra Modules/Classes must also surely 'clog things up'... but perhaps just in a different way to adding methods to the base-class itself ? What terrible problems await those who do it my way ??
You know that I am an Architect and NOT a 'programmer' per se: whilst I am sure that there are very 'good reasons' for your suggested approach, I can still see little benefit to me personally to break a habit of a lifetime and actually do things 'properly'

Jim

The reasons have been thoroughly covered.

http://forums.sketchucation.com/viewtopic.php?f=180&t=29560

It takes in practice no extra time or effort to go from "unlikely" to impossible.

honoluludesktop

@tig said:

.............You know that I am an *Architect and NOT a 'programmer'*per se: whilst I am sure that there are very 'good reasons' for your suggested approach, I can still see little benefit to me personally to break a habit of a lifetime and actually do things 'properly'

You could have fooled me. Just kidding out of envy, and admiration.

Jim

Here's an article by Rich Morin about the SketchUp environment:

http://cfcl.com/twiki/bin/view/Projects/SketchUp/AT_Modularity

(Sorry this is getting off-topic. Please move it if you prefer.)

TIG

@jim said:

Here's an article by Rich Morin about the SketchUp environment:

http://cfcl.com/twiki/bin/view/Projects/SketchUp/AT_Modularity

(Sorry this is getting off-topic. Please move it if you prefer.)
I'm fine with it here for now...
@unknownuser said:

As Rich Morin says...
Ruby offers a nice selection of constructs for modularity.
In rough order of granularity, these include: expression, statement, block, method, module, and class.
It's impossible to write Ruby code without the first two constructs; the following one-line script is both an expression and a statement:
puts 'hello, world'
However, the other levels are completely optional; the programmer must decide whether and where they are needed.
Because each added construct adds complexity, it should provide compensating benefits in program clarity. Otherwise, it's simply unnecessary "overhead".
A short script may get by with several statements, a block or two, and no method, module, or class definitions.
As scripts increase in size, other constructs can add modularity, keeping the code base manageable***.
A code base of several hundred lines might well use all of them to good advantage.
***There is a 'can' in there NOT a 'must'...
So... I generally agree with him... However, I see little benefit is 'modularizing' a short snippet on it's first outing: after all I did cobble this code together within a few minutes... I am not writing 'professional code' here.
Rich Morin comes at this from the opposie direction - he's a programmer writing code that does something for the likes of me - I do something with code for the likes of me - there is a difference... It's like I'm just driving a car down the street - I am not is a Grand Prix or exploring the Arctic like some see to want to do...

thomthom

@tig said:

BUT perhaps to turn it around... please explain clearly why TIG.exportvertices2csv would be S_O__M_U_C_H better than exportvertices2csv ?
[...]
What terrible problems await those who do it my way ??

Method in the global space - and extending methods which is pretty much the same as adding a method in global space - has a chance of clashing.
We have examples of the method box being defined by two plugins in global space. And we have the Array.offset method defined by multiple plugins which has caused issues.

Keeping everything in a namespace is safer - as picking a namespace to id you and keep all your code in there allows you much greater control and security over name-clashes.

Take the Image class for instance, there are several snippets here on this forum that adds .definition and .instance to the Image class. I think some plugins do so. Now, the .transformation addition in all versions is flawed as you know.
I've been trying to get Google to add .definition and .transformation to the Image class - but here is the issue. None of these snippets that extend the Image class checks if the method already exists.
So if Google implements correct .transformation class it'll be overwritten by bugged versions.

It's due to these kind of issues that I stopped working on the SKX project as I saw the potential for causing more clashes. Instead I now use my own library where I don't extend any base classes. It doesn't make my code look as neat as if the base classes had been extended, but it's safe. 100%.

TIG

Update here http://forums.sketchucation.com/viewtopic.php?p=298614#p298614
I have wrapped the code in a class to use you now type Exportvertices2csv.new in the Ruby Console or in your own menu item...

robertWan

Hi.
Could you modify the plugin so that it saves vertices of all (or some) components?
With no need of using Explode.
The name of a component and coordinates of the vertices in SCV file are needed.
It would be perfect if only components with, for example: "plywoodxxx", "drillxxx", in names were saved.

TIG

It will already save the vertices in any selection - so if you edit a group or component it will save the vertices of things selected in that context.
YOU could simply recast the code so that rather than process selected entities' vertices it goes through the entities in any selected group [or instance-definition] and returns their entities' vertices to a CSV [perhaps transformed by the group/instance's transformation] and named after the group/definition rather than the model... why not try to write it yourself ?

robertWan

I'll have few hundred components and sub-components.
That is why it can't be hand made.

And I'm not able to write it myself, because I'd have to learn Ruby.

From those coordinates I'm going to make in Exel a file to drilling machine.
Something like a plugin CutList but with coordinates of the holes on a sheet.

Robert

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