I use Sketchup sometimes for non-professional stuff.
Therefore, I stick to the 2017 Make version with a series of plugins to do what I want to do. Basically, my only 'inconvenience' with this old Make version, and for which I did not find a decent solution via plugins, was the lack of support for importing vector graphics.
On Reddit, I found some 'traces' of a very old plugin to import SVG files (origin 2008, updated in 2013). However, it missed many SVG features. There were also some incompatibilities and dependencies that made it quite complex to install. More recently, Samuel Tallet (author of some great plugins on Sketchucation) removed some of these dependencies, and made it apparently also compatible, up to SU version 2024. But, the old deficiencies in terms of SVG features remained.

Because I had no solution for the import of 2D vector data with my old Sketchup version, I decided - a couple of months ago - to jump into this gap myself (only for personal use). I had to dive into Ruby coding, the Sketchup API and the SVG specifications. Quite an endeavor, but I finally succeeded to come up with something that works... At least for me ...

• I extended the original support for the limited set of SVG shapes (i.e. rectangles, and 'shapes' composed of lines and cubic beziers) to the full set of SVG geometry (i.e. addition of circles, ellipses, horizontal and vertical lines, polylines, polygons, as well as support for elliptical arcs and quadratic beziers, including the smooth variants of cubic and quadratic beziers).
• I added support for all types of transformations (translate, rotate, scale, X- and Y-skew), including combined transforms.
• I added support for fills and line colors in a more robust way.
• I added support for text, although this still faces a number of limitations (as I encounter problems to fully convert some SVG font attributes into equivalent 3D text objects in SU).
• I could substantially improve the import performance, especially for complex SVG files (often from many minutes to just some seconds).

Below are some examples. The first example shows a screenshot of 3 files in my 2D graphics editor (Affinity Designer). Inkscape is a popular - and open source - alternative. Such editors allow to create SVG files, can read multiple vector formats (e.g. DWG, DXF, PDF) and also support the conversion towards SVG.

The first example is a site plan, with lots of text (measurements) and line colors, the second is a garden plan with multiple color-filled shapes, and the last one is a more 'graphical object' (that demonstrates an 'inconsistency' between 2D and 3D design constraints - cf. below).

()

Next, you'll see screenshots of the corresponding SVG imports in Sketchup.

Due to the inherent differences between 2D and 3D modeling approaches, there are some caveats to take into account. The last 2 figures (the dragon) explain this. SVG works with lines and shapes. Lines ('strokes' in SVG) have a thickness. Shapes can be filled with color, but SVG shapes can also be put 'on top' of each other ('layered' and blended, like in a photo editor). However such layering is not possible when converting the 2D drawing into a 3D modeling tool like Sketchup. You'll end up with 'Z-fighting' of different shapes on the ground plane. All lines and shapes are properly imported, but they may overlap, which leads to the 'black dragon'. The overlap between the different shapes can be - manually ! - manipulated by selecting the shape in the outliner and cutting it out of the larger shape. You can 'visualize' the different composing shapes by using the X-Ray mode (cf the second dragon figure). Alternatively, this 'avoidance of shape overlap' can also be performed (and likely more efficiently) in a 2D editor, before exporting it to SVG, and importing it afterwards in Sketchup.

My 'extension' supports colored shape fills and lines, including transparency. Line widths (~edges) are (as always in SU) without stroke thickness.

The (optional) shape fill 'enhancements' in SVG (i.e. gradients, patterns, filters, masks) are, due to the lack of an equivalent, non-rasterized alternative for SU faces, always 'solid colors'.

If any such 'enhancements' would be required, this must be done (manually!!) in Sketchup via the import of bitmap files as material textures, after the SVG file is loaded. However, be aware that the rasterized nature of such textures, nullifies the benefits of the vectorial nature of SVG!!!

The 'extension' supports various color definitions (RGB, 3-digit and 6-digit hex, as well as the W3C color names). As Dan Rathbun pointed out above, this last color coding mechanism may not be supported anymore in SU2025. It should be possible to adapt the extension to translate these color names into equivalent RGB values, but this is currently not implemented, as I don't use SU2025. Thus, I also have no clue what may be the impact of the new PBR materials for my 'SVG Importer'...

As mentioned above, the support for texts is currently not 'perfect', due to inconsistencies between the way the SVG specification allows text formatting and the way SU's 3D text can be manipulated via the Sketchup Ruby API. However, if a 100% accurate import of the text elements (e.g. a detailed font design) is absolutely necessary, this can be achieved by 'translating the text into curves' with a 2D graphical editor. In this case, the text is handled like a regular 'SVG shape'. This will lead to a larger SVG file size. In case of lots of text, it might be easier to create the text directly in SU as well.

There is no documentation available for this 'personal extension'. I'm also not pretending that it is 'professional-grade' software. E.g. the only dialog box (to capture some parameters) is an old-fashioned (ugly) Sketchup UI.Inputbox. I had no need or intention to learn how to code HTML dialog boxes and how they interact with Sketchup...

I don't know your exact needs in terms of SVG import. But, if the above clarification of what I did, looks like a potential match, I have no objection to share it (without any guarrantee and/or liability). If so, please reach out to me via a PM on this forum.

Re: [Plugin][$] JointPushPull Interactive - v4.8a - 30 Mar 24
I have the latest version of this plugin installed. I also have the required versions of LibFredo6 installed. I'm using Sketchup Make 2017.
On regular times, the plugin crashes. An example of the crash report is shown below:

***Date: 20-May-24 13:15:14 - SU2017.2
An error occurred in Joint Push Pull
Error in Analysis of model

wrong number arguments: 4 or 6 required

body_lib6g6.rbe: 3139 -- linear_combination
body_lib6g6.rbe: 3139 -- vector_exact_average
jointpushpullalgo.rbe: 1369 -- joint_compute_direction
jointpushpullalgo.rbe: 1315 -- block in block_prepare_vertices_J
jointpushpullalgo.rbe: 1315 -- each
jointpushpullalgo.rbe: 1315 -- block_prepare_vertices_J
jointpushpullalgo.rbe: 1200 -- block in block_prepare_vertices_all
jointpushpullalgo.rbe: 1200 -- each
jointpushpullalgo.rbe: 1200 -- block_prepare_vertices_all
jointpushpullalgo.rbe: 524 -- algo_prepare_calculation_exec
jointpushpullalgo.rbe: 504 -- algo_prepare_calculation
jointpushpulltool.rbe: 866 -- dragging_start
jointpushpulltool.rbe: 1574 -- onLButtonDown***

As I mentioned, this doesn't occur all the time. However, one process to trigger the error is as follows;

• Start Sketchup with a new file.
• Draw a circle in the origin
• Convert this circle into a cylinder with the standard Sketchup Push/Pull tool.
• Convert the cylinder into a group
• Activate the Joint-Push-Pull methods and try to increase the volume of the cylinder.....
• The error window pops-up...

From time to time, after doing some other actions, the joint push pull starts working again (even with the same cylinder!)
PS1: I also tried to downgrade to an earlier plugin version that I still had available on my system (4.6a). The same issue happens with that version.
PS2: The error happens on my 2 PC's where Sketchup is installed (Windows 10 and Windows 11).

Thanks to verify what' going on. Hopefully a fix can be provided.
In case more information would be required, please don't hesitate to ask.

Isn't triangulation of all faces a native feature when you export your Sketchup model to Collada? Normally, it should be available behind the 'Options...' button in the Sketchup 'Export Model' dialog.
Next, there are indeed separate extensions that offer similar functionality, but these may be beyond your needs. So, best is to start with the out-of-the-box feature, and see how it works for your specific requirements.

I don't understand your dilemma...
I'm also using Sketchup Make 2017.

• I'm not familiar with 'gtlf'. I assume that you mean 'glTF'? I never used this format so far. Do you want to 'import from' or 'export to' this format? I understand that there are extensions that allow the exchange of models (both directions) with Sketchup. Do a search, both in the Extension Warehouse, and on Sketchucation. A good importer (for many formats) is the 'Universal Importer' extension that you can find on Sketchucation. For exports, look at the extension warehouse.
• Running Sketchup Make (2017) on a Windows 11 PC is no problem. I do it on two machines since quite long.
• Open and save Make 2016 files in Make 2017 shouldn't be a problem: Just select 'File|Save As...' in the menu, and select 'Sketchup version 2016 (.skp)*' in the dropdown box that is labeled 'Save as file' at the bottom of the dialog box. Opening a 2016 file in version 2017 is no problem, it works like opening any other SU 2017 file (menu 'File|Open...').
• Your files remain on your computer. Just save them to your harddisk.

@Dan-Rathbun

@Dan-Rathbun said in SVG or other vector file import WITH colors:

The only caveat is that SketchUp does not support some of the gray/grey spellings variants, and may be missing a couple of the more obscure color names.

Dan, thanks to clarify that my Ruby SVG Importer will also work with SU2025.
W.r.t. the spelling variants and missing names, my current plugin handles this already, based on your highly appreciated advise (couple of months ago in a thread on the Sketchup forum) .

As said in my previous post, I'm still facing some problems with text in my plugin.

I'll try to explain:
In my plugin, I translate SVG graphical information into Sketchup geometry on the ground plane (Z = 0).
W.r.t. text elements, I convert the 2D SVG text into (flat) 3D text objects in Sketchup. In SVG, the (Y-)position of (horizontal) text is based on the 'baseline' of the text. This baseline is a virtual horizontal line on which most characters 'sit'.
However, in SVG it's also possible to differentiate the position and look and feel (color, size, ...) of indiviual characters in a text string. This can be accomplished e.g. with a 'tspan' SVG element.
In such cases with specific settings for individual characters, these characters translate into separate SVG (sub)entities ('text' or 'tspan'), which in turn convert into multiple Sketchup 3D-text objects (subgroups of the main text group).

To clarify my problem, in the figure below (screenshot of my 2D editor), I show 2 SVG textstrings, composed of the first 7 characters of the alphabet ('a' to 'g'). For the first string (on top) all characters have the same characteristics, and thus create a single object. In the second textstring (at the bottom), the 'd' has a blue color, and the 'g' has a red color. This splits this textstring into 4 substrings ('abc', 'd', 'ef', and 'g').

The screenshot below shows the result after importing this SVG file in Sketchup
The first string translates into 1 Sketchup 3D-text object, and is OK. However, in the second string with 4 substrings, there is a problem with the vertical alignment of the red 'g'.

Apparently in Sketchup, the vertical position of the 3D text object is not based on the Y-position of the font baseline, but it seems to take the lowest bottom of all characters in each text (sub)string as the baseline. This 'bottom' can be above the baseline (e.g. "-=°~") or below the baseline (e.g. "gpq"). If the bottom of a substring lies above the font baseline, all characters in the substring are pushed downwards (to align with the baseline). Similarly, characters belonging to a substring with a bottom below the font baseline are pushed upwards (cf. the red "g" in the figure above).

Therefore, it looks to me as if it is impossible to vertically align multiple 3D-text objects in Sketchup so that these objects join a common baseline?

Is there any source of information on how I can fix this (via the Ruby API of course)? I've searched already extensively, but couldn't find anything. It looks to me as a 'bug' in Sketchup, or at least as an ommission with the implementation of 3D texts.
Any suggestions or help would be greatly appreciated.

I use Sketchup sometimes for non-professional stuff.
Therefore, I stick to the 2017 Make version with a series of plugins to do what I want to do. Basically, my only 'inconvenience' with this old Make version, and for which I did not find a decent solution via plugins, was the lack of support for importing vector graphics.
On Reddit, I found some 'traces' of a very old plugin to import SVG files (origin 2008, updated in 2013). However, it missed many SVG features. There were also some incompatibilities and dependencies that made it quite complex to install. More recently, Samuel Tallet (author of some great plugins on Sketchucation) removed some of these dependencies, and made it apparently also compatible, up to SU version 2024. But, the old deficiencies in terms of SVG features remained.

Because I had no solution for the import of 2D vector data with my old Sketchup version, I decided - a couple of months ago - to jump into this gap myself (only for personal use). I had to dive into Ruby coding, the Sketchup API and the SVG specifications. Quite an endeavor, but I finally succeeded to come up with something that works... At least for me ...

• I extended the original support for the limited set of SVG shapes (i.e. rectangles, and 'shapes' composed of lines and cubic beziers) to the full set of SVG geometry (i.e. addition of circles, ellipses, horizontal and vertical lines, polylines, polygons, as well as support for elliptical arcs and quadratic beziers, including the smooth variants of cubic and quadratic beziers).
• I added support for all types of transformations (translate, rotate, scale, X- and Y-skew), including combined transforms.
• I added support for fills and line colors in a more robust way.
• I added support for text, although this still faces a number of limitations (as I encounter problems to fully convert some SVG font attributes into equivalent 3D text objects in SU).
• I could substantially improve the import performance, especially for complex SVG files (often from many minutes to just some seconds).

Below are some examples. The first example shows a screenshot of 3 files in my 2D graphics editor (Affinity Designer). Inkscape is a popular - and open source - alternative. Such editors allow to create SVG files, can read multiple vector formats (e.g. DWG, DXF, PDF) and also support the conversion towards SVG.

The first example is a site plan, with lots of text (measurements) and line colors, the second is a garden plan with multiple color-filled shapes, and the last one is a more 'graphical object' (that demonstrates an 'inconsistency' between 2D and 3D design constraints - cf. below).

()

Next, you'll see screenshots of the corresponding SVG imports in Sketchup.

Due to the inherent differences between 2D and 3D modeling approaches, there are some caveats to take into account. The last 2 figures (the dragon) explain this. SVG works with lines and shapes. Lines ('strokes' in SVG) have a thickness. Shapes can be filled with color, but SVG shapes can also be put 'on top' of each other ('layered' and blended, like in a photo editor). However such layering is not possible when converting the 2D drawing into a 3D modeling tool like Sketchup. You'll end up with 'Z-fighting' of different shapes on the ground plane. All lines and shapes are properly imported, but they may overlap, which leads to the 'black dragon'. The overlap between the different shapes can be - manually ! - manipulated by selecting the shape in the outliner and cutting it out of the larger shape. You can 'visualize' the different composing shapes by using the X-Ray mode (cf the second dragon figure). Alternatively, this 'avoidance of shape overlap' can also be performed (and likely more efficiently) in a 2D editor, before exporting it to SVG, and importing it afterwards in Sketchup.

My 'extension' supports colored shape fills and lines, including transparency. Line widths (~edges) are (as always in SU) without stroke thickness.

The (optional) shape fill 'enhancements' in SVG (i.e. gradients, patterns, filters, masks) are, due to the lack of an equivalent, non-rasterized alternative for SU faces, always 'solid colors'.

If any such 'enhancements' would be required, this must be done (manually!!) in Sketchup via the import of bitmap files as material textures, after the SVG file is loaded. However, be aware that the rasterized nature of such textures, nullifies the benefits of the vectorial nature of SVG!!!

The 'extension' supports various color definitions (RGB, 3-digit and 6-digit hex, as well as the W3C color names). As Dan Rathbun pointed out above, this last color coding mechanism may not be supported anymore in SU2025. It should be possible to adapt the extension to translate these color names into equivalent RGB values, but this is currently not implemented, as I don't use SU2025. Thus, I also have no clue what may be the impact of the new PBR materials for my 'SVG Importer'...

As mentioned above, the support for texts is currently not 'perfect', due to inconsistencies between the way the SVG specification allows text formatting and the way SU's 3D text can be manipulated via the Sketchup Ruby API. However, if a 100% accurate import of the text elements (e.g. a detailed font design) is absolutely necessary, this can be achieved by 'translating the text into curves' with a 2D graphical editor. In this case, the text is handled like a regular 'SVG shape'. This will lead to a larger SVG file size. In case of lots of text, it might be easier to create the text directly in SU as well.

There is no documentation available for this 'personal extension'. I'm also not pretending that it is 'professional-grade' software. E.g. the only dialog box (to capture some parameters) is an old-fashioned (ugly) Sketchup UI.Inputbox. I had no need or intention to learn how to code HTML dialog boxes and how they interact with Sketchup...

I don't know your exact needs in terms of SVG import. But, if the above clarification of what I did, looks like a potential match, I have no objection to share it (without any guarrantee and/or liability). If so, please reach out to me via a PM on this forum.

Just a quick update on my previous message:

After struggling with this 'bug' on my main desktop, I tried to install the ThruPaint extension also on my tablet PC. On that machine, the extension did not have the problem of the missing material browser.

I then decided to completely shut down the desktop PC and restart it (so, not just quiting Sketchup and relaunching the application).
Bizar, but then the ThruPaint extension worked again, including showing the material browser part.

So, please disregard my previous message!!!
This problem thus 'disappeared' without understanding why it happened in the first place, and how it was 'mysteriously solved'.

However, there is something else now that bothers me: When I select a material in the ThruPaint material browser, this selected material also becomes 'active' in the large material box on the upperleft side of the material browser. However, once I move the mouse beyond the borders of the ThruPaint dialog box, the material in the upperleft box always returns to the 'default' material (see: green box in image below).

I would expect that the selected material in the browser (red box in figure below) would remain 'active' in the upperleft material box when painting faces, edges or objects in the Sketchup viewport. From what I remember, I believe that this was the behaviour in the past, but it's no longer the case now. I'm also not sure whether my memory is right...

Currently, with the default material always shown in this upperleft box once the mouse is no longer over the dialog box, I don't see much value for this box, and it's also quite difficult to know what is the active/selected material that is being used for painting.

Can you please let me know whether the behaviour as described above is intentional of whether it is an 'error'?

Basically, this question relates to the meaning/purpose of the different material boxes shown in the UI while painting (see figure below).

• The red box (with the red material) is the one that is selected for painting.
• The green box (with the 'default' material once the mouse is no longer hovering the dialog box),
• The blue box is linked with the mouse cursor (and also shows the default material...),
• The black box (also with the default material) is shown as long as the ThruPaint extension is active).

Three boxes, all with the default material, while another material is selected for painting: in all honesty, the logic behind this escapes me a bit... But, probably, I miss something fundamental in my understanding of how this extension is intended to be used?

Furthermore, in case of a long list of materials in the material browser, the material that is actually selected may be hidden because it's not in the visible area, based on the position of the scroll bar.

I've searched online for documentation that helps explaining this, but I've not been able to find an answer.

I would really appreciate if somebody could shine a light on this in order to help me understand the use of this otherwise marvellous extension better.

I bought a license for ThruPaint 2.8a (latest version). I also have the latest version of LibFredo installed. I'm using Sketchup 2017 Make.

While ThruPaint was not yet a licensed product, I also used it sometimes, and it worked without any problems for me.

Since I installed the licensed version, I'm facing problems that make the product almost 'useless'. Indeed, the material browser part of the dialog window is always 'empty', so there is no way to select a material to paint with. I've tried many combinations of default parameter settings to see whether it made any difference, but it doesn't. The 'material browser' part of the dialog remains empty. I've also restarted Sketchup, and I uninstalled and reinstalled the extension, but it doesn't make any difference.

To clarify what I mean, I include the screenshot below.
It shows that there are many materials in my model (see the standard material box in the Sketchup tray on the right hand side of the screen (blue rounded rectangle). However, when I select the 'In Model' entry in the dropdown box of the ThruPaint dialog, nothing is shown (red rounded rectangle). Switching between face, edge or object painting also makes no difference. Selecting other entries in the dropdown box of the ThruPaint dialog (e.g. RAL Classic) doesn't show any materials under the dropdown bo neither.

Thanks to let me know how I can make the 'material browser' visible again.

@fredo6
Thanks a lot for the fast reply and solution.
Just installed the update and tested it. It works!
Up and running again.

Re: [Plugin][$] JointPushPull Interactive - v4.8a - 30 Mar 24
I have the latest version of this plugin installed. I also have the required versions of LibFredo6 installed. I'm using Sketchup Make 2017.
On regular times, the plugin crashes. An example of the crash report is shown below:

***Date: 20-May-24 13:15:14 - SU2017.2
An error occurred in Joint Push Pull
Error in Analysis of model

wrong number arguments: 4 or 6 required

body_lib6g6.rbe: 3139 -- linear_combination
body_lib6g6.rbe: 3139 -- vector_exact_average
jointpushpullalgo.rbe: 1369 -- joint_compute_direction
jointpushpullalgo.rbe: 1315 -- block in block_prepare_vertices_J
jointpushpullalgo.rbe: 1315 -- each
jointpushpullalgo.rbe: 1315 -- block_prepare_vertices_J
jointpushpullalgo.rbe: 1200 -- block in block_prepare_vertices_all
jointpushpullalgo.rbe: 1200 -- each
jointpushpullalgo.rbe: 1200 -- block_prepare_vertices_all
jointpushpullalgo.rbe: 524 -- algo_prepare_calculation_exec
jointpushpullalgo.rbe: 504 -- algo_prepare_calculation
jointpushpulltool.rbe: 866 -- dragging_start
jointpushpulltool.rbe: 1574 -- onLButtonDown***

As I mentioned, this doesn't occur all the time. However, one process to trigger the error is as follows;

• Start Sketchup with a new file.
• Draw a circle in the origin
• Convert this circle into a cylinder with the standard Sketchup Push/Pull tool.
• Convert the cylinder into a group
• Activate the Joint-Push-Pull methods and try to increase the volume of the cylinder.....
• The error window pops-up...

From time to time, after doing some other actions, the joint push pull starts working again (even with the same cylinder!)
PS1: I also tried to downgrade to an earlier plugin version that I still had available on my system (4.6a). The same issue happens with that version.
PS2: The error happens on my 2 PC's where Sketchup is installed (Windows 10 and Windows 11).

Thanks to verify what' going on. Hopefully a fix can be provided.
In case more information would be required, please don't hesitate to ask.

Hello, it appears to me that this plugin 'toggles' between two states ('far' and 'near'). However, there is nowhere a visual clue about the actual state of the viewport.

Therefore, I have a suggestion/request:
Wouldn't it be possible to differentiate between the 'near' and 'far' status? This would be very helpful, I believe.

The differentiation should be made visible, both in the menu system and via the icon in the toolbar.
I assume that the 'far' status will be the 'default' one. If a user wants to switch to 'near', this can be done, either via clicking the toolbar icon, as well as by checking the 'Clipping Fix' entry in the Camera menu. The menu entry should then be preceded with a checkbox, while the toolbar icon could e.g. change or show a 'pressed icon'.
Obviously, both visual clues (i.e. checkbox in menu and icon in toolbar) should remain 'in sync' at all times.

Thanks to consider this request/suggestion.
Kind regards.

Just a quick update. As suggested, I contacted the author of the extension.
He informed me that the selection of the pins (in order to compress them with the Gizmo) requires that the simulation is running. Actually, this was the solution for my problem!
May be relevant if other users would face the same problem.