Dear all,
you for sure would not believe, what I tried in the meantime, to get clean SVG out of SU7 FREE. Call me beeing stupid.
All attempts, getting clean SVG out of FREE, including using an EMF (Enhanced Meta File) printer drivers, failed in some or the other way.
My last resort was to ask Google for a PDF export even in the FREE version. Just sent, if they answer, I'll report.
Best regards, deerwood
Dear thomthom,
thanks a lot for still helping. I could only start to analyze the Adobe Distiller generated PDF, because the SVG generated out of that is EXTREMLY different from both, the (nearly optimal) SU PRO Export and the (ugly) results I got so far. With regard to the SVG filesize it is somewhere between both extremes (22K < 54K < 183K).
But it also produces, in principle, a similar result with regard to the shaded areas. It also uses these bounding box shading rectangles and clips them afterwards and the clip pathes used have many excess knots along the edges ... although much less than the PDFCreator produced ones.
And finally the distiller produces extremly nested SVG (I still assume, that Inkscape follows the PDF/Postscript instructions 1:1 just translating to SVG). It begins with clipping twice and continues by grouping simple pathes extremly deep, just to apply transformations, like so:
<g transform="translate(364.68,319.34)" ...
<path d="M 0,0 L 84.96,-32.16" />
<g transform="..."
<path d="M 0,0 L -244.02,85.56" />
<g transform="..."
<path d="M 0,0 L 100.32,-72.48" />
<g transform="..."
<path d="M 0,0 L -96.9,69.06" />
<g
... 15 levels more
...
</g>
</g>
which makes editing and analysis of the SVG extremly difficult.
I also gave the SVGMaker printer driver a try with even different results. This one isn't really better, but it does not use clipping, instead it uses shaded pathes for the faces ... but these pathes have even more excess knots. That front face from my last post (with 209 knots) has more than 2000 knots in SVGMaker!!! All along the edges, but distibuted much more evenly.
My first conclusions to all these observations are:
Best regards, deerwood
Hi all,
just to let you know: the overly complicated clippathes ain't neccessary at all, but either produced by intention or by some really stupid piece of code (maybe in some library). See this image (screenshot from Inkscape, clippath turned into a normal path, path edit tool active, so that the knots show up):
Note the almost clean path at the lower edge.
When we further zoom in (here the former clippath is given a red outline and moved to the very front), the whole mess of unneccessary knots will be visible more clearly:
I checked: the extra knots are already present in the PDF file, so it is definitely not Inkscapes fault. And I cross checked with a Postscript printer driver (HP2500 PS3) ... the generated Postscript was very different from the PDFCreator/Ghostscript one (different headers and thus different printing instructions). But the madness with these excess knots was identical.
So I'm pretty sure now, that the strange code leading to the excess knots is not located in the printer drivers. Instead it must be the way SU 7 free paints to the printer device context/driver. It would be most interesting, if the SU 7 PRO version produces similar results when printing, because we know, it can do much better when exporting. If PRO also shows this strange behaviour, I would want to add a feature request to do that better or even report it as bug, because also the PDF files are unneccessarily large.
If PRO behaves better when printing, then, sigh, SU 7 free users have to live with that as it is, which would be a pitty.
One could, in simple models like this sample SVG, go and manually modify the SVG with Inkscape, e.g. by
But then, this is really only for the "very poor man" and for simple models. So that e.g. the occasional supporter of wikipedia commons is aware of the issues, but not totally lost (and this thread will show up on Google searches, thus I must warn/hint, to keep commons free from really bad SVG files).
Finally I hope, that Google will be really aware of SVG beeing/becoming THE new web standard for vector oriented 2D graphics and sponsors/supports it much more (they already sponsored Inkscape development in a summer of code). Though MS obviously ignores SVG as a WEB standard in IE, almost all other important browsers support it. And beating MS is one of Google's current goals, isn't it 
?
Best regards, deerwood
Dear thomthom,
thanks a lot for your support.
@thomthom said:
I've attached a .zip with two pdfs. One is from SU's export function, and one is made using Adobe's PDF printer.
(p.s. You added the .skb, not the .skp file...
)
The SU Pro export (SUpdf.pdf inside your ZIP) is as perfect as it can be and produces a very nice SVG file, when imported into Inkscape, with all face shading and only ~22K filesize. All visible face parts are given out before/below the edges (in Z-order) as polygons, the polygon points are excactly in the corners of the 3D objects mapped to perspective 2D. After that follow all edge lines, partly overlapping the faces because of their thickness. This is almost identical to what a human would do, when drawing such a picture! See attachments.
Your exported PDF already shows that. It is almost uncompressed plain Postscript and can be inspected with text viewers. You'll see then essentially pathes constructed from MOVE_TO X,Y and LINE_TO X,Y. Inkscape just translates that into SVG syntax without hassles.
So the good news is: users of the SU 7 PRO version can generate nearly optimal SVG files easily.
The given "AdobePDF.pdf" obviously is in pixel format (I counted/estimated them: ~400 pixels or so not beeing white , PDF file size ~9KB). Maybe you didn't check that "Use high accuracy HLR" in the SU initial print dialog? Also, if you still wannna help, would you please check "Fit to page" and "Use model extents" in your print dialog? The EPS file you gave looks to me as pixel format too. I was not able to import it as vectors into Inkscape (though I had to pipe it through GhostScript 8.63 for conversion from EPS to PDF).
Oops/sorry for that SKB (what is that anyway)? You could open it?
Thanks a lot,
at least there is good news for PRO users,
best regards,
Georg aka deerwood
Hi Chris,
as told, I had no name clashes yet in any way. But I see myself "managing" my plugins already, though I'm still a newby.
Especially because there are soooooo many, very helpfull plugins around/published in this forum (wow, thanks to all providers). I have to find a way to try these out and find the ones appropiate for my way of working with SU ... ever changing as I get these new great additions and learn to use them.
And then: Rick warned, I wrote, what came up into my mind. Maybe, that is poor/not appropriate. It is meant as just a base idea ... brain storming, as stupid as it may be, should not be taken literally. Take just one idea out of it or come up with a totally different general approach. Collect as much of ideas as possible. Later on one or the other may be able to make use of the idea.
Best regards, Georg/deerwood
Dear Rick, all,
@rickw said:
Interesting concept, and for creating Module names, it could work. However, locating files in subfolders by organization/author name conflicts with Organizer.rb.
sorry, I wasn't aware of the organizer.rb. Hmm. Still not giving up on the subfolder idea , what about more closely mimic that Java concept by having under "plugins" max 2..4 letter folders named after the top level domains, e.g. "com", "edu", "org", "net", "tv", "de" or "co"? Isn't the length of TLD's restricted?
The organizer then could just ignore short folder names directly under "plugins", or, if neccessary, have a list of (additional) TLD names to ignore.
Under the TLD folders there would be the appropriate domain name folders of the authors. So someones/Jims/yours/mine plugins would reside in
plugins
co
uk
someone
someone-else
com
blogspot
sketchuptips* smustard
de
georg-rehfeld
For the module/class names I'm not any longer really happy with my proposal, because the names would be so exceptionally long/unusabale. Or did I miss some Ruby feature?
Just brainstorming, not more.
Best regards, Georg (aka deerwood)
Dear all,
I investigated a little bit further into that clippath thing. With the help of Inkscape and my text editor (yes, SVG actually is XML, so you can work on it with text tools including scripts ) I removed all these clippathes and their references, which turned the SVG filesize down from 180 KB to 18 KB. The file still is valid SVG ... but I lost all face coloring and was left with just the edges. See attachement.
So it turned out, that it has to do with shading/coloring the faces and seems to be caused by the PDF printing/export already and not beeing the fault of the InkScape import.
To shade/color a face a colored rectangle covering the 2D bounding box of the face in question is given out. As that opaque rectangle is much too big and would either cover other parts of the drawing or show up in the wrong places that rectangle then is clipped ... leading to overly complicated clipping pathes.
In plain SVG one instead just would define filled polygons exactly covering the visible face parts (in Z-Order behind the related edges of the face). I believe, this would reduce SVG file size essentially compared to the clipping way. And filled polygons are available in PostScript too and thus in EPS/PDF.
Please note, I am not complaining here in any way, just reporting what I've found, so others are aware of it.
What I'm not sure about is: is that strange way coloring faces is the way SketchUp works, maybe only when printing? Or is that caused by the used PDFCreator printer driver?
If you want to do me a favour, can someone with the SU 7 PRO version please be so kind and directly export the "four_matches.skp" (found in an earlier post) to PDF and hand it over to me? Thanks in advance. I'll then report here the results of my further exploration.
Remember, one of my main reasons for having SVG out of SU is supporting wikipedia commons (respecively open a way for others to better support commons) and they ask for SVG not only because of it's scalability, but also for SVG typically beeing much less in file size than pixel formats (for diagrams and schematic drawings, photos etc. still are better off in JPG).
Again, thanks a lot, this is such a friendly and helpful forum, I'm happy to have found it.
Best regards, deerwood
Dear all, especially thomthom and Anssi,
thanks a lot for your tips. Now I actually can generate SVG from SketchUp 7 free using only open source GPL tools! See attached ZIP with SVG file (I'm not allowed to upload SVG files directly). The SVG itself should be directly viewable in Safari, Firefox and Opera, in the latter two you also can zoom into the picture and see, that there is no quality loss, because it is really vector format.
I installed the PDFCreator printer driver and printed from within SU to a PDF file with the mentioned "Use high accuracy HLR" checked. This option is indeed available in the free SU 7 (and also documented to be available there). The PDF already looked very good and was zoomable to any extent without quality loss.
Then I startet InkScape and just imported the PDF, which took a second or so. I saved in InkScape SVG (plain SVG is possible too). And voila!
Note that this just was a quick check. The SVG file contains a lot of clippath elements, that I believe might not really be neccessary and blow the file size up much more as the few lines are worth it. But then I just worked with all default settings. I'll try and see if I can get rid of unneccessary clip pathes.
How nice! Thanks again, best regards, deerwood
Dear Todd, all,
sorry for my late answer. This is a really great forum with so many helpful people around giving their knowledge away. I can't really keep up with all that in a timely manner .
@unknownuser said:
What I meant was I didn't know how to remove the faces in the model that that camera cannot see.
Yes, that "occlusion culling" gives me headaches too (my brain hurts). All algorithms I could find are assuming pixel output (Z-buffers etc). But for a vector output all these won't work.
In the extreme case neither entities nor lines nor points give a clear indication of what is in "in front" of each other ... because part of every entity might be "in front" of some entity and at the same time "behind" some other entity as seen from the camera:
After a discussion with an "expert" (actually my son, a student in CG) we came up with this basic idea:
Several problems had to be solved, amoung others a blind test for intersecting lines in the 2D camera space must be optimized somehow, to avoid (O2) behaviour (testing every line against every other line is just to expensive).
Could this idea be turned into a concept? If so, I/we can't believe to have found it before others. There MUST be some others having done that or better (e.g. the EPS/PDF export in SU Pro). Any pointers to vector algorithms are welcome.
Best regards, deerwood
Hi all,
though I not yet had any name clash problem, may I suggest a rule adopted from the Java world? The essential idea is to qualify/prefix "packages" with something unique in our internet world. Namely the domain of the author, reversed, optionally followed by some more specific info.
So e.g. Jim's "jitter.rb" is qualified by "com_blogspot_sketchuptips" and the specific info beeing "jitter".
And Ricks "GoldenGauge" is qualified by "com_smustard" (or maybe "com_smustard_wilson_rick") and the specific info beeing "golden_gauge".
Following that idea the plugins working code would not reside any longer directly inside the "plugins" directory (unless it is an essential thing/library) but in some directory named after the domain inside "plugins".
E.g. Jim's plugins ALL reside in "plugins/com_blogspot_sketchuptips" and ALL of the Smustard ones are present under the "plugins/com_smustard" directory, optionally further down in a dir named after the author ("..../wilson_rick") or a project ("..../common" or "..../utils").
And, please, all other excellent plugin writers here around: I apologize to not have named you. But you'll get the idea, hopefully.
To call/activate such a plugin on startup of SU there must be a minimal Ruby script directly in the "plugins" dir, requiering the real code. These would be one liners, but then named after the complete path to the plugins code. E.g. "jitter" would have this Ruby in the "plugins" dir (named "com_blogspot_sketchuptips_jitter.rb"):
require 'com_blogspot_sketchuptips/jitter.rb'
But it should be easy to just call a script common to a domain, that does advanced handling of (sub)scripts to be included. That script then just requires, what the final user wants to have. These require scripts (down to any level of the dir hierarchy) could easily be tweaked by users, by just commenting out "require" statements.
Packaging of plugins into this hierarchie/concept is easy for every developer of plugins.
Every plugin's author is known/can be reached (as long as his domain is existent).
Cluttering of the plugins directory is reduced greatly, especially when the feature of just require'ing subdirs reqire scripts is used.
What do YOU think?
Best regards, deerwood
Hi all,
Thomas, thats a nice use of yield inside blocks ... I wasn't aware of that possibility in Ruby!
And Jim seems to be right, component definitions often exist although not instantiated (e.g. that default man in the corner).
And, though Matthieu did not specifically asked for that, I can imagine, that he also is interested in the actual transformations (final placement and scale) of every component instance. At least I would be interested in that information.
But, maybe, the transformation thingy opens a "can of worms"?
best regards, Georg
Dear thomthom, all,
@thomthom said:
It was just that what deerwood said sounded to me that, modules where to be used for a few methods, but classes if you had many. Maybejust me that read it odd.
I've seen often in scripts that classes has been used as purely encapsulation and never used as objects.
sorry for my late answer, I just had prepared a continuation of my earlier post ... and lost it completely in an editor (notepad++) crash 
!
Yes, you are right: if one invents a class with only class methods, it makes no real sense at all to instantiate that class, because the instantiated object(s) don't carry any state. The Java Math class is an example. It has a full load of useful class methods, e.g. Math::sin(), Math::cos() etc, all getting in the values to work on by providing them as parameters. But it has no state at all (and no instance methods). In Ruby one would normally use a module for that (independent of the number of modul/class methods, compare the Ruby Math module). But then, it doesn't harm to use a class. Just do not instantiate any objects from it and use it the same way you would use a module, just to have your own namespace.
Class/module methods do their work by accessing some commonly available information (e.g. Sketchup.active_model.selection) or some parameters or a combination of both.
Though there is more to tell about Ruby modules (later).
But the Ruby way of dealing with things is different. In Ruby almost everything is an object. Even simple things like integers are full blown objects. Try this in the Ruby console:
65 >> 65 65.next >> 66 65.chr >> A 65.next.next.chr >> C
You just invoked two easy to use methods on a simple integer number object. What is an object, then? Something having a state (a value or some values, individual to each object) and a behaviour (common to all objects of that type). Every integer object in Ruby has it's own state (that integer value) and a common behaviour (next always gives you a new integer object with it's value incremented by one). And chr spits out a 1 character long string object with the ASCII representation of the value.
Note, that both methods take no parameter at all ... they use the internal state of the integer object at hand.
It would be very inconvenient to have to define the common behaviour of something in all and every object of that sort. Thus OO languages (including Ruby) have classes to define the common code/behaviour for all things of that sort.
If the class is in place, you can later instantiate as many objects of them as you need. Every instance/object will have it's own state (using up memory) but share the same behaviour (not using up memory).
So, for now (remeber my loss of ready made explanations): if your plugin does not carry around some state (or you save them somehow externally in attributes) you might be fine with just using module/class methods.
Still to be continued ...
best regards, deerwood
Hi Jim, all,
thanks for bringing up this topic.
I might be wrong, because I'm just trying to learn Ruby and the SU Api, but I believe, it is always a good idea to encapsulate plugins into a class or a module. Else everyone potentionally stumps onto the feet of others.
Because, if you just use 'def some_method' you actually add methods to the class 'Object' beeing the parent of all other classes and thus it is easy to accidentially redefine/overwrite methods already in place.
Try the following in your ruby console, directly after starting SU (and maybe with all plugins removed, to be sure). Your input in black, output from Ruby in red:
%(black)[self.class] Object %(black)[def XXXXX; return "5 X'es"; end] nil %(black)[XXXXX] 5 X'es %(black)[self.XXXXX] 5 X'es
So, fine, we have our new method in place and it works. But now try this:
%(black)[Array.new.class] Array %(black)[Array.new.XXXXX] 5 X'es %(black)[Sketchup.active_model.XXXXX] 5 X'es %(black)[Sketchup.active_model.selection.XXXXX] 5 X'es
Huh! Were you aware of that? And was that actually your intention? Depending on the implementation of XXXXX it might even do strange things, when called on an instance of WhatEver (not in our sample, as that simply returns a string object). And that method name is unusual enough to not stump onto anybody's feet too easily.
But assume you have a need for, say, a method returning some identifier and you naturally name it 'id' ... first let's check a little bit, then define our method and recheck (your numbers will be different):
%(black)[id] 108448104 %(black)[self.id] 108448104 %(black)[Sketchup.active_model.id] 115396684 %(black)[def id; return 4711; end] nil %(black)[id] 4711 %(black)[self.id] 4711 %(black)[Sketchup.active_model.id] 4711
Nice, our method works ... but we stumped heavily onto everbodys feet. Try some other object ids you can come up with, all will give 4711. Most probably some loaded Ruby scripts are now broken too, e.g. when they test for equality of object instances with the method 'equal?'. So you better now terminate and restart SketchUp before continuing with serious work!!!
How stupid can one be to redefine/overwrite the 'id' method? OK, nobody, but if everybody just uses 'def' within the scope of the default Object, especially with several plugins already loaded, name me that man knowing all and every method name already in use in some plugin, so that I can ask him for permission to use my personal method name.
A better(?) approach would be to pre/postfix every method (still in Object) with your signature ... good, when you enjoy typing your name often, e.g. def deerwood_id ....
But, if you just have one to five unrelated methods to offer, then maybe a module is appropriate, e.g.
module Whatever
# a module method (note the prefix)
def Whatever.id
return 4711
end
end
and call it then as Whatever.id returning the desired 4711 without affecting others.
But if your plugin is just a little bit more sophisticated and uses different helper methods to implement some complicated feature, then use a class. Instead of writing one several pages long method with many nested loops and if/else statements split the whole behaviour into several instance methods, that call each other.
To be continued ...
best regards, deerwood
Dear Doug,
@doug said:
I have search for a Bill of materials plugin for skecthup 7 basic.
May be the free CutList 4.0 plugin can help you too?
best regards, deerwood
Hi Todd,
@unknownuser said:
This can be done, but it would require a back face culling algorithm. I started such a project a few years ago (to takes the view the camera sees, and create a 2D plane of line work from that view. I had it working, but stopped when I realized I didn't now how to do the back face culling.
Back face culling shouldn't be a big problem, see Wikipedia (de with formula). It reduces to testing the dot product of a face.normal vector and the camera.direction vector beeing + or - . Something like:
if camera.direction.dot(face.normal) > 0
....
However I think the transformations of groups and component instances have to be taken into account, too. Would that motivate you, to continue with your script?
Another problem might be the view frustum culling/clipping ... for a first version I could live without that (e.g. having a rather small model and just moving the camera far enough away to see all of it).
And the last problem I see is the occlusion culling/clipping. Again I would be fine in a first version without that as long as the faces/edges are given out in correct back to front order.
Best regards, deerwood
Dear dmatho/Diego,
thanks for your hints/links. But, as I had written in my initial message, I got (and inspected) these already ... though this plugin comes in handy, to lay out faces ready to be cut by laser, this is not, what I wanna have. And there is some (better?similar) plugin over at lumberjocks.com (or so). That one is excellent (with sophisticated WebDialogs and very good layout on boards etc). But both "miss" my point (they don't miss their point however).
@dmatho said:
I then found somebody has done it for them/us:
My point is, to have a SVG (2D vector format) essentially as seen from the SU camera.
best regards, deerwood
Dear Chris, all,
@chris fullmer said:
The free version does not allow .eps export?
Nope (at least not in SU7), just pixel formats .bmp, .jpg, .tif, .png.
My main target application for SVG will be the OpenSource Inkscape to, for instance, make scalable images for wikipedia. Wikipedia (especially commons) prefers SVG over pixel formats, where appropriate (diagrams, schematics etc.) and has good support (thumbnails and intermediates are automatically converted to pixel images, the final image remains as SVG, open to be modified/extended by others).
Inkscape actually can import .pdf (but not .eps without hassles under XP) and preserves the vector format and e.g. grouping. Tested here with gnuplot generated .pdf files.
Thanks and best regards, deerwood
Thanks Chris, but I forgot to mention, that I use the free version of SU7. Is there, maybe, a Ruby script exporting to some other 2D vector format that could be used as a base for extending/modifying it to export SVG?
@chris fullmer said:
Have you tried the .eps format? It might be what your wanting.
Chris
best regards, deerwood
Dear all,
I'm a newbie regarding Ruby and SketchUp (the API).
I'm surprised that (after googling several days) I could not find any plugin spitting out essentially the same as the built in image exports (*.png/jpg ...) to SVG (Scalable Vector Graphics). A view onto the model, as seen from the camera, not in some (unscalable, not really antialized) pixel format, but instead in a common vector format, scalable and wide spread.
I'm not after exploding/laying out some SU faces/edges optimized e.g. to do woodwork (I got these plugins already) and get a layout/material calculation.
I just want to see my current SU view exported to SVG, respecting as much of the SU settings (e.g. visible layers, hiddden entities etc).
Any hints?
best regards, deerwood