341–350 of 377 posts
Earlier quoted context omitted.
Famously, all 3D art is of things only found in the real world.
Real world might be boring, but very useful. Especially for companies that move boxes around, not fantasy characters.
Earlier quoted context omitted.
It’s not about seams in 2d but 3d curved surfaces. OpenCascade’s kernel forces you to deal with periodicity in topology (the shape structure), while Parasolid handles it in geometry (the math). A cylinder is mathematically continuous because there's no actual "seam" where it starts and ends. But in OpenCascade there’s a seam from 0 to 2π and this seam edge becomes a real topological entity that every algorithm has to…
Is there any canonical literature on this? I've been interested in what's inside the brep kernels recently.
Earlier quoted context omitted.
Is there any canonical literature on this? I've been interested in what's inside the brep kernels recently.
Boundary Representation Modelling Techniques by Stroud is probably the most popular one. It's expensive but Anna has it in her archive.
Earlier quoted context omitted.
I think the questions you ask demonstrate that you already understand the issue completely.
I'm just a noob asking questions and I'm having a very hard time detecting sarcasm on the internet these days - can you elaborate a bit, please? :-)
You asked the right questions, IMO, and I think they are self evident.
> do they fill the exact same space?
No.
> is Blender adopted by different types of companies?
Yes.
A company or institution that has money to burn will opt for more "professional" suites (Maya, Microsoft, ...). Smaller entities will use the cheaper alternatives (Blender, Linux, ...).
I’d really like to see something like blender come for the 3D CAD industry, at the moment it feels like the only people who would lose out are AutoDesk. The amount of money that flows in and out of 3D cad (as subscription and then value created) having a first class open source kernel and tooling, would be giving big industrial players freedom to modify and tailor to their needs as well as smaller / hobbyists get sta…
"first class open source kernel" Speaking with over a decade of experience as a developer in industrial CAD (but still just one random guys point of view only). The question _isn't_ about the availability of a 3D kernel. 3D kernel is not the "moat". You can cross that with money. You can purchase a ACIS or Parasolid and you are off to the races. Or even use OpenCascade if you know what you are doing. The more interes…
I’d really like to see something like blender come for the 3D CAD industry, at the moment it feels like the only people who would lose out are AutoDesk. The amount of money that flows in and out of 3D cad (as subscription and then value created) having a first class open source kernel and tooling, would be giving big industrial players freedom to modify and tailor to their needs as well as smaller / hobbyists get sta…
"first class open source kernel" Speaking with over a decade of experience as a developer in industrial CAD (but still just one random guys point of view only). The question _isn't_ about the availability of a 3D kernel. 3D kernel is not the "moat". You can cross that with money. You can purchase a ACIS or Parasolid and you are off to the races. Or even use OpenCascade if you know what you are doing. The more interes…
The further you get from a "general purpose" tool toward a highly specialized yet "trainable" one, there's a very perceptible drop in quality. We're talking about god-awful software here, where if you click the wrong button, the whole thing crashes, or you finish clicking the 30 different things in 4 different "wizards" and it still doesn't work. And all for the low-low cost of about 0.25-1.25x the engineer's salary/seat (subject to audit)!
Just having a solid, open-source framework to build upon would have many positive externalities across the supply chain, similar to how open-source systems software allows innovation across the computing supply chain. There would be no AWS without GNU/Linux.
Earlier quoted context omitted.
> And these "most people" who are scared of a Python API? Weak! It should have been a low level C API! ;-) I wouldn't frame it as "scared". The issue is that at a certain scene scale Python becomes the performance bottleneck if that's all you can use. > You pick a (stable) version, and use that API. It doesn't change if you don't. If it truly is a _major_ project, then constantly "upgrading" to the latest release is…
If you had multiple shows in production, I would expect that standards be set to use the same platforms and versions across the board. If the company is more than a boutique shop, I would expect them to have a somewhat competent CTO to manage this kind of problem - one that isn't specific to Blender, even! Also, if the company is more than a boutique shop, I would hope it would be at a level and budget that the Pytho…
Considering productions span years, not months, artists would never get to use newer tools if studios operated that way. And it really only works if shows share similar end dates, which is not the reality we live in. Productions can start and end at any point in another show's schedule, and newer tools can offer features that upcoming productions can take advantage of. Each show will freeze their stacks, of course, but a studio could be juggling multiple stacks simultaneously each with their own dependency variants (see the VFX Reference Platform).
> Also, if the company is more than a boutique shop, I would hope it would be at a level and budget that the Python performance bottlenecks would be well addressed with competent internal pipeline and production engineering teams.
That would be the ideal, something that can be difficult to achieve in practice. You'll find small teams of quality engineers overwhelmed with the sheer volume of work, and other larger teams with less experience who don't have enough senior folks to guide them. The industry is far from perfect, but it does generally work.
> But then again, if the company is more than a boutique shop, they would just pay for the Maya licensing. :-)
And back to reality XD
That being said a number of studios have been reducing their Autodesk spend over the past few years because it's honestly a sick joke the way the M&E division is run. It's a free several hundred million a year revenue earner, but they foist the CAD business operations onto it and the products suffer. Houdini's getting really close, but if another AIO can cover effectively everything in a way that each team sees is better, you will start to see the ramp up of migrations occur. Realistically this comes down to the rigging and animation departments more than any other. But Maya will never go away completely as it'll still need to be used for referring to and opening older projects from productions that used it, beyond just converting assets to a different format. USD is pretty much that intermediary anyways, it's the training and migration effort that becomes the final roadblock.
Earlier quoted context omitted.
I've been working on a quite simplistic tool which currently just supports writing out DXFs and moving tools in lines and arcs for a 3D preview in OpenPythonSCAD --- I _think_ I can envision what you are describing, and it sounds very interesting, and might be an approach I'd want to look into for 4th and 5th axis work --- do you have any texts/references which you could share/point to?
Here's a demo of tangents being calculated in real-time for complicated curved surfaces: https://enkimute.github.io/ganja.js/examples/coffeeshop.html... In general, GA and its variants like PGA are good at calculating tangents and offsets for points, lines, planes, spheres, and other parametric surfaces. The key benefit is that the exact same algorithm will work in 2D, 3D, 4D, or any higher number of dimensions. This…
Earlier quoted context omitted.
agreed! take a look at https://Plasticity.xyz . It's not open-source, but it's got a small, highly dedicated team behind it. It's built on Solidworks' kernel, so it's quite robust. Also take a look at solverspace, caligula, FreeCAD, ...
* Node-locked (up to 2 machines) Hard nope.
Earlier quoted context omitted.
Blender gives you two paths for extension: a) fork it and layer your changes directly onto the app, or b) you create a plugin via the Blender Python API. For vendors, the former is obviously a no-go. The latter has the issue of be throttled by Python, so you have to effectively create a shim that communicates with an external library or application that actually performs compute intensive tasks. Most (if not all) ind…
I'm curious as someone who's thinking of making a blender plug-in that will need to use some native-ish (not C++ though) libraries/modules for performance. What are the issues with using a Python interface instead of a dedicated C++ SDK?
1. Extend Blender itself. This will net you the maximum performance, but you essentially need to maintain your own custom fork of Blender. Generally not recommended outside of large pipeline environments with dedicated support engineers.
2. Native Python addon. This is what 99% of addons are, just accessing scene data via Blender's Python interface. Drawbacks mentioned above, though there are some helper utilities to batch process information to regain some performance.
3. Hybrid Python Addon. You use the Python API as a glue layer to pass information between Blender and a natively compiled library via Python's C Extension API. With the exception of extracting scene data info, this will give you back the compute performance and host resource scalability you'd get from building on Blender directly. Being able to escape the GIL opens a lot of doors for parallel computation.