I like what I’m seeing so far. How about text on a path?
Text on a path is a frequent request which hopefully will work its way up to being done — no idea on timeframe.
Until then, you can use F-Engrave or use Inkscape to set the text, convert it to paths, then use Path | Object to Path on a copy of the file to get geometry which you an import into Carbide Create
Can you share the file you’re using?
Just uploaded 428 to https://carbide3d.com/carbidecreate/unstable/
- (NEW) Progress notification for vcarving
- (NEW) Multiple vcarve regions are now calculated in parallel
- (FIX) Time estimate for disabled toolpaths show correctly (Arjan)
- (FIX) More consistent progress updates for toolpath calculations
@fenrus - Your file now calculates in a few seconds.
Thanks, Will. Yes, I’ve used Inkscape. Have experienced stretching issues so have to perfect the object to path size.
Again, great work so far. Seriously considering the subscription.
Update the keyboard shortcut PDF:
yup fix confirmed; thanks for the quick fix
429 is up at https://carbide3d.com/carbidecreate/unstable/
- (NEW) Optimized internals to make dragging many many objects more efficient.
- (FIX) More aggressively try to close SVG paths on open.
CC429: texture tool paths failing to load properly when reopening a file created with CC429. Texture tool path and user inputs are saved properly, but upon reopening the file the tool path displays “Empty Toolpath” in place of the estimated time. I haven’t tried to open a file created by an older version of CC yet to see how it reacts.
edit: all it takes is editing the tool path to get it to load the estimated time again
edit 2: having some trouble with the simulation not loading. It loads for a minute and then displays a blank window. No problem hiding the simulation, doesn’t cause the program to hiccup or close.
Can you post a broken file?
WH40K_IW_Insignia.c2d (443.0 KB)
Just noticed if you go so far as to edit the tool under the texture toolpath, it will reset the feed and plunge to defaults.
Simulation will show toolpaths and rapids if selected, but the “material” does not render.
Edit: No simulation rendering issues when I disable the texture tool path. Makes me think it is a graphics issue on my end as I am using the built in gpu on my Intel Nuci5.
Edit2: Renders with texture fine on 417
I think we found a combination of two things- the texture toolpath wasn’t loading a time estimate and the texture caused too many triangles for some video cards so it may not show a simulation. We’ll get a new build out tomorrow.
Just posted 430 to https://carbide3d.com/carbidecreate/unstable/
- (FIX) Texture toolpath time estimates
- (FIX) Modified simulation resolution
CC 430 - certainly a step back for me. Here is just a new document with a simple “Text” v-carve. It looks awful and has many incorrect artifacts - notice the horizontal lines…
Edit - It only happens with v-carves. I checked a few older documents and all endmill toolpaths etc seem to render fine but all v-carves are horrible
I am using an AMD Radeon R7 200 Series with the latest drivers - which has always been more powerful than I need.
I also notice that I used the default settings for “Text” and it actually placed it somewhere way off the workpiece to the top right - took a while to find it until I zoomed out…
test.c2d (42.9 KB)
The text object when added has always been placed up and to the right of the bottom left of the stock — only an issue when working on really small stock sizes — resetting the view brings it into view.
Ahh yes - Last time I used CC I had an unusually small sized stock - which it remembered for this test,
I also noticed several CC versions ago that the simulation is “hollow” - i.e if you rotate to to see the underside there is no bottom surface rendered.- the workpiece is “hollow” This explains the many white speckles in the screenshot - it is the white background bleeding through the infinitely thin top surface rendering.
431 is up at https://carbide3d.com/carbidecreate/unstable/ with a change to the simulation resolution
thanks @robgrz - better but still not as good as it used to be…
We’re trying to find the happy medium of good-but-not-melting-the-gpu. We’ll keep tweaking.
i understand - its always a compromise.
i suspect if you render the bottom surface then the problem might not be so obvious - worth a try?