search

deadsy / sdfx

A simple CAD package using signed distance functions
MIT License
533 stars 52 forks source link

Request to add pointer to `sdf` project #51

Open soypat opened 2 years ago

soypat commented 2 years ago

Hey! I've made a library based on sdfx and was wondering if it could be added to sdfx's readme to inform users of options when it comes to CAD with Go.

stevegt commented 2 years ago

@soypat I think you'll be more likely to get a pointer in the sdfx README if you reword the sdf README a bit first and then send @deadsy a PR. If you want to do this, I'd refactor the parts around the words "questionable" and "needlessly". Here's why those jumped out at me:

I'm glad to see you in particular tackling open source solid modeling -- it's been sorely needed to make better progress in space transportation, and I'm especially interested because you're apparently into both GN&C and structures and are working in a modern language; humanity needs more of that. (My own background includes NASA supercomputing and the USAF. I run a shop making stuff for everyone from suborbital to superheavy, and once incubated a newspace startup that's still flying 15 years later. Can't complain.)

Support for advanced modeling and advanced manufacturing of aerospace systems was the context behind #24, #26, #27, and #50. When you get to the point of code generation to rapidly evolve structure, engine, flight dynamics, and manufacturability together, it helps to have error returns instead of panics in order to more cleanly inform your genetic algorithm's fitness function.

I'm trying to figure out whether there is any mind-meld that can come out of your work on sdf and Jason's work on sdfx. The whole point of open source is this sort of evolvability, and because it's all just Go I think we'll be able to avoid https://xkcd.com/927/ to some extent, though I can see how APIs are going to matter sooner or later. I'll keep thinking.

soypat commented 2 years ago

@stevegt While I agree with your points I've actually been pleading with deadsy to simplify the sdfx code before optimizing it. This would help reduce the cognitive load of any new contributors to the repo making contributions easier and overall make it more pleasurable to work with (in my case it would save me coding time).

The performance gain was just a nice bonus, I really wasn't counting on it when I set out to simplify the codebase.

Reading over the aforementioned issue I still feel Jason was dismissive about my concerns on simplicity and better API and more worried about whether the existing implementation could reach the same performance given it was changed. I maybe took it a little too personal and let it show on the README, it will be changed.

It's great to meet a another engineering oriented soul on here meddling in the same area. After the software I've seen in the aerospace industry I can wholeheartedly agree it is in dire need of a modern language.

I hope to someday have a pure-go pipeline to do what you describe- so far I've got all the individual pieces in early state

Guess I'll have it ready by the end of this life sometime, I hope heh.

As for the mind-meld: yes please. I really don't like the idea of splitting the community. It'd be great if we could talk and consider eachother's point of view. I was in the wrong thinking no one had use for errors today. It'd be great if Jason heard me out on some of my concerns too on the way sdfx was headed.

Some wise engineer once said

Confession is good for the soul —

To which his yet wiser friend replied

— but bad for your career.