Open Irev-Dev opened 4 months ago
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?
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.
I think we might need engine for this, because if we nuke something later that somthing else relies upon that would be weird right?
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.
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.
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
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
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.
yeah jsut the tag coincides with a edge_id in engine which makes it super awkward when we then nuke it
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
Okay sweet, worth chatting about.
fwiw this is how I'm thinking about it.
https://github.com/KittyCAD/modeling-app/assets/29681384/4f42a82a-1aba-4929-bbfe-c0077853bb43
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
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 (maybedraft
,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 https://github.com/KittyCAD/modeling-app/issues/1554 at the same time.