LDraw.org Discussion Forums
2D (ortho) editing - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: LDraw Programs (https://forums.ldraw.org/forum-7.html)
+--- Forum: LDraw Editors and Viewers (https://forums.ldraw.org/forum-11.html)
+--- Thread: 2D (ortho) editing (/thread-4690.html)

Pages: 1 2 3


Re: 2D (ortho) editing - Roland Melkert - 2012-05-04

Tim Gould Wrote: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.

Philippe \Philo\" Hurbain Wrote: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.

Philippe \Philo\" Hurbain Wrote: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.

Philippe \Philo\" Hurbain Wrote: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.

Philippe \Philo\" Hurbain Wrote: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.


Re: 2D (ortho) editing - Roland Melkert - 2012-05-04

Steffen Wrote: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.


Re: 2D (ortho) editing - Travis Cobbs - 2012-05-04

Roland Melkert Wrote:
Philippe \Philo\" Hurbain Wrote: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.


Re: 2D (ortho) editing - Travis Cobbs - 2012-05-04

Roland Melkert Wrote: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.


Re: 2D (ortho) editing - Roland Melkert - 2012-05-04

Travis Cobbs Wrote: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 Smile faster then (classic) selection buffer tests.


Re: 2D (ortho) editing - Travis Cobbs - 2012-05-04

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.


Re: 2D (ortho) editing - Roland Melkert - 2012-05-04

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 Smile


Re: 2D (ortho) editing - Tim Gould - 2012-05-04

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 Smile

Tim


Re: 2D (ortho) editing - Travis Cobbs - 2012-05-05

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.


Re: 2D (ortho) editing - Roland Melkert - 2012-05-06

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.