2D (ortho) editing

[Roland Melkert]

Hi all, I've been working on LDCad's 2D (Ortho) editing mode on and off lately, and I'm almost ready with the basic view handling. Next on the to do list is to put in special editing tools for that mode.

I already have some ideas, but at this stage I could still implement something completely different if brought to my attention.

For starters it will have mlcad's way of selection handling (always in front rectangle), everything else is still open to suggestions.

So I was wondering if anyone else has some pointers/ideas concerning working in 2D mode? Especially from the people saying they hate 'those 3D only editors'

[Tim Gould]

I hate 3D only editors

I think you could go beyond MLCAD so that one-click = front, two-clicks (slow,not double) = second etc. That would be a big plus. Other than that I think MLCAD handles it pretty well, so copying would definitely be great.

With 2D editing I'll give LDCAD a proper try

If I could have something with MLCADs editing (or better) and a better part selection process I would be a very happy man.

Tim

[Roland Melkert]

I think you could go beyond MLCAD so that one-click = front, two-clicks (slow,not double) = second etc.

You mean for switching the view in a single window?

In the current dev version any editing view can switch between 2d and 3d at any time and the current editing plane (xy/xz/yz) determines the 'ortho' side in 2D, which you can also change by using the compass (e.g. for top view -> x up, x down, z up, z down).

Quick changes between the planes is also controled by keyboard (just like in the current 1.0) using:

[ s ]ides (yz)
[ t ]op/bottom (xz)
[ f ]ront/back (xy)

Where in ortho mode the last used orientation of the chosen plane will be restored.

(tmp) Switching from split windows to a fullwindow version of the current view will also be possible using the spacebar.

edit: fixed bb code issue

[Tim Gould]

No. I mean one-click selects frontmost piece (like MLCAD), second click selects the one behind it, etc. To do this in MLCAD you have to click, hide, click, hide etc. until you find the part you want.

Tim

[Philippe Hurbain]

No. I mean one-click selects frontmost piece (like MLCAD), second click selects the one behind it, etc. To do this in MLCAD you have to click, hide, click, hide etc. until you find the part you want.

I have an electronics cad program that uses tab key to cycle through the possibly selected elements after a selection click. Pretty convenient.

More or less related, something I often miss in MLCad is the possibility to "laser select" everything in the selection area (visible or hidden by other elements).

There are also two possible modes in area selection, either select all elements touching the selection area, or select only elements entirely inside selection area. Both modes may be interesting depending on context.

Now if several modes are implemented, remains the problem of convenient mode selection...

And the BIG question for me: Roland, do you intend at some time to add part editing possibilities to LDCad? I understand that this is not a top priority now, but I'd be happy to use a more modern tool than MLCad

[Willy Tschager]

I also hate 3D-only editors ;-) Since Tim and Philo already asked for the features I seek most the only think left is:

* If you're going to add a 4 pane 2D view GUI (kind of front, left, top, 3D) I'd like to have the possibility to select also in the 3D window.
* Select in the different ortho pans + the 3D pane.
* Select various parts and then invert the selection.
* Select by type AND color. Say all BLUE Bricks 1x2.
* Select by official/unofficial.
* Select by Category (first name in the parts title). Say all WINDSHIELDS

w.

[Philippe Hurbain]

I also hate 3D-only editors ;-)

I hate much more a 2D-only editor!!! eg. MLCad where you can't do anything in 3D view except get a very poor quality, undecipherable preview with silly auto-scaling!

I'd like to have the possibility to select also in the 3D window.

...otherwise it would become a 2D-only editor... (see my rant just above

[Steffen]

> I hate much more a 2D-only editor!!!
> eg. MLCad where you can't do anything in 3D view except get a very poor quality, undecipherable preview with silly auto-scaling!

same here

[Roland Melkert]

If you're going to add a 4 pane 2D view GUI (kind of front, left, top, 3D) I'd like to have the possibility to select also in the 3D window.
* Select in the different ortho pans + the 3D pane.

Selection/editing handling in a 3D window will retain the same (and more) possibilities as the current online 1.0 version has in it's single view. You gain the 'old school' ortho behavior by splitting the view and setting the extra ones to 2D mode (or set the single on to 2D). There's also no real limit to the number of times you split the window, so if your screen is big enough you could have 16 views All of those follow the current selection and could be used to manipulate the selection and or model.

* Select various parts and then invert the selection.
* Select by type AND color. Say all BLUE Bricks 1x2.
* Select by official/unofficial.
* Select by Category (first name in the parts title). Say all WINDSHIELDS

Inversion and selection by part or color is already possible in 1.0, but I like the other suggestions too so I'm thinking some kind of selection filter dialog so you can make up your own rules.

undecipherable preview with silly auto-scaling!

Actually proper auto scaling (to fit) is a tough thing to implement, I redid my scaling code in LDCad about 3 times now and it's still not perfect (as a result of boundingbox deadspace ). But I agree scaling should only be upon request or after the first load.

[Steffen]

> But I agree scaling should only be upon request or after the first load.

Definetely. Otherwise, as a user, you carefully position the object for your inspection,
and BLAM! - the tool "knows it better"...
I sometimes would even like to be able to have 2 or 3 3D views from different angles onto an object
at the same time.

[Roland Melkert]

No. I mean one-click selects frontmost piece (like MLCAD), second click selects the one behind it, etc. To do this in MLCAD you have to click, hide, click, hide etc. until you find the part you want.

Ah I see how that could be useful, but how to join this with normal selection behavior? There a second click is deselect or multi select when ctrl is hold.

I have an electronics cad program that uses tab key to cycle through the possibly selected elements after a selection click.

I like using the tab more, only thing is how to handle (the current) multi selection in such a case.

the possibility to "laser select" everything in the selection area (visible or hidden by other elements).

Laser selection would be cool, and relatively easy to implement cause the 'hit test' code already knows all parts 'below' the mouse in order to calculate the nearest one.

Area selection is something on my to do list, but I'm not jet sure how to do that efficiently.

Now if several modes are implemented, remains the problem of convenient mode selection.

I'm trying to avoid mode selection and having everything context depended, but when it becomes really necessary I'll probably put control for it in the editing compass.

And the BIG question for me: Roland, do you intend at some time to add part editing possibilities to LDCad? I understand that this is not a top priority now

At some point I would like to make it part editing aware, but I think a part editor inherently needs to get it's basic (thus model) editing functionality in order. It also will need interaction with 2..5 lines, something the current version lacks entirely. But the 'next next' version will probably get a file line listing panel/dialog so that might be a step towards being a part editor.

[Roland Melkert]

I sometimes would even like to be able to have 2 or 3 3D views from different angles onto an object
at the same time.

This will be possible, cause the split views can be set independently to 2 or 3D projection. So you could also use 2 or 4 3D ones if you don't like ortho editing at all. In such a setup you could still use the same ortho approach of editing though, like one view for xy movements, one for xz etc, so you don't have to change the editing plane all the time.

[Travis Cobbs]

the possibility to "laser select" everything in the selection area (visible or hidden by other elements).

Laser selection would be cool, and relatively easy to implement cause the 'hit test' code already knows all parts 'below' the mouse in order to calculate the nearest one.

I don't know how you're doing selection, but if you're using OpenGL's select buffers, then the above is only true if you disable depth testing during the select operation. Otherwise, if the frontmost part is drawn first, parts behind it won't make it into the select buffer. If you have your own custom hit testing, this obviously wouldn't be the case.

[Travis Cobbs]

Actually proper auto scaling (to fit) is a tough thing to implement, I redid my scaling code in LDCad about 3 times now and it's still not perfect (as a result of boundingbox deadspace ). But I agree scaling should only be upon request or after the first load.

Zoom to Fit in LDView is incredibly complicated. And the code that does the heavy math actually came from Lars Hassing. It's also relatively slow. (On a big model, there is a noticeable delay between the time you do Zoom to Fit, and the time it actually finishes.) But LDView uses all part geometry for its zoom to fit, not just part bounding boxes, and just using the bounding boxes would speed it up dramatically. For most parts, the bounding box is "close enough" to not have a bad negative impact on a zoom to fit. I think doing zoom to fit on an orthographic 3D view would be a lot easier.

[Roland Melkert]

I don't know how you're doing selection, but if you're using OpenGL's select buffers, then the above is only true if you disable depth testing during the select operation. Otherwise, if the frontmost part is drawn first, parts behind it won't make it into the select buffer. If you have your own custom hit testing, this obviously wouldn't be the case.

I don't use OpenGL's select buffers, last time I tried that it was ridiculously slow. I take the unprojected far/near line at the mouse cursor and check all mesh data using line/triangle intersection tests (after discarding big chunks using bounding boxes). This method is (surprisingly) much much much faster then (classic) selection buffer tests.

[Travis Cobbs]

Interesting. While I know how it works, I've never actually used OpenGL selection. I guess I'm not surprised that it's slow. The one time I needed to do selection in an OpenGL app, it was an iOS app, and OpenGL ES doesn't have selection. I just had it draw the whole scene using object IDs as colors, then checked the color at the touch point. (For obvious reasons, I never showed the user the drawing used for selection.) I may at some point in the future investigate your method, since I expect it would still be faster just because of the bounding box tests.

[Roland Melkert]

Yes finding the balance between speed and quality is a pain indeed. I haven't really tried to do mesh data fitting yet out of performance fear. Maybe I'll add a 'hq' mode some day using threading.

Ortho fit still needs boundary info from a boundingbox (in my setup), after that it's just the min max after the modelview transformation so no fiddling with frustum fitting there

[Tim Gould]

I've had a suspicion for a while that you could improve a global bounding 'box' if you tried looking for a box, and an ellipsoid that fit the model. You then choose the one with the smallest volume.

With an ellipsoid you can center it nicely. Simply find x^2, y^2, z^2 for each point based on a crude center (eg. that of the box) and you can then minimize

(3V/4pi)^2=(max(x^2-2x xb+xb^2) + max(y^2-2y yb+yb^2) + max(z^2-2z zb+zb^2))^3

according to xb, yb and zb to find a better center.

Not suggesting you should try it, but it's food for thought if you're in the mood

Tim

[Travis Cobbs]

For reference, LDView's default zoom level is calculated based on a minimally sized sphere around the center of the model's bounding box. The default zoom level puts the edge of that sphere at either the top/bottom or the left/right edges of the window (or both if the window is square). This has the effect in LDView of making it so that no matter what model you load, if you rotate it without zooming, it will always be fully visible, while at the same time being as large as possible while satisfying this constraint.

LDView's Zoom to Fit, on the other hand, adjusts the view frustum (pyramid) until at least two of the edges touch the model, while the other two edges are equidistance from those edges of the model.

[Roland Melkert]

Thanks for the insight Tim and Travis,

My current code isn't that math oriented at the moment, because of the frequency it might be called at (bin browsing etc) it needs to stay relatively simple.

It basically only calculates the optimal 'eye.z' position (in modelview space) from each bounding box corner and takes the one closest to the viewer for a final negative translate in the modelview matrix.

This method should be somewhat better then the one currently used in 1.0 though.

[Roland Melkert]

Ok, another semi related opinion poll...

When changing the 'selection center' (aka rotation center) in a current selection, should it reset back to the main part center for the next selection (a deselect in between) or should it live on for ever (or at least while the application runs).

Cause this kinda bugged me in mlcad (sometimes you moved it by mistake, without even noticing).

But it also might be irritating when it resets unwanted all the time as well. I would like to make this somewhat smart without resorting to jet another option, any ideas?