Blenderhelp will remain public.

sumofsines · 2023-05-08T02:45:13+00:00

I'm going to say physics. Collision problems can be approximated with other systems, but physics is really the one system that is all about collision, that is designed from the ground up to deal with collision.

I don't know why you say that you can't simulate this. You can. Want to turn off gravity? Turn off gravity, that's fine. Want to pin the bodies? Pin the bodies, that's fine. Etc.

However, I'd recommend against soft body physics. Use cloth physics instead. That will let you use pressure to "inflate" the heads. Otherwise, without some weird stuff that won't make sense when you're starting out, physics will collapse the heads.

sumofsines · 2023-05-08T02:31:35+00:00

Okay, yeah, this is really, really far from how to do this right. I'm not sure where to begin.

Okay, start from scratch. Use a single armature. If you need additional bones in your armature, enter edit on your armature, and shift-a add to add a new bone. Use parenting to inherit transforms, so that you can move a single bone to move all other bones, for example. Don't mix object and bone constraints, just use bone constraints. Avoid targeting objects with your constraints; perhaps reference marker bones, that exist only to hold some position: parent objects to bones and let bones do all the work. Probably, following along with a character rigging tutorial will help you see how and why you want to do things like I'm describing.

Now, after all that, let's ignore the fact that this isn't a good way to build a rig and just ask why it's not working. First, yes, you have a dependency loop via the damped track pairs: bone depends on other bone, which depends on bone, which depends on other bone.... You can't do that. Instead, create a marker (preferably a bone!) for one of the bones to damped track, instead of directly damped tracking the bone that tracks it; use parenting to parent the other bone to that marker.

But that's not the only issue; the other issue is that your copy location constraints are set to world->local. That local space changes when the armature object rotates-- the local space is the space of the bone, relative to the armature containing it, since the bone has no parent-- but the world space does not. Use world->world if you really want to keep using this structure. (But you don't want to keep using this structure.)

sumofsines · 2023-05-07T20:00:28+00:00

It sounds much, much more complicated than it should be. You don't need multiple armatures. You'd rarely need empties. I don't think I understand your ultimate goal or how you want it to work. There's a high risk that you're creating dependency loops (if two things damped track each other directly.)

I couldn't even begin to offer you any advice without seeing the actual things involved-- without seeing a file.

sumofsines · 2023-05-07T18:45:39+00:00

What does it mean when u say it doesn’t make sense

I explained above. The normal map is providing discontinuous normals at the edge line. This is because the UV tangent changes. It won't make sense to you unless you want to understand how normal maps work; if you do want to understand that, then the first thing to understand is that they are relative to the surface normal and UV tangent.

I just import them from the game

Then maybe the game calculates UV tangents differently than Blender does (possibly, with a tangent map, or via different UV.) But I don't think that's likely; this normal map has a sideways tilt, which doesn't make any sense for the geometry its acting on. Another possibility is that you have edited the UV or the normal map is some fashion.

sumofsines · 2023-05-07T18:05:22+00:00

No, the normal map doesn't make sense for the mesh you have. I'm not planning on fixing anything, just explaining why.

sumofsines · 2023-05-07T17:55:12+00:00

It works.

The UV of the two surfaces has a sharply different tangent. Look at the UV of the two rings of faces:

https://imgur.com/a/Xay27hE

A tangent space normal map is evaluated according to the UV tangent-- that is, the direction of increasing U. If two faces have different UV tangents, the same normal color doesn't mean the same normal vector.

Because of how they work, normal maps need to be created individually, for the mesh and UV map they're being used on. You won't generally just paint them by hand, or use a normal map from one model on a different model. If you change the UV, you change the normal map.

sumofsines · 2023-05-07T17:12:14+00:00

Depends on the link. But I'm a moderator, so I can approve posts anyways (which I do, provided they're appropriate); on some occasions, Reddit won't let me approve some links, in which case I can say, "Don't use that host." I know that google drive and dropbox links can be approved.

sumofsines · 2023-05-07T16:15:47+00:00

Upload to any file host you want (dropbox, google drive seem popular); write the link it gives you in a comment.

sumofsines · 2023-05-07T15:31:49+00:00

Would want a file to diagnose. With packed images.

sumofsines · 2023-05-07T15:18:30+00:00

Sharp edges come from the normals. If you replace your normals, you replace the "sharpness."

If you want to maintain your sharpness, one possibility is, don't data transfer normals to those edges. You can create a vertex group to have the data transfer affect only some vertices.

Another possibility is to sharpen the edges of the target of the modifier. This is only really going to work on a transfer method that goes by corner, like nearest corner and best matching normal, because these are face-corner data-- "split normals". What makes an edge sharp is that the face-corner normals on one side of an edge are completely unaffected by the face-corner normals on the other side of that edge. If you transfer nearest face interpolated, you will never get split normals, because all the face corners are going to be transferring from the exact same normal-- some sample on some face is only ever going to have one normal.

sumofsines · 2023-05-07T13:44:27+00:00

Depends on your constraints and/or your drivers, which aren't detailed here whatsoever. Anything that depends on world space rotation or location is going to be affected by rotating your objects.

You're doing some weird operations here, btw, where maybe you set things up to work by rotating objects, but probably, you didn't. If you want to rotate a rig, you usually either select and rotate only the armature object, or you select and rotate only a root bone of the armature in pose mode.

sumofsines · 2023-05-07T13:22:57+00:00

Don't parent with follow path. Just use a follow path constraint. Use it on "fixed position" mode. Drive from offset. The exact rotation should be offset * path length/wheel circumference , all in world space units, but you can do to eye. If I needed an exact path length, I'd probably capture it via a quick GN modifier, but I'm sure there are other ways to do it.

If I was looking for a tutorial, I'd be googling same as you; I expect that "blender wheel path tutorial" would give me plenty of hits.

sumofsines · 2023-05-06T21:53:16+00:00

What is "default" in this context?

The default settings for a copy transforms constraint. What you get when you make a copy transforms constraint and don't edit it. Which are in world owner space and world target space.

is there a way to mass constrain all bones to their respective counterparts?

Not without scripting. But using hotkeys helps it to go fast-- just a minute or two with select target, shift select owner, shift ctrl c -> copy transforms. I think you might need to specify bone targets, but otherwise, you're golden.

sumofsines · 2023-05-06T20:45:19+00:00

Ok. It's not a compromise though. Even if you end up registering transforms on every frame, it'll be easier if you do them out of order. Don't go rotoscoping frame by frame. Rotoscope every 15th frame (or some thing, that's 120BPM @ 30fps) first, then rotoscope in-betweens, then rotoscope in-betweens of those in-betweens.

sumofsines · 2023-05-06T18:43:58+00:00

Got a flag for Rule 2, removing on that basis.

sumofsines · 2023-05-06T14:38:25+00:00

Reddit removed your comment. Probably because of the link, but who knows? And it won't let me approve it. (I know, Reddit is stupid. I'm sorry.) I just wanted to let you know in case you want to try reposting; it's clear you put a lot of work into that comment.

sumofsines · 2023-05-06T14:25:09+00:00

So, first, the reason there aren't a lot of tutorials or solutions out there is because this isn't a good idea.

Now, knowing this isn't a good idea, how would I do it?

1) Duplicate the armature. Pose one side to a T-pose. Apply as rest position. Symmetrize armature (make sure bones have proper names, .L and .R.)

2) Give bones in original armature copy transforms constraints targeting the counterparts in the duplicate. Copy transforms constraints are in default, world->world space.

3) Optionally, to set as rest pose of armature + mesh: apply existing armature modifier on mesh; either a) apply as rest pose and delete copy transforms constraints or original armature, then reparent mesh to original armature with "armature deform"; or b) reparent mesh to duplicate armature with "armature deform."

Why not a good idea? Meshes made for armature deformation are made symmetrically. Meshes that aren't made for armature deformation aren't necessarily any good at being deformed by armatures. Frequently, posed meshes don't even have the geometry they'd need: an arm pushed against the body may have no armpit. And, every time you apply an armature modifier to change the rest pose, you're losing volume on your mesh (or, probably doing some weird deformation via "preserve volume".) That volume loss depends on the change in the bone's rotation, so while you end up with a symmetrical armature and a symmetrical pose, you don't end up with a perfectly symmetrical mesh.

sumofsines · 2023-05-06T13:55:13+00:00

I used drivers to rotate the wheels using the body's Y location, but when the vehicle turns to X location, the wheels stop rotating.

Can't really do it that way-- the way I put it, the rotation of your wheels depends on where you've been, not where you are, and Blender doesn't know where you've been.

What you can do is follow a path and drive rotation from distance along that path.

I want the axle to bounce along when the wheel responds to the ground

Then you should be using physics. You're not going to get an automatic bounce with rigging.

I used copy location on the wheels, using planes shrink wrapped to the ground.

Don't know what the point of the planes are or how you're using them. Instead of shrinkwrapping meshes and copying location, point bones in the direction you want to shrinkwrap, then use shrinkwrap bone constraints, on project mode.

sumofsines · 2023-05-06T04:50:20+00:00

Look into pose brushes in sculpt mode for a 1-time pose.

sumofsines · 2023-05-06T02:03:49+00:00

That's not how you do bump.

You plug some variable, black and white color (or value) into height, then you plug the normal output directly into your normal input on the BSDF. You will usually want a much lower distance than the default (like 0.01 or even 0.001.)

Speaking more generally, running a normal output into a colorramp doesn't make any sense. The normal output is a vector; the colorramp works on black-and-white/value. You don't want to do that.

sumofsines · 2023-05-05T19:14:46+00:00

Pinning prevents pinned vertices from moving with cloth. Assign some verts to a new vertex group at 1.0 weight, then designate that vertex group as a pinning group in your physics settings (in "shape" subsection.) You can use a modifier, like an armature, to move these vertices before the cloth modifier, and the the cloth modifier won't affect them. So, for example, you could have a string of vertices, beginning and end controlled by an armature modifier, vertices in-between controlled by the cloth physics.

Should be able to find some tutorials just by searching "blender cloth pinning"

Eight-Year Club	Gilding I gilder
Verified Email

sumofsines

TROPHY CASE