Load vectors at origin

[cojarbi]

If we are loading raster at origin, wont it make sense to load vectors also? Currently vector are loaded based on the location it was when created

[tbfleming]

That will ruin the ability to split a design across multiple vector files and have them align with each other without having to tweak the positions after loading.

[cojarbi]

So It would pull all vectors in the artboard to the origin?

⁣Ariel Yahni​

On Feb 23, 2017, 21:05, at 21:05, Todd Fleming notifications@github.com wrote:

That will ruin the ability to split a design across multiple vector files and have them align with each other without having to tweak the positions after loading.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/LaserWeb/LaserWeb4/issues/171#issuecomment-282182516

[tbfleming]

Right now it does its best to preserve vector locations at their Cartesian locations. This was a lot of work to get right; SVG made it a pain. jscut didn't jump though the hoops to make that work and people complained. If someone puts the corner of a vector object at 10mm, 20mm in the SVG document, they expect it to end up at 10mm, 20mm after loading into LW4.

[cojarbi]

ok i get that, but then the user places his material at 0,0. Do most users usually start from a corner or somewhere in the middle of the material? Or most users have their location marked on their wasteboard or similar and place the material origin based on where they have placed in the design software?

This are just question on most common case, im not implying i know the answer

[tbfleming]

I don't know about laser people, but most mill people place 0,0 at a reference spot on their stock then set the machine's WCS to match.

[cojarbi]

And the reason behind this is to leave/have  a margin for the tool?

⁣Ariel Yahni​

On Feb 23, 2017, 21:48, at 21:48, Todd Fleming notifications@github.com wrote:

I don't know about laser people, but most mill people place 0,0 at a reference spot on their stock then set the machine's WCS to match.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/LaserWeb/LaserWeb4/issues/171#issuecomment-282188923

[tbfleming]

Mill people sometimes have to mill an existing object or mill multiple sides of an object. They set up their drawings so 0,0 is a convenient measuring spot, sometimes nowhere near any vectors. This will fall apart if LW4 changes the coordinates. It's not related to margins.

[ghost]

In LW1 I bled a lot of tears and frustration to get that to work right, especially with SVGs. And worse when you resize because threejs used the center of the object's bounding box as a 0,0,0 - so when you resize, the left/bottom sides of the bounding box changed so you had to keep recalculating position as "difference between center and edge + offset moved)

It was very tough to make it work. I almost considered taking the easy eay out telling users to make sure it is at 0,0 in their CAD.

But the incredible growth of LW is and has always been that it "hides" the hard to understand cnc component, and does some assumptions on behalf of the users as a kickoff

This was less about addressing the origin, that rather just pulling a bounding box around a new file when its opened, and then positioning that bounding box's edges on bottom/left or top/left (we only had two 'image positions' in LW1-2-3)

https://github.com/LaserWeb/LaserWeb3/wiki/Settings:--Image-Position outlines the fuctional reasons

The typical laser workflow is to not care about the file (unlike CNC people, laser people grab files from repos, and anywhere else, with god knows where origins) and drop it in. Have some reference corner. Position stock at that corner. Move object in LW to where it should be based off the 0x0 corner If its a reused stock, or irregular shaped stock they jog to a 0,0 in real life, then zero out the axis

So while I do hear you on the center point for the origin in milling, the way our grid looks now, 99.9" of users will mentally consider only the first positive cartesian quadrant as a working area

[ghost]

Because we did the BB around the actual geometry in the file, it also automatically "trimmed" off any dead whitespace that a user may not understand where its coming from if the whitespace is the distance between origin and geometry

[ghost]

(; PS when Cojarbi complains we really should listen. He was the FIRST EVER laserweb user 14 months ago. He's probably the only other person (other than me) that knows the history of why certain things were done the way they were done.

I can go and find the old open issues of users complaining LW didnt load their file, when it fact it did but geometry was somewhere in the 3rd cartesian quadrant (-x,-y ) and thus not shown on screen as we focus the camera over (x+,y+) after which i coded in the setAtZero functions

[ghost]

https://plus.google.com/+PetervanderWalt/posts/Fp26TqdJzFH for example. As his role of Master Beta tester his was very instrumental in testing LW long before I even had a laser machine of any kind. I coded, he tested on real hardware. Thats how LW was born. Every day that was our workflow, across the ocean and across timezones

[ghost]

Found an even older one! https://plus.google.com/+ArielYahni/posts/3GMYsfp2AVN (31 DEC 2015! Beat THAT (:

[ghost]

(: Also dug out the history. that was added https://github.com/LaserWeb/deprecated-LaserWeb2/commit/b61617b91703f0dbb8437c57420c9f0ab6a88d89 in laserweb2 days (:

Note my happy exclamation in the commit message "Scaling, offset working for DXF and SVG! - now also doesnt go into any negative coordinates!"

[tbfleming]

@openhardwarecoza so you say we should trim off the whitespace like LW3 does and throw out viewBox handling? jscut trims vertical whitespace and people complain about the coordinates changing.

[jorgerobles]

I also prefer to keep the viewBox, and then get a Trim/Pack button for such operations,

[ghost]

Agreed, default to viewBox but offer users a "move to origin" sort of button sounds best

[cprezzi]

I think we have a little inconsistency in the system.

In setup we define machine size which is represented by the workspace dimensions, but the workspace zero point is related to work coordinates, not machine coordinates. If I zero WCO somewhere in my work area, the availabe workspace is smaller than the visible workspace.

I belief its fine that the background raster represents the machine size, but it would help if we shift the origin to the work offset and let the user decide where he wants to place the work origin in the view. This could probably also satisfy milling pro's.

[cprezzi]

I hope you understand what I mean ;)

[jorgerobles]

Yes I do

We need to move the axis coordinates upon G92, graying the rest workspace.

[cprezzi]

It would be nice if the user could switch between preset views (like machine space or zoomed to objects) + move and zoom the space himself. The location of the coordinate origin doesn't have to be bound to a corner.

[cprezzi]

@jorgerobles I think it's enough to shift the origin (axis) and fix the available space to the machine settings. Graying out some space is not needed. It should be possible that a gcode has the origin in the middle and also work in negative space (for milling pro's), but I don't know how this could be solved in CAM.

[jorgerobles]

@cprezzi What do you think? I've managed to style up the spacing wires, and used an offset to the text grid. That should be loaded upon G92 X0Y0 command (maybe Set Zero grid, or a setting with the coordinates offset.) @tbfleming will be cool to place some kind of mark, bullseye or so to mark Zero

Also, I would like to change the colors to light blue, but that should be consensed.

[jorgerobles]

@cprezzi Some progress, we have a crosshair! Not commited yet. It depends on a machineOriginX and machineOriginY

[cprezzi]

Wouldn't it be better to have the red and green axis through the origin?

[jorgerobles]

Can do that! :) Do we keep the blue square?

[jorgerobles]

@cojarbi Wondering what vectors should be moved to origin? Only top level ones should be moved to, if not would be a mess, isn't it?

[cojarbi]

Vectors and rasters should default to 0,0 ( the complete boundary ) instead of the current saved location on the illustration software. So the whole thing just moved into that location

[tbfleming]

Not default to. I thought there was going to be a button to move them.

[jorgerobles]

Yes, a button or setting will be if achieved

[cojarbi]

Yes a button