michael-f-bryan / arcs Goto Github PK

Thanks for your work on this library, I have been playing around with it and I would like to see it develop further. I was hoping to contribute to it but some guidance would be helpful.

I'm looking to implement a grid, was wondering what your thoughts were regarding how it should be done, should it be another primitive type or should it be described as a window style? Or some other way?

Should this be working now? I'm just getting a black square.

To be a CAD program our WebAssembly demo actually needs to draw things.

There should be a toolbar with buttons to enter specific "drawing modes". When you are in a mode the corresponding button stays pressed (letting the user know which mode they're in) and things like click events get passed to that mode.

For now we'll want to implement a formal mode system, with modes for:

• Drawing points
  • Clicking on the canvas adds a point where the user clicked
• Drawing lines
  • Clicking on the canvas once will set the line's start point
  • Once the start point is selected, moving the mouse around will draw a line from the start point to the cursor which follows the cursor as it moves, providing the user with visual feedback on the line they're in the middle of drawing
  • Clicking again will select the line's end point and add it to the drawing
• Drawing arcs
  • I'm not 100% sure how we want to implement this one

The standard way to implement these modes is with some sort of state machine. I prefer trait objects over enums or strongly typed state machines because they scale more easily and are easier to work with.

pub trait Mode {
  fn on_mouse_down(&mut self, args: MouseDownArgs, world: &mut World) -> Transition { 
    Transition::DoNothing
  }

  fn on_mouse_move(&mut self, args: MouseMoveArgs, world: &mut World) -> Transition { 
    Transition::DoNothing
  }
}

pub enum Transition {
  DoNothing,
  ChangeState(Box<dyn Mode>),
}

(note: this is a big task and will probably require breaking into a dozen smaller issues along the way)

yarn start currently fails. I assume the module is either missing or no longer exists:

error[E0432]: unresolved import `arcs::render`
 --> src/app.rs:6:5
  |
6 |     render::{Renderer, Viewport},
  |     ^^^^^^ could not find `render` in `arcs`

error[E0433]: failed to resolve: could not find `render` in `arcs`
  --> src/app.rs:61:15
   |
61 |         arcs::render::to_drawing_coordinates(
   |               ^^^^^^ could not find `render` in `arcs`

I can't seem to run the example, I get a panic during rendering. This project seems like something i'd like to help contribute to maybe one day. Need to get up to speed with Rust

arcs-master\target\debug\examples> .\render_to_image.exe thread 'main' panicked at 'Render context dropped without finish() call', C:\Users\jasin\.cargo\registry\src\github.com-1ecc6299db9ec823\piet-direct2d-0.1.0\src\lib.rs:475:9

We need to make sure the demo's canvas rendering logic is correct.

A good smoke test would be to:

1. hard-code the viewport to be centred on (0, 0) with a pixels_per_drawing_unit of 1.0
2. Click somewhere on the canvas (note: click location will be in Canvas Space - pixels with the origin in the top-left)
3. In the click handler, add a point to the World at the equivalent spot in Drawing Space (cartesian coordinates who's origin is completely unrelated to the world)
4. Tell the canvas to render again
5. Make sure a dot appeared exactly where the user clicked

Can you add info as to how to download and develop this as local copy?

(Sorry I'm Rust newbie)

So explain what to download, where to place it, what to call (cargo build etc.), how to import.

How does this compare/relate to the FreeCAD project?

This follows on from #9 (comment):

I would like to add to this another mode for selecting or picking already drawn geometry.

This is probably the most used functionality and can probably also be implemented as a mode.

As an algorithm for finding things under the mouse cursor we have the most important thing already, as we can do a quick sort of all DrawingObjects whose BoundingBox contains the MousePosition in WorldSpace and do some fine-grained checks afterwards

We need an interactive mode which lets us mark an object as selected and move them around the drawing by clicking and dragging.

This will necessitate a couple new concepts on top of #9:

• Selected component (see specs::storage::NullStorage)
• The SelectMode itself
• An efficient way to see what is under the cursor

#12 introduced aabb_quadtree as a mechanism for doing lookups based on location (i.e. "which items are within 5mm of P?"), but its API doesn't really line up with how we'd like to use it.

At some point in time we should implement our own quadtree (or N-tree or whatever).

This issue can be used as a list of useful links for implementation, and a wish list based on arcs' needs.

Hey just read the article that was on hacker news, linked to here I think: http://adventures.michaelfbryan.com/posts/ecs-outside-of-games/

Looked at the code, looks like these lines are likely what's slowing things down:

And it looks like this gets used here?

So it looks like that calculate function has a high likelihood of running in the hot loop. Apologies for the questions, I'm not very proficient in rust.

We have some experience with this in our graphics engine (C++). A few suggestions:

• Try to avoid building a render list directly in the hot loop; one way to avoid it is by keeping a render list up to date and in the correct order on the side
  • When it comes time to render, you can go over the list and render in order with no further logic
• Try to keep the render list up to date by updating it whenever a system state change occurs that could impact the list; for example ...
  • items are added/deleted
  • a layer is hidden or made visible
  • z order is updated on an item
• Frequently you can do a synchronous eager update on the list as soon as one of those events occurs; if that's too slow, marking that the list needs to be updated is also an option to defer the update to later
• Adding/removing items is the one thing that you'll generally want to do on the spot (or just before render) in order to deal with dead refs (there are other ways to deal with this as well eg proxy objects)
  • You may want to do performance tuning to see if a vec ie contiguous storage is adequate here or whether enough updates occur per second (or they happen burstily enough) that it warrants using a linked list
  • If you opt for a linked list, you can improve read performance by allocating for the list from an arena style allocator
• Z order updates can be handled without a full list update
  • in house, we deal with it by using partial bubble sort passes
  • so basically each frame, we do a single bubble sort pass (eg iterate once from 0..n and re-order items)
  • this guarantees eventual ordering; this is typically "good enough" as "correct" behaviour is typically exhibited within a few frames

That's most of what comes to mind. Hopefully it helps. Happy to chat further. Cheers!

This line:
max_by_key(rest, |p| line_segment.perpendicular_distance_to(*p))
ultimately calls Vector2D.length() for each point, which takes the square root, an expensive operation. That's not really necessary -- the max of the square will give you the same answer.

You could make square_perpendicular_distance_to() which uses square_length() which uses Vector2D.square_length().

For long lists you could probably do even better by preparing a rotation matrix that would make the line segment horizontal -- then you only need to consider the Y values of the rotated points to see which is farthest from the (horizontal) line.

I made a rough prototype of a possible bezier implementation. Here is the beautified adapted output of the render_to_image example:

From a design standpoint I had the following ideas for implementation:

• Bezier curves can technically have an infinite amount of control points, crates on crates.io I could find only support quadratic and cubic bezier curves. I assume this is modelled after the SVG spec, which only supports cubic and quadratic beziers.
• The rough prototype just implements a generic Bezier struct with 3 control points and an Option for a fourth one
• I would like to abstract away the SVG limitations in our implementation and expose a generic Bezier from an array of Points which we subdivide into quadratic and cubic parts for rendering

Are there any caveats with a generic implementation over an array of Points you can think of @Michael-F-Bryan ?

At the moment we're reimplementing a lot of basic geometry math with Vector and BoundingBox. Is it worth reusing primitive types from an existing geometry library?