Menu

#1 Snapping - Dynamic constrains

open
nobody
None
7
2007-10-11
2007-10-11
No

From the interface point of view, I propose the following for a sketcher (2d). 3d should be discussed separately.

These are the basic snapping requirements in my opinion. Snapping functionality should ergonomically let you choose which of these you want to snap to:

1. vertex

2. line:
2.1 perpendicular
2.2 tangency
2.3 ends
2.4 middle
2.5 near
2.6 intersection

3. virtual lines (extensions of lines)
3.1 virtual intersection
3.2 virtual perpendicularity

4. shapes
4.1 circle center
4.2 circle quadrants
4.3 spline control points

Dynamic constrains are a variant that is quite useful. I allows you to interactively draw a line or curve that follows a parallelism or something and you can change that on the fly.

- Parallelism
- Orthogonal to x and y, or to a prefixed direction
- Angle
- Bisectriz (is that the name in english?)
- Fixed length

Discussion

  • Peter Dolbey

    Peter Dolbey - 2007-10-12

    Logged In: YES
    user_id=3191
    Originator: NO

    Alvaro,

    Do you think it would make sense to turn this feature into 2 separate tasks - one for snapping and one for constraints? That way we might be able allocate them separately to different task leaders.

    Pete

     
  • Álvaro Castro Castilla

    Logged In: YES
    user_id=1906516
    Originator: YES

    Yes, they are separate things conceptually. If we make a kind of "solver" which takes both of them and allows you to use them simultaneously it could be possible. The only requirement is that they can be used simultaneously. For example, use a near point to a line and be simultaneously parallel to other.

    I don't know how difficult is it to make it flexible enough so you can use various snaps simultaneously, plus a constrain. On the other hand, constrains are not only dynamic but they should be stored as perpendicularity, parallelism is saved with the sketch. While on the other hand, real-time snapping is not constrains/snaps it would be drawing-aids/persistent-constrains.

    Which option do you think is best?

    In order to make this useful, we need first a sketcher and some basic drawing functionality...

    A hierarchic organization of the requirements for the software could be useful for this.

     
  • Peter Dolbey

    Peter Dolbey - 2007-10-12

    Logged In: YES
    user_id=3191
    Originator: NO

    I'd like to separate them on the basis of achievability. I think we can implement a snaps model using mostly OpenCascade built in functionality, and it should be a relatively straightfoward excercise.

    Contraint or parametric modelling is a non-trivial task. The OCC Advanced Samples pack has a parameteric OCAF sample, and there's an OCC compatible contraints engine from Ledas (see http://ledas.com/products/integration_module/\) but both of these cost money - which I don't have. So I'd like to consider this to be a longer term goal than snaps. I've joined the Ledas site and I'm down loading their 2/3D examples now - this might give an idea of whats achievable.

    Pete

     
  • Álvaro Castro Castilla

    Logged In: YES
    user_id=1906516
    Originator: YES

    Yes, I agree is a more complicated task. What would be nice is to have it in mind, so the architecture is built thinking in its future extension from snaps to constrains

    Isn't it achievable using the OCAF operations solver? I don't know is just a question...

     
  • Yugami

    Yugami - 2007-10-17

    Logged In: YES
    user_id=1563872
    Originator: NO

    I have the snaps engine just about finished.

    We need to hand draw the pointer to complete it on the application side.

    I'll submit the changes to sourceforge as soon as I clean it up. You guys can comment from there.

    While snaps and contraints go hand in hand I think they are 2 different things conceptually, though it may be possible to reuse some of the snaps code to finish them.

     
  • Peter Dolbey

    Peter Dolbey - 2007-10-17

    Logged In: YES
    user_id=3191
    Originator: NO

    Marc,

    Could you create a new module on the cvsroot of "development", then perhaps put your code into a folder there, for instance "qtoccsnaps" so we can keep the "trunk" module for codesets tested on all platforms.

    Pete

     
  • Stephane Routelous

    Logged In: YES
    user_id=338342
    Originator: NO

    for snapping : it's possible to develop our own AIS_InteractiveObjects and add some extra selection modes (SNAP_XXX) where for those mode, we will create invisible but detectable objects.
    When opening a local context, setting the selection mode to SNAP_XXX, we will be able to select the "snappable" entities.
    same for intersections. we can create a dummy AIS_InteractiveObject containing the intersections of the lines and make them selectable in a local context.

    Stephane

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.