108 replies · posted

Backhoe Contribution-spikeyxxx-Wheels/Axle

A bit late to the party...

  • Didn't start this earlier, because there was not much to show; I must have started from scratch on the front axle, about 17 times!

    This was because I couldn't 'understand the shape of it...(Still need to figure out how the steering is connected to the axle...)

    I submitted this yesterday, because it was time and I am not unhappy with where this is going:

    There are however some intersections with the Chassis adrian2301 and the axle should actually be able to rotate quite a bit on the Y-axis and there doesn't seem to be a lot of wriggle room there:

    Although it has room on one side, so maybe that is ok, have to re-watch that video that blanchsb linked me to...

    The engine enclosure however aartifact and ddoulos4iesou  is completely in the way;)

  • Oh, and here is some of the wireframe madness:

    • I think that is looking great spikeyxxx I can wait to see the actual non-subdivided wireframe.

    • blanchsb Thanks, you can check it out at the Google sheet for the Collaboration. You can read all the Comment boxes (where there is a little orange triangle in the upper right corner) and thus have access to all contributions...

      There are still a few tiny mistakes in that (second) file, they have already been fixed now, but I didn't want to update my submission again (there were some non-quads, because some verts hadn't merged at some point...and one 'ugly' quad, I mean shaped like an arrow head.).

    • That's funny because I resubmitted last night lol. Oh well hopefully Kent doesn't harp on it too much. I'm such a rebel.

  • Oh No My Wheel is too Big! and when I aPend it It deletes all the objects except the tyre. I cannot scale it down  or it will make the tyre thinner. can you Help?

  • Started on this part:

    just out of curiosity (how I would handle this) and because I spend so long on the 'housing' and still haven't figured that out yet;)

    theluthier will probably reduce my points because of the non-planar quads (and a six sided pole...), but I think it just works here.

    It feels like 'How to get away with....'

    Now I am going to work my way inwards...let's see how that goes...I think I will go with holes, then we will have a 'holed' and a 'solid' version.

    • If that is the section with the issues. I think it could be overcome with more geometry to work with on the circles. But it also means more things to connect the geometry too haha. Maybe this is good advice and maybe it isn't lol.

      The center circle may have enough sides to work with to be honest.

    • blanchsb you're absolutely right, but I don't want to add more geometry, because it's not an issue for me;)

      I like how it looks subdivided, it gives the exact right transition imo, so I'll leave it as it is even if costs me some points...

      If it looks good then it's ok.

    • Yeah I think that is a decent response. Good mentality to have especially if the mesh is not deforming.

    • Sometimes you just gotta break the rules...

    • I would have saved more time with that mentality. I have been stressing tooo many of similar details during my assembly.

      To be honest though, I am still learning so I think it was time well spent just because of that.

    • You should of course not start with breaking the rules and when you get shading artefacts then that needs to be resolved, but when you feel confident and know what you are doing, breaking rules can be very rewarding (not in XP's of course)!

  • Maybe something like this:

    Now I have to make one with the correct size, as this is just a test, made 'freehand' from looking at one reference picture...

  • Having another go at the 'housing'(?):

    Again just testing the geometry, sizes not correct yet.

    • These cast parts look so organic haha. I guess you can do that when the metal is a liquid and poured to fill the desired shape. They remind me a little bit of bones.

    • Indeed Shawn, it's organic hard surface modelling; that's what makes these parts so difficult, but at the same tome challenging!

    • I didn't post any WIP's for a long time, just didn't get much further; only testing things out, trying to understand the shapes and figuring out how to actually model them...

      But with the deadline being tomorrow , I finally started the real modelling today.

      Still quite a bit to do, but this is where I'm at now:

      I think the most difficult parts are done, but then again, you never know how hard something is to model until you actually do it;)

      Hope to get it finished tomorrow!

    • I have been enjoying Topology Studys by masterxeon1001 and it has made me understand crazy shapes on hard surface modeling a little better.

      This is definitely one of those crazy shapes that he was referring to.

    • blanchsb loved thoseTopology Studies. Learned a ton! Especially not to stress out about getting the perfect topology, just getting a better topology; getting better and better each time. You never stop learning!

    • So far...

      I think it looks heavy...

      Taking a small break now.

      I know these plates on top of the housing have holes in them, but that's where the fenders are connected and you will never see them unless you start disassembling the whole DOG...

      Speaking of fenders, adrian2301 they don't seem to fit...did I somehow mess up the scale?

      Also this:

      looks a bit different than your part, where it connects to my 'gearbox'....and not fitting either, but you didn't have my part yet, so...

      Anyway if you want to take a look:

    • This is some next-level low poly modeling spikeyxxx 

      The only area I wondered about was this area. Seems like this section transitions to the next piece very sharply. I'm not saying it is bad, per se, but I just noticed it when sub-D was applied and wondered what it looks like in edit mode.

    • I am loving this part!

    • Thanks Shawn! That whole housing part is not completey as I would like it, but that plate is supposed to be welded on top, but only on the front side:

      (at least that's how I read it) and I tried to simulate that effect...

      And that part in your second picture: yes! One of my favorites too! It was a struggle to model, but I am very pleased with how that came out!

      Although I see now that I have forgotten an edge loop/knife cut to get rid of those N-gons...but maybe that will destroy the look...I'll have to try that!

    • blanchsb looking even better now, thank you:

    • crew

      Fantastic job spikeyxxx! You're becoming a sub-d holding edge wizard. Lovely presentation lighting too 👍👍

  • Finally figured out why I couldn't get the hydraulic cylinder to fit (I think)!

    Need to do some clean-up on this side of the cylinder now, but it fits! I am so happy!

    Also will have to make the fittings and cables on the cylinder (which shouldn't be a problem),  or it won't be able to steer. But I have no idea where they will be coming from....

  • Okay, one more render:

  • It's the Sistine Chapel of Axles spikeyxxx 

  • Basic transitions with 'Subsurf':

  • Can you hear Ian Hubert explaining what is happening here:


    • crew

      Very cool way to show the whole process in one image. Not an easy thing to accomplish 🤘

      And yes I CAN hear Ian Hubert commentating this haha

    • I thought I commented on this. I actually saved it to my "modeling nuggets" folder where my Jon Lampel topology picture, and all quad junctions,  and a couple of other great references reside. You nailed it on presentation Spikey!

  • Haven't synced my Google drive yet. Uploaded a new version just now, hope that worked!

    Changed the shape of the axle a bit to fit this reference I only today discovered and also fixed some topology that was giving some pinching that annoyed me:

    Picture is a bit distorted, I was paying with the Focal Lenghth of the Viewport and forgot to set it back...

  • Finally found out how the steering cylinder is connected to the front axle:

  • Looking great spikeyxxx , a little dirt and some scratches and its done. 👍

  • Another piece done:

    Not 100% accurate to the reference but it looks good enough to me in the model:

  • A little bit of progress:

    and a render:

  • adrian2301 All seems to fit really well!

    Maybe we can connect the motor something like this:


  • Yes spikeyxxx that looks perfect. We should go with that, I like your joint better, I was unsure of that end so I copied the other end.

    I need to change my shade of yellow also.

    • I have read that CAT uses FFC500 for its yellow...

    • I can't get enough of your renderings, spikeyxxx . Looks to me so real that I want to grab into my computer screen in order to touch the axle 👍!

    • I replied to your question on the main thread spikeyxxx but with broken links it is in the middle on page 8 for now. FFC500 is good enough. I say let's go with it.

      It is a thing of beauty that is for sure!

    • blanchsb it's a good thing you found it...the question got buried so fast in that thread;)

      I was a bit unsure, because:

      1. there was another site that posted a completely different hex value (but this color looked more like it to me) and

      2. they gave this the RGB values of (255, 197, 0), which in Blender would mean a Green of about 0.77255, but typing in the Hex in Blender and then switching to RGB representation the Green is about 0.55834...

      So I checked and C5 is indeed 197 in decimal.

      The thing is that the Hex value in Blender is Gamma corrected and the RGB values are not!

      If you type in 7F7F7F in Blender,(which is 127 or 0.5) then you get a Value of 0.5 in the HSV (with some rounding error),

      but in RGB that gives (0.212, 0.212, 0.212)...

      In the 'old days' a Value of 0.5 in HSV would yield a RGB of (0.5, 0.5, 0.5), but at a certain point in time ('long' before 2.8) they changed that. Don't know why, but I remember Kent telling us this in one of his Shader Forge lessons..

    • I bet theluthier could explain it a little better. There must be a good reason why RGB got changed like that.

      I trusted the HEX values and didn’t even check the HSV after my RGB findings since I assumed it would not be reflected either. As long as I remember to use HEX I don’t think it is a deal breaker.

      Thanks for the explanation. Always worth my read.

    • crew

      I always sigh when it comes to Blender's colorspace technicalities. A few years ago they changed how colorspace was interpreted (at which point I submitted a bug to the devs about the 0.5 example Spikey mentioned) then filmic was made default... and I've never fully understood it since. Color gurus like Troy S make my mind explode with the nuanced specifics of digital color representation.

      The result for me is not getting too stuck on achieving a specific color based on hex values. I'll plug in the value we're discussing but adjust it to taste if it seems off. Lighting, material, color space, monitor calibration..it all affects color.

      Similar to what I tell my wife when she holds a paint color swatch up to the wall: Until we see the room fully painted we can never truly know if it's what we want or if the swatch is an accurate representation. Lighting deeply affects how our eyes perceive color and a swatch (or hex value) can't represent it fully.

    • The thing is, that nobody knows what color RGB  (0.237, 0.73, 1) is, because there are so many different RGB models!

      Let's just concentrate on what looks right to us..

      And VERY IMPORTANT: remember to take pauses and look at it again after 'a good night's sleep'...

      Things that look awfull, might look 'good enough' or even ' great!' when looked at with 'fresh' eyes!

    • crew

      Couldn't agree more with Spikey. Fresh eyes is a must! Great reminder

  • I thought I posted another render, testing a close-up of the hub:

    Must have forgotten to click the  'Add Reply' button..

    Experimented a bit with text...I think this will do...

    I really love how a few well placed holding edges can give this beautiful result...

  • adrian2301 I took the liberty and Appended your 'front' so that I could connect it to my part like so:

    This means that you can delete it from your file (superfluous remark: make a backup!).

    Or we could make it part of the motor and put it in your file if you want to (we both modelled half of this after all and I don't care whether it lives in your .blend or in mine...)

    blanchsb I changed my yellow to FFC72C, (which apparently is close to Pantene 123) because that looks a bit warmer to me and doesn't hurt my eyes so much...Tested it under different lighting conditions and it looks good. I think.

    Of course this isn't a real shader yet and with all the dirt and grease and damage that will probably be added this will look completely different, but as a working base color for now.... I'll post another render later on, so you can see it 'in action';)

    • That looks perfect spikeyxxx . Keep it in your file, I assume that's where it is now.

      When it's uploaded I can delete my part(s).

    • Done......

      And I have matched up the yellow.

    • adrian2301 I am quite sure that this is not where my hydraulic lines should connect to, but I have no idea where they should go.

      Anyway, this is where I'm at at the moment:

    • Yeah that's the fuel primer you have attached to, Not sure anyone will notice though.

      They do intersect with the chassis slightly, you might want to have a look at that.

      There is supposed to be a hydraulic tank behind the engine above the transmission, It's on order but may not arrive on time.

    • So somewhere here:


      I think I avoided collisions this time, at least with the engine and chassis...

    • That's it., spot on.

    • crew

      The teamwork on display is 💯

    • 'Finished' my tires that were still stuck in their block-out stage:

      This will look a lot better with actual shading, of course!

      I think I will call it good for now and get started on the port stash console...

    • Amazing work spikeyxxx . The axle turned out to be a real challenge, but you rose to it, and smashed it.

    • I feel like you could plop Axle from Twisted Metal on top of that and go around rampaging with those tires.

    • Just a fun little modelling exercise:

      but of course complete overkill! Made some adjustments on the tires; looks better now, I think:

    • crew

      Is that screw thing a single contiguous mesh??

    • Most of the Valve is one mesh, yes, just the metal ring and the cap are separate:

      Not even an actual screw thing, the windings are fake, they do not spiral, which is a lot easier to make and when it's on a small enough object with very 'shallow' windings, nobody will notice.

    • crew

      I'm impressed. The non-spiraling threads fooled me. Vertical and lateral threads in the same mesh is not easy. You're a topology wizard, sir 💪

    • One more piece:

      that is hiding out here:

      Some statistics included; the wheels have about the same amount of Vertices as the axle.

      The second image is with the 'new' Viewport Denoising, which is horribly slow on my machine (can't use GPU, it's too old), but still very impressive for 4 Samples!

    • I really like this hidden part 😀👍! It should be animated!

    • 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.

      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....

    • crew

      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?

    • Thanks a lot jlampel  !

      blanchsb oops, that should be 2.79...

      There is no, and will never be a Blender 2.97; the latest daily is 2.91 and after 2.93 LTS it will jump straight to 3.0.

    • 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

    • crew

      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!)

    • And yes, the twelve times twelve monkeys was deliberate;)

    • 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?

    • crew

      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..

    • crew

      @spikeyxxx That's interesting...hadn't thought much of hardware differences. You're probably right. My PC is about 1.5 yrs old. Still I would expect the principle to hold truer than the opposite results 😅

    • I'll take a look on my new Lenovo Laptop and see how it handles a similar test on my blender version.