i hope they eventually add more support for 2D in the style of toonboom or after effects. being able to draw with vectors, create puppets, and then animate them. 2d animation is sorely lacking when it comes to open source software.
Blender 3.x roadmap
101–110 of 119 posts
Re: Blender 3.x roadmap
#102Blender is such an amazing tool. I have a side business where I create 3d printed jewelry with my customer's fingerprints on it in gold and silver ( https://lulimjewelry.com ) and I use Blender on the backend for all of the jewelry creation. I run blender headless in a docker container on google cloud run. When needed I invoke it with an image and have a blender script "engrave" that image on the jewelry and output a…
That's a really cool application of Blender! I'm also using Blender headless in docker containers on Google Cloud, though not using Cloud Run. I'm doing it for self-service molecular visualizations -- "create your own molecule video". It's at https://bioviz-studio.com. But I run up to 50 dual-T4 instances for speed (Cycles X helps a lot!). And I agree the python API is a bit weird, and hard to use, but once you get the hang of it you can create really complex and interesting scenes just using python.
Re: Blender 3.x roadmap
#103Earlier quoted context omitted.
Collections and objects have fundamentally different purposes. An object's job is to anchor a bit of geometry information (e.g. a mesh) in the scene. Collections serve as hierarchical grouping and instancing. Instancing is specifically intended to not produce deep copies of objects. This is essential for creating some types of really complex scenes. Any modifier - destructive or otherwise - requires one or more deep…
Yes, except that you CAN instance collections. You can do linked imports of collections and you can do linked duplicates of collections. And I understand the difference conceptually, but what I'm saying is that the distinction always ends up being arbitrary to me from and actual usage point of view. If I've made a wall or a tower out of mesh data directly, or a collection of objects, it makes no difference to me in r…
You're correct in saying there's no real difference between objects and collections, but there is a meaningful distinction between mesh data and objects, in the object just being a container for the mesh. The modifiers, including array, actually work on the underlying mesh data, not the at the object level, and produce a mesh object as an output. As such, the array modifier does not utilize instancing but actually copies the mesh data multiple times in memory (both RAM and GPU memory), which is definitely not what you want with large, complicated scenes.
So it's not actually about the modifiers being able to be used for what you want in one scenario and not being usable in in a slightly different scenario; the array modifier is not really the tool for the job here at all.
The tool to be used for both of the use cases here is instancing, not the modifiers. Setting up your scene with multiple levels of collections and using proper instancing (which the array modifier is not) certainly is possible, there's just a couple of pieces of the puzzle that you seem to be missing (or unobvious hoops you have to know about, depending how you look at the UX).
Instead of arguing about philosophy and good UX design, I hope you don't mind me elaborating in a more step by step way on how to actually set a scene such as your example up.
You can spawn a collection instance at the location an "empty" type object, by selecting "collection" as the instancing type at the instancing section of object properties. You can have many of these empties and position them manually if you were so inclined.
The other thing is that you can use a mesh to spawn instances of an object at each face of the mesh. So you can create a mesh object, and set up instancing to spawn aforementioned "empty" object, that in turn spawns the whole collection, at each face of the mesh. (You do this by parenting the empty to the mesh, and setting instancing type to "Face" in the instancing panel).
This mesh would typically be rather simple, for example just a couple of disjointed faces scattered where you want your collections to spawn. Or just a single face, and mesh modifiers applied to it, such as array. So instead of arraying the collection, we array a mesh consisting of a single face, and each face of the arrayed mesh spawns an empty that spawns the collection, but the end result is the same. (No idea why each face can't be set to spawn the collection directly and we need an intermediate "empty").
You can also set instances to appear from particle systems etc, for example if you want your houses to just be randomly scattered on a surface of an object (like mesh in shape of the city or so)
Re: Blender 3.x roadmap
#104The Blender x Internet project is called Meta! quite unfortunate timing
Re: Blender 3.x roadmap
#105I love Blender, but have been stuck on version 2.7 due to what I can only describe as some sort of icon dyslexia. For 2.8, all the Blender icons were replaced with monochromatic ones. This is a very popular trend and a lot of programs are replacing their icons in this way, so it's obviously fine for most people, and I realize this is probably a niche accessibility need I have. But, to use the new icons, I find I have…
Perhaps this will help you.
https://blenderartists.org/t/would-you-like-the-colorful-2-7...
Re: Blender 3.x roadmap
#106I love Blender, but have been stuck on version 2.7 due to what I can only describe as some sort of icon dyslexia. For 2.8, all the Blender icons were replaced with monochromatic ones. This is a very popular trend and a lot of programs are replacing their icons in this way, so it's obviously fine for most people, and I realize this is probably a niche accessibility need I have. But, to use the new icons, I find I have…
It makes perfect sense, we are (most humans) visual creatures and color adds an extra dimension of information. Your issue sounds quite legit.
Re: Blender 3.x roadmap
#107Earlier quoted context omitted.
Well some things are already done. For example Cycles X will be released at the end of this year.
The 3.0 beta came out last night. The speed increase is staggering, I can easily use cycles in real-time in the viewport now!
Oh wow that sounds amazing. I didn't know what to expect but even if the increase is only 25% of what you describe it'd still be amazing.
Re: Blender 3.x roadmap
#108Biggest thing I’m waiting for is metal support for the cycles render engine. It’s only CPU on Apple Silicon, which is a waste on Pro/Max chips.
...or Apple could bite the bullet and just support the open, next-generation standard everyone is using. Metal is silly, if it's 'superior' to Vulkan, then at least give developers the option. Sadly it's another App Store situation, where you're forced to entrench yourself if you want basic functionality. It feels like MacOS is the new Linux, with how little software actually works on it now and how bad the performan…
But Apple don’t need a portable cross platform API which they have limited control over and can’t accurately forecast functionality.
They need something they can tightly control which grows side-by-side with their hardware ambitions/product vision.
OpenGL did little to make the Mac easier to target, while supporting a standard that sunk into irrelevance, I’m sure they’re not keen to make that mistake twice.
The bonus of this approach is apple needed to directly sponsor+support blender to make it happen.
Re: Blender 3.x roadmap
#109_sigh_ ... Still no C++ API :-(
Re: Blender 3.x roadmap
#110Earlier quoted context omitted.
...or Apple could bite the bullet and just support the open, next-generation standard everyone is using. Metal is silly, if it's 'superior' to Vulkan, then at least give developers the option. Sadly it's another App Store situation, where you're forced to entrench yourself if you want basic functionality. It feels like MacOS is the new Linux, with how little software actually works on it now and how bad the performan…
But Apple don’t need a portable cross platform API which they have limited control over and can’t accurately forecast functionality. They need something they can tightly control which grows side-by-side with their hardware ambitions/product vision. OpenGL did little to make the Mac easier to target, while supporting a standard that sunk into irrelevance, I’m sure they’re not keen to make that mistake twice. The bonus…
OpenGL was inevitably going to be depreciated, you won't find me crying many tears over it's grave. Vulkan is an entirely different beast though, one that Apple should support. They have the resources to make it happen, any excuses they make are quite obviously perfunctory and dismissive. Maybe Apple doesn't need a cross platform graphics API, but I do. Their 'devil may care' attitude towards backwards compatibility doesn't make me confident in owning a Mac.