-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Video export #1808
base: master
Are you sure you want to change the base?
Video export #1808
Conversation
in my opinion, the current linux / bsd "build dependency" system is not designed for the number of dependencies that want to be added, and is no longer maintainable if more are added. the linux/bsd "build dependency" script should be removed from README before any more dependencies are added, and the project should become like almost every other project, advise people to install linux/bsd dependencies with their own system's package manager, and tell them they are out of luck if their system doesnt have a package for a certain dependency. (and advice on how to work to get the dependency included in their distribution) there could be a note on how to build your own custom OpenCSG, as version 1.4.2, just released, is necessary to workaround certain bugs, but most of these other dependency libraries should be available on most linux/bsd systems as premade packages in a sufficiently advanced version where it is not necessary to build them from source. when you combine version incompatabilities and compiler bugs and build tool bugs all the other typical issues of dependency trees, this is an exponentially increasing curve of complexity with each added dependency, not a linear one. that's what makes it unworkable. It was maintainable when there were 6 or 7 dependencies, but nowdays there are several dozen dependencies in the full tree. it is to the point where the linxu/bsd build-dependency is recreating large sections of a package manager like BSD's pkgsrc or Arch's pacman or Mingw's makefiles. people building on machines without root would be on their own (its ok, we are used to it). you could keep the linxu/bsd build dependency script around, but make it undocumented. hackers will find it on their own, looking at a note on the wiki page about how it "might work, your mileage may vary" |
There is not supposed to be any additional mandatory dependency (if I missed something, that's a bug then). The default without the extra libraries is exactly the same state as right now, just enable PNG export via lodepng. The build error is just a file I missed to move to libvpx.pri when shuffling around things. I'll fix that in the next update. |
it is my opinion that "optional dependencies" are even more complicated than "mandatory dependencies". Adding three optional dependencies adds eight possible new states to the build system, (and test, support, etc) making it even a stronger argument that linux/bsd build-dependency script should be removed from the README and become an undocumented "it might work" script for hackers. |
No offence, but why not use ffmpeg (libavcodec+libavformat) for the video export? |
Because I currently have no time to wrangle with that huge monster and 3 build systems, especially with libav vs. libffmpeg in some older distributions. It's all structured in a relatively simple modular way, so adding more options later should be easy (ignoring the build-env part). |
Workaround for anyone who wants to convert an STL into an animated gif. It only requires bash + docker https://stackoverflow.com/a/70468907/1626687 |
This is the code shown in #891 dusted off with a couple of updates...
Change animation panel to dockable window and decouple show/hide of the window from the actual animation logic. Base of the export is the existing PNG single image export which is basically unchanged.
libgif
)libvpx
)libxvidcore
)