Thanks for the file, nose-show (No idea either, but you can change that)
The IK chain that you have set up misses the Pole, which can be used to rotate the Chain. The Target (Ziel) is the main object to move anything besides the Pole in IK mode. The Joints are not touched when in IK mode.
If you want to rotate the joints, go into the IK tag and use the IK/FB slider to move it to the right to be out of IK and entirely in FK. Now you can rotate the Joints individually.
Invert kinematic and Forward Kinematic in opposite directions.
The algorithm finds the best solution in IK mode based on the Pole and Goal. Any other influence will create, more or less, chaos.
I would not use the Protection Tags in such a chain.
As a side note, the Group Nulls under each Joint is not centered on the Joint. Otherwise, this Null could be used to rotate the element; of course, it would not affect the ones below, and that would be another step.
It's great that you found something that works for you.
I had to ask if there is perhaps something new to make that happen, but no external MoGraph Cloner will read the content of the Scene Editor. With this, the Fields question for this purpose was answered.
I hesitate to reply here, as it would look like production is ready and a must-have option.
So far, it is more for developers who might draw from their knowledge of Python to use this more graphical interface to set up fun-to-use Capsules.
When it goes mainstream, I will invest more time into it.
Thanks for your patience and openness to alternatives.
Perhaps tune in tomorrow to the Ask the Trainer show and place some of the questions there. I had a chat this morning with Noseman about it.
this happens on windows, if the system display/scale setting is set to greater than 100%.
it results in viewport renders being rendered pixelated, regardless of AA settings.
if you render to PV, you don't see/get this.
(see png) https://drive.google.com/file/d/1iz3Dsd9D4VFN7Yi3loF6r27wDOwsLSz7/view?usp=drive_link
(standard render : AA @ 2x) should not look like this, but it does.
This started happening several versions back. I did report it.
you won't see it on a mac, and you won't see it on win at 100% scale.
The idea of Instances is simple: calculate on Clone and have the data, not the object for the render engine.
Screen Shot 2024-01-29 at 11.08.09 PM.png
Perhaps there is an idea to place the SDS as a parent on a Cloner, but if one could use the SDS on the Clone Child before it is Cloned, the SDS would have to deal with one object only, not with many.
In other words, if there is no urgent reason, SDS before Cloning. It will save you a lot of time.
If possible, use the
Mesh> Add> Subdivide * > Smooth ( the * means, use the cogwheel)
To my knowledge, Redshift 3D doesn't work with the Camera Shader.
The question would be, can you provide an example scene? (If over 1MB/c4d, then please use Dropbox, Wetransfer, Google, Apple, or Adobe Cloud download; I do not touch other sources here. Please no rar compression)
If it is a part of the scene, you need to render it out and then use it—yes, an extra step. Perhaps when I can see what is needed, I might have a different suggestion besides that.
Yes, any object visible from the camera will show the world's position.
You want to move the camera, which will stabilize this information on non-animated objects.
What you need to make the particles invisible is the data that is not shown, the "Viewing Shadow."
While the camera moves, the parts of an object that is visible to the camera change. You can calculate the distance between the camera and the Object. Since you don't get the particle's position, you get nothing more than a 2D idea of the camera-object relation.
Let's say you have that particle position; you would be able to obscure all the particles behind objects, but what about particles that would bounce into objects, like the front round part of the cylinder? Where do the particles go when they become invisible, through the Object, and then become visible again later? Typically, they bounce, which needs complete information on all parts.
Is that creating a more precise "picture" of the problem?
FBX is old but pretty robust. However, simplifying the data has often shown a good effect.
There is typically an option to have the Object run by the joints in place or independent of the location.
This would have been my next iteration to explore with you, as I'm unfamiliar with your target app.
I'm not aware of any default solution for this. Nor has anyone ever asked in the past ten years to connect this rig with MoCap data.
When you check all the FK Joints, the number of Constraint Tags that rule over those would prevent using them quickly.
IK and FK are the feed for the Bind Joints, meaning that if you need to overwrite anything, that would require a lot of change.
Using only the Controller to transfer would also not work. So, creating that definition would be a lot of sorting through. Yet, again, the typical Motion capture would not provide all the needed information to run it. Which leaves a lot of manual work along the way. I haven't seen a MoCap from anyone here that would contain all the details, which is even more valid for the Toon rig/character.
I can only suggest opening a ticket with the needs that you have. "Share Your Ideas"