It appears to use C3D as its CAD kernel, which is proprietary. You can't build it without a copy of C3D. I'm guessing the source will be available for inspection, but the binary will cost money.
A full build from scratch would require the c3d headers, which I can’t provide.
What I am planning is to something like this: divide the app into two pieces, an npm wrapper around the kernel and the electron front end that uses the module.
You will need a license key to “activate” the node module. You would then use the electron app or the module directly if you’re a programmer. You will be able to build your own fork of the electron app, but not the npm module.
In effect you will be paying for a license key, not the binary
I will say I’m constantly bewildered by which license to choose. I’m using copyleft to defend myself a bit. But weak copyleft because I’ve hate that the gpl prevents blender plug-ins from being closed source or linking against something closed source. Plasticity will allow plug-ins to do whatever they want, that’s the goal.
There is some possibility I will switch to MIT since philosophically I’m more in that camp
> I’m using copyleft to defend myself a bit. But weak copyleft because I’ve hate that the gpl prevents blender plug-ins from being closed source or linking against something closed source
So you're ok with using copyleft to defend yourself, but not ok with others to use copyleft to defend themselves ? This is bewildering
Their stance seems reasonable to me. They seem happy for works to be GPL, but frustrated that it means plugins or extensions or things which are not the core work themselves are then hampered.
That’s exactly my take. What exactly constitutes a “derived work” in the gpl (plug-ins do!) is counter intuitive to me.
Even the lgpl definition of “dynamic linking” is something that scares me in the context of npm modules, which is why I’m nervous I made the wrong choice with lgpl
But why would a GPL app need to force GPL on a plugin? That seems to me like a perfectly reasonable boundary between the two applications. If I wanted to leverage OBS for example and introduce my own plugin that made use of a closed-source library or tool I had the license for, I should be able to create it. My third-party plugin doesn't impede the distribution and usage of OBS in any way, only provides a separate feature that might require a different license.
As someone who spends most of his days on a GPL app which loads plug-ins, I do not want my work to serve the interest of proprietary software vendors more than strictly necessary, simple as that. I spent the effort of writing the app, defining its plug-in APIs, etc; if others want to benefit from this effort they should also spend the effort of writing GPL plug-ins. The end result is that no end user will ever be stuck because $PROPRIETARY api shut downs or change (and in my field I've seen that a ton of times).
> I should be able to create it.
Why do you feel entitled to that ? No one prevents you to go and write your own OBS-like or look for a proprietary alternative (and don't complain when they change or shut down their API with no possible recourse at all). But here you look you you want to benefit from the work of OBS contributors, without satisfying the simple obligation in return: the program that you redistribute must be open, just like it was when you found it.
Because I'm not beholden to your ideals. GPL is tantamount to a parasite, infecting everything it touches, regardless of the wishes of those who'd make use of the GPL'd software.
I was a contributor to FOSS until I had to make a choice to step back from excessive keyboard use due to RSI. I love and embrace open source software and the ideals behind it, but I believe everyone should be given their own freedoms.
The plugin boundary should be exactly that, a boundary between the primary app and any created plugins. Why do you feel entitled to force a license decision on a third party's work? Yeah, my work might not function without your code, but your code is your code and my plugin is mine. If I choose to write a utility that enhances your code in ways I want, is that not the benefit and flexibility that FOSS clamors about? Hell, what if someone else adopts a similar API and I choose to take my plugin that direction? That's my choice to make, but forcing GPL on my code may now be hampering my freedoms.
I hear the argument of "if only software X was open source, then I could fix this bug here or add this feature there". I'm right there with you on code that is in the mainline and lives inside the source, but if I'm writing a plugin, that's my work and I own that, not you.
If I choose to make use of a proprietary library because it makes sense to me, like for example CAD solvers where the FOSS alternatives aren't there yet, that's my decision for my plugin. All your GPL license does is infect my work.
That's why I don't use GPL, and why I agree with others that the end result of many GPL licenses is to simply reduce the overall amount of GPL code in the world, as people avoid it out of concern of risk.
> I believe everyone should be given their own freedoms.
Absolute freedom does not exist (or even make sense).
> The plugin boundary should be exactly that, a boundary between the primary app and any created plugins. Why do you feel entitled to force a license decision on a third party's work?
That's the expectation I set when I develop the host software. If I was fine with third party proprietary plug-ins I could set my plug-in headers as MIT or something. Just like if I only wanted my software be used by people who have no revenue or live in $COUNTRY I would put that as a license instead of the GPL.
> Yeah, my work might not function without your code, but your code is your code and my plugin is mine.
this is super super entitled. You're fine with leveraging GPL work which is release for free for your own benefit, but do not want to reciprocate. As I posted elsewhere: https://en.wikipedia.org/wiki/Golden_Rule ; this is the most basic expectation one can have.
> but your code is your code and my plugin is mine.
but the GPL code is and will forever be freely available ; anything that goes against increasing the pool of freely available thing is a no-go. The end goal of all that would be to change laws so that ownership of ideas, patents, etc..., is itself ended ; ultimately, licenses and copyright shouldn't even need to exist.
> If I choose to make use of a proprietary library because it makes sense to me, like for example CAD solvers where the FOSS alternatives aren't there yet, that's my decision for my plugin. All your GPL license does is infect my work.
Again you seem to forget that your plug-in depends on an existing host software and seem to want to use the work done there without giving anything in return. If there was some kind of public standard for CAD solvers so that the GPL part of your plug-in could be also used with free solvers, that would be a non-issue - ship your plug-in, and end-users can install a free solver or a proprietary one separately if they are fine with proprietary code.
I think it's fine for people to have varying philosophical takes on what should be the normative goals of open source software licenses. Obviously the FSF takes a rather maximalist stance. I personally find this aggressive goal and some of the personalities behind it to not match my vibe. And the reality is that more permissive licenses like MIT are becoming more and more popular.
What I've seen some Blender plugins do to get around this is to have an open-source plugin communicate via IPC to a closed source library. It's totally legal. It's a performance and implementation tax that just seems silly to me.
If the IPC is here only for the sake of circumventing the GPL (e.g. there aren't any meaningful use of the "GPL plug-in" part through this IPC channel outside of communication with the non-GPL program), it's totally not. What are such plug-ins ?
Why would it be illegal to use IPC to communicate from one GPL executable to another non GPL executable?
Files are interprocess communication too. If files are fine and other forms are not, then it starts to get into an argument of speed making something illegal.
Not only that, but network communication is IPC and that would imply that it's fine to have a GPL program go to another computer holding a non GPL program, but not if they are on the same computer. There are a lot of holes in this argument.
Not only that, but any program that can't communicate with other programs (do drivers count?) through file formats, networks operations or anything else is probably limited anyway.
I think so. I originally said there were a lot of holes in their argument, but I think they didn't actually make an argument in the first place, they just made a claim with no evidence behind it.
The GPL does not care about stuff such as libraries, executable, etc. The only relevant concern is whether your IPC-splitted thing is part of the program, or is a public API expected to be used by many unrelated other programs.
Quoting the GPL:
> The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
The relevant part is "intimate data communication": querying for instance some other program's publicly-advertised D-Bus API, such as a notification service expected to be used by the whole operating system wouldn't be "intimate data communication". However splitting a single executable into two parts which don't individually make sense are obviously "intimate data communication" - it may be two binaries, but it's still one single software from the point of view of the end-user.
If the GPL part of your plug-in cannot do meaningful things (basically still be useable for its original goal by the end user) without the other, proprietary, side of the IPC up and running, then they have "intimate data communication" and distributing it is breaching the GPL.
I have a hard time imagining how one would justify that a CAD plug-in split under two parts for IPC wouldn't constitute a single work for instance, with the following GPL paragraph in mind:
> A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit.
You mentioned drivers: they are specifically denoted in the paragraph above ("it does not include the work's System Libraries").
First is a plugin that would be shared library loaded into the same virtual memory space as a running program.
The second is GPLed header files that define function signatures and data structures.
The third scenario would be passing already defined data formats like JSON or something serialized through the file system, shared memory, or the local network. In this situation, there would be separate processes, separate memory spaces and no interface definitions would need to be included into the non GPLed program. This situation can't violated the GPL because it would imply that almost any communication with a GPLed program would violate the GPL.
> This situation can't violated the GPL because it would imply that almost any communication with a GPLed program would violate the GPL.
any intimate communication would indeed. Any communication that goes through a standard (e.g. ISO-defined or industry standard, so not something specific to your company) would not.
Quoting the FSF:
> Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking.
You can obviously extend "communicating complex data structures" to RPC through JSON & websockets for instance as it's this "exchange of complex data structures" which is the defining matter in what constitutes a single program from the point of view of the GPL.
I gave specific examples and you keep using an abstract label.
> Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking.
These are two separate things unless they are talking about shared memory meaning sharing the same memory space as another process, which is what dynamic linking does.
Communicating through complex data structures can describe files too. If you save a file from one GPLed program and open it in a non GPLed program, that is interprocess communication. If both programs are using mmap on the files instead of writes, does that change things? If files are being sent over local loop back does that change things?
Are there any examples of any of these ideas being tested? I've never heard of anyone except for you asserting that two processes communicating without including GPLed source code was somehow a GPL violation.
> I gave specific examples and you keep using an abstract label.
I am quoting the license text.
> Communicating through complex data structures can describe files too. If you save a file from one GPLed program and open it in a non GPLed program, that is interprocess communication. If both programs are using mmap on the files instead of writes, does that change things? If files are being sent over local loop back does that change things?
I don't thinkg it would at all - it would still breach the license if e.g. you are dumping raw struct contents in your files that are only meaningful for the proprietary side of things.
The part you are quoting is still an abstract label. You can't take specific common scenarios and say 'intimate communication is banned' when 'intimate communication' is not defined well.
you are dumping raw struct contents in your files that are only meaningful for the proprietary side of things.
What does that even mean? You could work with the bmp file format internally as a frame buffer in a program because it is uncompressed. Does that mean if you write a bmp file out of gimp and open it in photoshop you are violating the GPL? If so, why has that never been brought up or asserted by any person or company ever?
The things you are saying don't seem to line up with what anyone else thinks. When has anyone else tried to claim that you can't send files from one GPL program to another non GPL program?
I think you should consider whether you are trying to claiming something is true because you want it to be true, not because it makes sense.
IPC is totally worthwhile for native applications in any case, when separate complex components are combined into a single user session. Running the code in separate heaps reduces the chances of bugs in one application code corrupting the entire application heap.
Very hard to argue that IPC would ever be just for avoiding license. It always increases total robustness.
I agree with you -- it's hard to safely kill a runaway thread but it's not hard to kill a runaway process. But I think it's worth noting that the performance characteristics of IPC can be very bad
As a very tangential side note, behavior like this is fairy common, and a good reminder human being are not rational actors. People drive like asshats when they're in a hurry, but are very upset when someone else drives that way. Rather than bewildering, I would call it human nature. What is rare though, is being very honest about it.
> People are free to use whatever license they want and I’m free to explain why I choose lgpl over gpl
choosing a license is a political act whether you want it or not - you are free to choose whichever license you want, that does not mean you won't get called out (like for any other choice with political relevancy even tenuous - eating meat, driving a car, etc. to speak about things I am guilty of for instance)
We shouldn't have to live in a culture when being called out for making a 'choice with tenuous political relevancy' is socially expected, and something someone is 'guilty of'.
surely you see how your position is not workable in any decent society ? this is literally one of the only common rule across humankind: https://en.wikipedia.org/wiki/Golden_Rule
I thought I am the copyright owner and I can offer my code under as many licenses as I want. Many people dual license gpl code is my understanding. Converting my own code to mit should be allowed right?
Every Google result I’ve found says I’m the copyright owner and I can offer as many licenses as I want. Are you just trolling?
So external contributors can only provide patches without being able to test themselves I suppose.
Is the c3d dev license cheap enough for determined contributors to join? As in, cheaper than a f360 maker license?
I do not mean this in any pejorative sense. As a dev/maker I kept an eye on c3d for a long time, since that seems the only advanced-enough and commercially affordable brep kernel around to get off the ground quickly.
However, there's no discussion the closed nature pretty much bars any sort of in-depth contributor.
At least, contributing to a project like this would be extremely off-putting for me, to the point that besides having the ability to look a bit deeper than usual, I question whether keeping the source open does much.
> So external contributors can only provide patches without being able to test themselves I suppose.
My intention is that if you buy a license for plasticity, you can then build locally and test locally. You can contribute back or not depending on your interest.
Think of it like this. There will be a typescript/javascript wrapper around a limited version of the c3d kernel. this is the plasticity api. You will call plasticity.Enable(license_key) at the top of your program and you will be good to go. You buy a license key from me.
Although I do hope people will contribute the plasticity's development, my main goal with it being open source is that people will write plugins that they can then give away or sell themselves.
I have used commercial software that I pay for -- like Fusion 360 and MoI3d -- where I ran into bugs that I could have fixed for myself if only I had the code. I'm still happy to pay for them. Instead I literally waited 2 years for Fusion to fix a bug I cared about.
It is for sure a murky area where I'm working out the details. You don't have the full kernel. But you can think of it a bit like a scripting API on top of the kernel, which is not uncommon in CAD apps, like OnShape's FeatureScript or something.
you may sell binaries of GPL licensed code. red had is doing it, while the redhat source is available for free. (which is how centos and now rocky linux and others are made)
I find this to be a very cool NURBS-based CAD project, can't wait to play with it more. From what I can see it borrows a lot of concepts from solid modeling CAD tools like Solidworks, but also has UX similarities to other common surface modeling tools like Blender. Here is a video of how it works:
Blender as a tool is very far from CAD-ey, in the sense that precision work - this should be 120 mm and that should be 1.41 times this - is not really a supported workflow. There isn't even a constraint solver in Blender.
You can make Blender work as a CAD-ish tool with practice and self-discipline and lots of keyboard shortcuts. But e.g. Fusion360 or even SketchUp is what a CAD-oriented workflow feels like. There is a big difference.
Haven't tried this yet, but I expect it to retain enough of the CAD-oriented approach that the workflow still feels quite different from Blender.
I think the main thing to understand is that blender has minimal nurbs support. For example, try doing booleans, fillets, or offset surfaces with blender nurbs. You can’t.
Nurbs are good for some shapes and bad for others. In addition to manufacturing, nurbs are great for hard surface / scifi assets for video games and movies.
Plasticity is for artists. It is more in the tradition of MoI3d than say solidworks. It has a very powerful geometry kernel and the user interface is meant to be familiar to blender users and modern looking.
I get PTSD when i heard the acronym of NURBS. Decades ago when Subdivision modelling wasn't a thing YET, people though that NURBS was a viable modeling method.
[EDIT 3]: now that I've been able to install try it on Linux: this is really nice, very pleasant UI, and for those familiar with blender, the interaction style will be familiar. I will definitely be keeping an eye on this.
For those of us who are not familiar with the domain, what differentiates this from Blender? Does Blender not support NURBS? If not, why is that the case?
Blender does support NURBS but very basic and very limited to the point that it's not very useful.
Basically there are 3 methods for creating 3D content:
* Voxels (points in space)
* Polygon (vertices, edges and faces)
* Mathematically calculated (NURBS, CAD)
Blender uses all three but focusses on polygon modeling (triangles).
The real pro of NURBS mondeling is that you are working with surfaces that can easily be shaped. That's why this method is used a lot in product development. Since all surfaces are calculated they also are infinite smooth. When you want a smooth surface with polygon modeling you need a lot of triangles.
For each category there are different tools, Blender is just one of them.
Some examples of software products per category:
product design: Rhino
car design: Alias
house design: Revit
technical components: Fusion 360
game assets: Blender
sculpting: Z-Brush
movie GFX: Houdiny
Grasshopper is used a lot for parametric 3D printing as well (the printer prints a one continuous space-filling curve rather than individual layer slices).
As others have said, Blender supports NURBS, but it is not too fancy.
I have played before with Moi3D[^1], which is "3D modeling for designers and artists", and I also use Blender and ZBrush quite a bit. My impression so far is that CAD-like specialized software is not worth using for artistic 3D modelling, at least the type which is only intended to be shown on a screen. That's because Blender's NURBS, curves and surfaces are good enough for simple shapes. For relatively complex shapes, the solvers in CAD engines can be very slow and glitchy[^2].
With a little bit of patience, one can do amazing non-destructive hard surfaces using curves and Blender's Geometry nodes (specially now that there is support for curves). With an entirely different workflow, ZBrush is a mighty hard-surface modeller as well[^3].
That's not to say that there aren't scenarios where one may have use for a solver, but they are so specialized that most artists would be better off doing the math outside their 3D modeller (or renting Fusion360 for a month, but for a casual user that software has to be more intimidating than using Python and Kiwisolver).
A 3D editor mainly intended for visual pipeline such as Blender, and a modeling application intended for producing physical shapes have entirely different constraints and intents. They both operate on 3D data, but it's best to leave it at that.
If we use text files as an analogue, then the "3D" feature in these applications is roughly a similar unifying feature as "text based input" in programming languages - or in all programs for that matter.
For text files, you want it to have specific encoding - e.g. UTF-8. For 3D shapes, you want the data to similarly follow a mathematical schema with specific topological constraints.
If you break the convention of the encoding, or the schema, you produce gibberish.
With a specific standard in place some parts of input data may or may not be transferrable between domains (e.g. CSV data is kind of lingua franca) and lots of interesting things can be built on top of that.
But generally you could ask "how is this different from" X where X can be for example Excel or Photoshop - the answer is very complex.
Blender supports NURBS.
What differentiates this from Blender? Blender is a full fledged pipeline of tools, not to CAD, extensive modeling tools, texturing, rigged animation, post production, multiple rendering engines.
It's like comparing a specific photo editor that say focuses on filters and color adjustments, with Photoshop.
Right. It's even got things like a text editor with syntax highlighting and an image editor. If someone spliced a browser in there, it could practically be a whole OS on its own.
it probably deserves the comparison with Linux altogether as it's even more multi purpose and has become, at lead since v2.8, not only appealing to total geeks.
I can't think of any other open source software, other than Linux, that represents such a threat and valid alternative to commercial products. Autodesk be damned, even merging with Adobe wouldn't solve the Blender problem.
This is very interesting to me. However if it’s truly for “artists”, linking to a GitHub page isn’t going to reach that demographic. You need a proper product web site with an explanation of the features and benefits using images and videos. And you need a simple download link.
I’ve been using and managing CAD professionally for product engineering for 30+ years and I’ve had GitHub accounts to review code for work things. My eyes still glaze over and I close the tab if someone dumps me in their GitHub and expects me to find the right pieces to download. It’s user-hostile.
When I get to version 1.0 I will do all of those things. For now this is a beta, more for artists who are interested offering feedback to affect the design of the app.
Even in beta, how you present your work is as important or possibly more important than the "work" itself. (It's actually a significant part of the work.)
I've been involved with beta programs for other CAD tools and constantly give feedback to the Onshape team for their design and development of their app. I've worked at major design firms (IDEO, Pentagram, Lunar, etc) and have an ID background. I'm very enthusiastic about CAD and its creative uses. I'm part of what I understand your core audience to be.
I'm trying to give you constructive feedback that a GitHub link which dumps me into a directory is a huge turn off.
Go look at Shapr3D [1], Gravity Sketch [2], or even FreeCAD [3]. Look at how they have calls to action, download links and key benefits shown visually in 2 seconds.
Watching some of the videos on your YouTube page [0] gives a much better impression and clarity of what you're trying to do. Particularly this one [1].
The workflow and ease of creating so many features with so few keyboard/mouse commands is intriguing. I understand that you're trying to focus on game asset creation, but since it does do STEP import/export, there's really no reason this can't be used for ID or engineering work, at least at the initial concept level. Don't ignore those markets.
I appreciate your feedback and I totally want to market it in the way you propose. But let me be real: I am one person doing everything. I expect to have all that stuff by September when I plan to launch 1.0. If I were "in control" of this situation, I'd prefer the app get more buzz closer to launch rather than 6 months away. But I can't really control when people post to hacker news... And in any case I think all publicity is good. Dying in obscurity is the biggest risk.
I've also been using CAD professionally for nearly two decades (RhinoCAD), and was intrigued by the title. When I saw it was just a GitHub code page, without even much for documentation, etc. My response was basically "nevermind", although I did come to check the comments - the video definitely highlights capabilities in a way I would never have guessed form the GH link.
In short, some basics that I learned while building software companies (before doing materials & CAD):
1) Most users have very little imagination - we MUST really spell everything out and draw the connections for them, at least until they get to the "AHA" moment.
2) Most potential customers have no interest or knowledge of software and how it works (software for artists this goes double++). They want to know what it can do FOR THEM, not how cool it is for us
3) A decent approximation for how well users will understand something is what we as software experts would understand with a new application or feature set when we are very tired and in a huge rush - think what you can figure out in less than a minute at 3AM when you've been crunching for days under a deadline, and someone brings in a new thing - it isn't much; you don't really GAF about the new thing, if it isn't really obvious, you'll skip it for now. That level of insight is what is available for a non-expert after a half hour of presentation. So, whatever it is, you need to design it and the presentation of it so that it meets that criteria - you could present it to your peer at 3AM in crunch time and they'd be able to pick it up and use it (or at least get the "AHA" moment and see the utility).
I knew it hadn't yet launched. thx for the update on the poster.
Still, the knowledge was hard-won, and I hope it helps someone else on the forum. I've had people randomly provide me with a few of their hard-won gems over the years, which when I applied it made substantial positive differences in my career.
It seemed relevant to the topic, even if not in the strict sense of advising directly the developer in this specific conversation. (Also, it'd not unlikely that the Dev would have the convo brought to his/her attention, so it may end up there anyway).
I want to emphasize to everyone that this is for concept artists. It’s nurbs used to create interesting shapes and fillets. While there are some parametric features, they’re completely de emphasized compared to something like fusion or solidworks
Some very basic parametric features might open this up to a large woodworking community that wants to sketch out design ideas before building. Sketchup used to be the goto but now people are hungry for a replacement (which seems to be Fusion360 at the moment) but don't want or need a full CAD solution.
That was exactly my thought. I've tried to use fusion/freecad/etc for woodworking, but this looks amazing for it. But I'd like to set some basic dimensional parameters
Isn't Fusion 360 similar? I don't think it's Electron, but it definitely doesn't feel native. Despite its jankiness, it works and is free for hobbyists.
This is a significant issue for anyone doing business with Russia. I’m happy with c3d in general but there is a possibility I will be forced to use another kernel
Parasolid and Acis are the only other options. I have a lot of admiration for OpenCascade but unfortunately its functionality is very limited for my needs.
I’m considering parasolid but, no, I can’t keep this price point with it
I think all recognize the necessity for general sanctions due to the heinous, illegal and genocidal invasion of Ukraine. This however, is a slightly tangent topic to that.
Some software companies with operations in Russia are Russian, other have their IP licensed by a legal entity outside of Russia. Not sure into which category c3d falls into. Which partially motivated my question.
One really can't stop using code a native Russian has ever touched - it's like deciding never to read Tolstoy again, only much harder since Russians are very prolific in software technology. Also, for code for whose IP has been already purchased, it would not be very effective as a sanctioning tool. The point is not to "cancel" Russian culture or technological output as such - only to stop trade to put economic pressure on the population and hence their government. The domain of the licensing entity in that sense is relevant here, but not to simply "stop using anything from Russia".
I'm curious how this will be implemented. According to the LICENSE file in the repo, the current source is available under LGPL.
What will cost $25? Will the repo be taken off-line after 1.0 release? Or will further updates after 1.0 be binary only?