I might have forgotten it, if you hadn't pointed out that it actually can be seen. Don't know what it looks like, but there is another one that can be seen, so I took that;)
They are called universal joints in English (didn't know that...) and they are indeed beautiful when animated!
There are a few tutorials on how to rig these things, I haven't seen all, but I liked this one: https://www.youtube.com/watch?v=cUC3W_rW7dc
spikeyxxx Awesome animation and rigging tutorial you found there!
I called this part a "yoke" since this term appears in the official list of parts for my rear axle. This is a picture of the front drive shafts that I suppose to be the same at the rear axle:
Made some nicer bolts:
Also managed to reduce the number of Vertices from almost 800.000 to around 500.000.
This came with a cost!
Here's the thing: I removed the Mirror Modifiers and made linked copies (ALT+D) and mirrored them over to the other side (S, X, -1). The amount of Vertices did not change!
Now look at this:
I made a linked copy of a subdivided Cube, with the Subsurf Modifier applied. The number of Vertices stays the same.
But when I made a linked copy when the Modifier wasn't applied, the amount of Vertices doubled:
It sort of makes sense, that linked copies can have different Modifiers (or does it?), but then I would expect 188 Vertices, because the 'base' vertices wouldn't be 'doubled'.
So I tried this with my Axle file and as you can see above the number of verts was reduced drastically.
But my file size went from 23 to 72 MB!
It gets worse; the render time went from 4:42 min to 6:06 min. Just to be clear: the version with less geometry but more memory took longer to render!!!
@theluthier or anyone, do you know what is going on?
I do not understand this at all, but decided to revert to the version with the Subsurf Modifiers and the linked copies. Seems like the best option...
I made a linked copy of a subdivided Cube, with the Subsurf Modifier applied. The number of Vertices stays the same.
spikeyxxx
So I think I can explain some of this only because I learned a little about this with Prefab upgrades to Unity last year and I think it relates to what you are seeing on your Link'd Dupes. A linked duplicate is referencing the object data of the original object. What you are doing is passing the information to another location but it is still the same information and is somewhat more tidy. You can scale that information and rotate it but it is still the original data. When you go into edit mode you end up editing everything that is linked. So it makes sense to me that the total vertex count with modifiers applied is no more than with 1 object.
What is happening under the hood I really don't know but I bet they are referencing a location in memory and reusing it in another part of the scene and making small changes to it on screen draw calls. I may be way off base here. But that is probably storing that linked data and then applying changes somewhere else in memory and storing both?
But when I made a linked copy when the Modifier wasn't applied, the amount of Vertices doubled............ It sort of makes sense, that linked copies can have different Modifiers (or does it?), but then I would expect 188 Vertices, because the 'base' vertices wouldn't be 'doubled'.
According to your picture the original object has 98 verts (I presume that is with the modifier data being added on top of the original base mesh data). So the Sub-D modifier is being applied to the base mesh twice and being stored in memory after the sub-d calc. So 98 x 2 = 196
I tried simplifying this to just a 4 sided plane with a sub-d modifier resulting in 9 vertices at 1 level of sub-d. When I link duplicate that object I can still go into edit mode and "edit"just the 4 verts. But the modifier is happening and shifting the data uniquely for each copy and then stores that result in memory. Thus my 9 vert duplicate linked object now contributes 9 verts as well due to the uniqueness being applied to the original data and then being stored in memory afterwards.
In Unity they recently came up with a similar way to make Prefabs all reference a single object but you could add unique charateristics to each prefab in the scene and they would inherit the general properties of their base prefab model and then add with uniqueness. They are calling these unique duplicates Prefab-Variants. When you change something about the main Prefab then the unique prefab variants will all inherit that change by default.
I can explain by making an Avatar of Spikey. The original copy I make in blender and export as an FBX into Unity. I make him with 3 hair spikes coming out of his head. Then I load 3 prefab variants into my scene and they all look the same. But then I give the 1st blue hair, and the second I make really tall, and the 3rd I give him some green skin because, like Kermit the Frog says: "It ain't easy being green!"
I decide I like the Avatar better if he had 4 spikes of hair and a 3rd arm just for fun. I go back into blender and re-export to Unity and viola! All my prefab variants maintain their unique changes but they all magically inherit 3rd arm and extra hair spike!
I think they call these terms Inheritance and Overriding in programming talk in my delves into C# land while pursuing my Unity learning. I also wonder if pointers are being used where you basically set memory aside for a pointer to point you to the actual data? This is pretty common in object oriented programming languages like python and C# if I remember correctly.
Now why the file is getting drastically bigger and taking longer to render is beyond my expertize.
Maybe my explanation and understanding about this is all wrong but I talked myself into it and I feel good about it at least for today lol.
Since Kent is out with baby girl I wonder if @jlampel could give an assist since he knows blender data quite well?
Something interesting spikeyxxx our master file is only looking at linked assemblies and it is only kB in size whereas our files are all MB in file size. Mine still has lots of mods but some of my sub-d are applied. Strange that almost seems like reverse of what you are seeing, right?
blanchsb thanks for looking into this.
What you say in your first answer is exactly where I was at, although I didn't explain it that clear as you;)
There is a different dependency graph since 2.8, so I tried something in 2.79 and found that when you ALT+D a Cube (8 verts), the stats say 16 verts (same as if you had SHIFT+D'ed). So there the behavior was more consistent.
Some stats with 2.97: (file sizes of Scene with Monkeys):
With Subsurf on: ALT+D. 530 kB, SHIFT+D. 1.1 MB
Subsurf applied: ALT+D. 1.2 MB. SHIFT+D. 9.5 MB.
Now that is the kind of behavior I would expect!
As to your second post, yes that is strange and sounds also more logical to me....
I'm a bit out of my depth with that one but what I do know is that modifiers in Blender technically generate a new mesh after every modifier. That's why they can be so slow on complex objects. So, when there are no modifiers, Blender is able to use instancing while rendering and in the viewport to speed things up. When there are modifiers though, that efficiency is lost since the mesh that gets passed to the renderer is different. Technically if both objects have the exact same modifier stack then they should be able to use instancing since the mesh that's passed to the renderer is the same, but I guess that's an optimization that just hasn't been made yet.
Thanks @jlampel for the further explanation to the best of your abilities. We are both scratching out heads and I'm running low on hair. I figured you had plenty to join in haha.
I wonder if a memory issue was introduced and is fixed down the line in the latest pre-release versions of blender as spikeyxxx suggests? Did you mean 2.97 or 2.79 on your latest comment?
Oh yeah. I remember reading that. I went along with it but then reread after my post and edited my post haha. I figured you meant 2.79
Very interesting find spikeyxxx about the poly counts of mirror modifiers vs linked duplicates. I couldn't help myself: Had to run some tests myself..
I created a scene using a 12K poly head sculpt. Version A of the scene uses mirror and array modifiers to generate 144 duplicates:
Version B features the same 144 heads generated with linked duplicates:
Version A (linked duplicates) only use 3% of Version B's memory (modifiers) and renders 40% faster. This info could come in handy for optimizing final DOG renders. And optimizing large scenes in general.
@theluthier that is crazy, I get these results:
- Subsurf followed by two Array Modifiers:
and Subsurf with linked duplicates:
So, linked duplicates are worse on my machine!
Maybe that is because I am using only my CPU????
(What was to be expected: when first Arraying the monkeys and then Subsurfing them is a lot worse!)
Is there an explanation for this significant difference? One should think that both techniques simply copy a mesh an position it with an offset relative to the original.
@theluthier, the association in your last sentence just swaps what you write above each image. Which technique is now the faster one?
Sorry that last sentence wasn't clear. The linked duplicates version renders faster and uses less memory (note the scene name in the bottom right corner of each image coupled with the render time + memory in upper left). I get similar results on CPU and GPU spikeyxxx. I'm using 2.83 and I noticed you're on 2.91 alpha.
Is there an explanation for this significant difference?
My only guess comes from what Lampel said about modifiers duplicating source geometry data to achieve their function. Linked duplicates don't do that I suppose
@theluthier tried this in 2.83.4 and results are similar, linked duplicates are slower to render and use more memory (2.91 appears to be a bit faster...)
Now, it is possible that because I'm on an older P.C., I am not able to use some optimization features that modern hardware uses, but I'd still expect linked duplicates to always be better than Arrays/Mirrors/ normal duplicates...
Guess I'll have to learn C/C++ and dive into the Blender Source Code and see what is going on..
I'll take a look on my new Lenovo Laptop and see how it handles a similar test on my blender version.
spikeyxxx What do you think about making your mark on the steering wheel for our dog? I would love to see a nice Spikey logo.