Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable construction geometry #1553

Open
Tracked by #1548
Irev-Dev opened this issue Feb 27, 2024 · 14 comments
Open
Tracked by #1548

Enable construction geometry #1553

Irev-Dev opened this issue Feb 27, 2024 · 14 comments
Assignees
Labels
engine kcl Language and compiler features

Comments

@Irev-Dev
Copy link
Collaborator

Irev-Dev commented Feb 27, 2024

Being able to add geometry that's not officially part of a profile can be really useful, especially with constraints because it will allow a user to define a circle ahead of time, than have a line segment snap to it and follow the arc afterwards or similar.

I'm not certain of the API, but I think so that we can use the same stb function calls maybe we just do

startSketchOn('XY')
  |> startProfileAt()
  |> line()
  |> line()
  |> construction(circle())
  |> line()
  |> construction(line({from:[], to:[]}))

which will also allow for construction geometry to be sprinkled in throughout a sketch, which might be useful for when construction geometry needs to reference non-construction geometry and vise versa.

But I might change my mind and have constructionCircle, constructionLine etc (maybe draft, plan, prefab are better word candidates than construction, more concise)

This mean that the sketch group data will need to change to allow more nested data (array of arrays perhaps). In this regards it might be worth doing this issue #1554 at the same time.

@franknoirot
Copy link
Collaborator

franknoirot commented Mar 4, 2024

Just zooming in on this part of your example:

  |> line()
  |> construction(circle())
  |> line()

Will the llatter line call pick up the lines where the former left off?

@Irev-Dev
Copy link
Collaborator Author

Irev-Dev commented Mar 5, 2024

I think so yes, we'll have to play it by ear, but I think that makes sense for cases where construction(circle()) want's to position itself based on previous segments in the profile, and then parts in the second half of the profile want to reference the construction circle for their geometry. I don't really see a use case for doing a profile for construction geometry i.e. chain of segments so I think this works.

I had also thought we might want to do something like

startSketchOn('XY')
  |> startProfileAt([...], %, 'profile1Tag')
  |> line()
  |> line()
  |> construction(circle())
  |> line()
  |> startProfileAt([...], %, 'profile2Tag')
  |> line()
  |> line()
  |> close()
  |> continueProfile('profile1Tag', %)
  |> line()
  |> close(%) // closing profile1

It's a little messy, so we'll see if we can avoid it, but it's an option, definitely bleeding into #1554 though.

@jessfraz
Copy link
Contributor

relaetd #1876

@jessfraz jessfraz added this to the v1 Modeling App Launch milestone May 21, 2024
@jessfraz jessfraz added the kcl Language and compiler features label May 22, 2024
@jessfraz
Copy link
Contributor

I think we might need engine for this, because if we nuke something later that somthing else relies upon that would be weird right?

@Irev-Dev
Copy link
Collaborator Author

I think we might need engine for this, because if we nuke something later that somthing else relies upon that would be weird right?

Sorry I don't follow, nuking things that are relied obviously a problem, but not sure how construction geometry is unique here.

@jessfraz
Copy link
Contributor

jessfraz commented Jun 24, 2024

Well its a child of something, like if you use contruction geometry to create a line to revolve around, we send the id of that line to engine, then we nuke the line, wtf happens to the revolve, is it okay? I have no idea.

@jessfraz
Copy link
Contributor

Or we create a hole in some gemetry using another geometry then nuke that geometry is the hole okay? I have no idea, since we use those ids in engine

@jessfraz
Copy link
Contributor

oh i understand your question now, yeah i guess name me a scenario for construction geometry where it doesnt wind up a child of the thing we create, i guesss i only see scenarios where it does

@Irev-Dev
Copy link
Collaborator Author

Yeah construction geometry will get a tag, and that tag will be used to reference it later in KCL, so it's in terms of the mechanics of how it's relied on and what not I think it's not really very different from say relying on a tag segment that becomes a face for sketchOnFace.

@jessfraz
Copy link
Contributor

yeah jsut the tag coincides with a edge_id in engine which makes it super awkward when we then nuke it

@jessfraz
Copy link
Contributor

Im not saying we definitely need help from engine here but I'm saying we will eff around and find out I have a feeling some of these will get weird fast

@Irev-Dev
Copy link
Collaborator Author

Okay sweet, worth chatting about.

@Irev-Dev
Copy link
Collaborator Author

fwiw this is how I'm thinking about it.

Screenshare.-.2024-06-24.10_44_42.AM.mp4

@Irev-Dev
Copy link
Collaborator Author

Irev-Dev commented Oct 1, 2024

Related engine issue, not contruction geometry exactly, but instead projected geometry, it will have a similar interface in KCL I think.
https://github.com/KittyCAD/engine/issues/2663

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
engine kcl Language and compiler features
Projects
None yet
Development

No branches or pull requests

4 participants