On 15/11/2015 at 08:52, xxxxxxxx wrote:
Cinema 4D Version: 16
Platform: Windows ; Mac OSX ;
Language(s) : C++ ; XPRESSO ;
In the linked scene file there is the following setup:
1. A mesh being deformed by a Skin object.
2. A Spline object with its points being positioned by control Null objects through an Xpresso tag.
3. One of the control Nulls is being clamped to a mesh point by a Constraint tag.
If the Spline object is the active object and the editor is in points mode, the scene works as expected. If the Editor is in object mode, the Spline lags during animation playback. My first goal is to get rid of the lag regardless of editor mode or object selection.
I have tried to create an ObjectData plugin that generates a Spline where I included Texpression in the .res file. I have tried many different Priority settings and cannot get rid of the Spline's lag.
Is there a way to configure an ObjectData plugin that generates a spline where I can control the Priority?
My end goal is to use the Spline Deformer in a character rig where I'm implementing a cage and a Mesh Deformer. The Spline's point positions will be driven by the cage. The Spline Deformer will deform another mesh being deformed by the Mesh Deformer.
I'm open to any suggestions except point caching because that will not work for the client/animator.
On 16/11/2015 at 07:24, xxxxxxxx wrote:
while I have not been able to solve your problem with playing around with the priorities in your scene (it seems as if there's a refresh missing and I can't eliminate the possibility of a bug in Xpresso), I think I have a solution for you using a Python tag.
In your scene simply replace the Xpresso with a Python tag.
Create two User Data on the Python tag. First (ID 1) an integer, which will define the spline point to be influenced. Secondly a Link box (ID 2), where the Null object (or any other object) gets thrown in, which defines the position of the spline point.
Then use the following code for the Spline tag:
def main() :
sp = op.GetObject()
if not sp.CheckType(c4d.Ospline) :
print "Error: Attach to spline"
idxPoint = op[c4d.ID_USERDATA, 1] # User Data ID 1 is an integer
ref = op[c4d.ID_USERDATA, 2] # User Data ID 2 is a link
if ref is None:
print "Error: No refernce linked"
if idxPoint < 0:
idxPoint = 0
lastSplineIndex = sp.GetPointCount() - 1
if idxPoint > lastSplineIndex:
idxPoint = lastSplineIndex
op[c4d.ID_USERDATA, 1] = lastSplineIndex
newPos = ref.GetMg().off
#print ref.GetName(), " influences spline point: %d" % idxPoint
#print " New pos:", newPos
sp.Message(c4d.MSG_UPDATE) # make spline aware of point change
c4d.EventAdd(c4d.EVENT_NOEXPRESSION) # NOTE: EVENT_NOEXPRESSION is needed,
# otherwise EventAdd causes reevaluation of scene
# (and tag being executed endlessly)!!!
On 16/11/2015 at 08:57, xxxxxxxx wrote:
Thanks for checking this out for me.
Revised scene file:
The revision to the scene does not appear to fix the problem for me.
In my humble opinion, it has something to do with a priority issue between a skin object and how a spline is generated.
Also, it is curious that the spline is generated without lag when the editor is in points mode and the spline is the active object.
Does the priority change for a spline object when its active representation is drawn in the editor? It appears that an inactive spline is drawn with less detail than an active spline. L.O.D. calculations?
Here is a link to a scene where the spline's control null is parented to the joints tip with a constraint tag:
The spline is generated without lag. This setup will not work for a character rig as I need to get point locations from a cage mesh.
Please let me know if you have any other suggestions.
On 16/11/2015 at 09:40, xxxxxxxx wrote:
I checked your splinelag_01.c4d.zip scene, and it seems to work for me. I agree, it might look as if there's some drag, while moving the power slider (the slider below the viewport), but as soon as I release the power slider, the spline hits exactly the tip of the cone. And so it does, if I jump to an arbitrary frame or when the scene is being rendered.
On the other hand, I agree, that the lag during usage of the Power Slider is strange. And so is the difference between object mode and point mode with the spline selected. I'm looking into it...
On 16/11/2015 at 09:45, xxxxxxxx wrote:
Forgot one thing:
I don't think, it is related to the skin and the spline object. Instead, I think, the Xpresso or Python tag, which in your scenario needs to be run below Generator priority (higher prio value, meaning, it is actually handled after Generators), is leading to this strange behavior. But that's still guess work, as I said, I'm looking into it.
Cool. Thanks Andreas.
On 16/11/2015 at 10:51, xxxxxxxx wrote:
I have tried many priorities and stacking orders with no success. Perhaps I have not stumbled across the magic combination. I was hoping you could take some of the magic out of it for me.
Since we are on this topic:
Does object manager order take precedence over priority settings in the attribute manager?
On 20/11/2015 at 09:42, xxxxxxxx wrote:
no, priorities precede Object Manager order. Only if two entities have the same priority, the order in the Object Manager comes into play. Actually the priority settings are there, so you are not dependent on Object Manager hierarchy alone.
By now, I have talked to several people about this issue and I'm afraid there is no real solution.
The reason is, that the Skin Object (despite its priority setting) is a Generator like all other deformers and thus runs on Generator/0 priority. The Spline Object is a generator as well, equally running on Generator/0 priority. In your setup, you need to read values from the Skin Object (so you would want to run on Generator/1 or higher to read the latest generated values) and on the other hand you need to feed these values into the Spline Object, which of course should happen before it is generated, latest on Generator/-1. So you basically need data earlier than you can get it... Unfortunately this situation is not really solvable in the current system.
I still think, my Python tag version may be a workaround, but of course it heavily slows down a scene (due to double evaluation) and it still has the drawback of the "virtual" viewport lag. Virtual, because I think, it is only noticeable, while user interaction (dragging a slider), but it should actually work during rendering.
On 20/11/2015 at 20:49, xxxxxxxx wrote:
I think the real issue is when ObjectData::GetContour() is called. After further testing, I think using PriorityList::Add() in ObjectData::AddToExecution() does not change when GetContour() gets called. It only changes when ObjectData::Execute() is called. So having a higher priority than 0 makes Execute() get called after GetContour(). Having 0 or lower makes Execute() get called before GetContour(). Of course this is only another guess on my part.
There should probably be one more level( EXECUTIONPRIORITY_FUBAR ) added to the pipeline that only plugin developers can use to pick up the pieces.
After some research I found out that Cactus Dan had this figured out years ago. It appears that his CD Skin tag is called early in the pipeline and you can use it to rig with greater flexibility.
Thanks for your time Andreas.
On 23/11/2015 at 12:19, xxxxxxxx wrote:
yes, that's exactly the point. With the priority you can only influence, when Execute() is called, GetContour(), GetVirtualObjects() and ModifyObject() are not influenced by the priority.
Unfortunately another priority level would be no solution either. As in your case you would need to get in between ModifyObject() of the Skin deformer and GetContour() of the Spline object.
Perhaps Cactus Dan reads this thread and could shed some light. I'd be interested, how he pulled it of.
On 23/11/2015 at 12:51, xxxxxxxx wrote:
not sure if this will work, did you try correction deformer?
you have a cage object, which got a rig, this cage object is used inside a mesh deformer.
++skin_deformer (or any deformer)
in a typical case, this may lag at some point "happened a lot here"
what I usually do:
++mesh_deformer(using your correction_cage)
use correction_spline deformer as your input, it shouldn't lag.
just tested your scene and it didn't work with the clamp constraint, so it didn't work.
On 23/11/2015 at 13:17, xxxxxxxx wrote:
Since I'm obviously not grasping the concept of EXECUTIONPRIORITY, I have a few more questions if you have time to answer:
1. Why does a deformer object need to be called at EXECUTIONPRIORITY_GENERATOR? Why cant it be called at EXECUTIONPRIORITY_EXPRESSION?
2. If I want to change the position of an object's points with a plugin, does that plugin have to derived from ObjectData?
Thanks again for your time and patience.
On 23/11/2015 at 13:21, xxxxxxxx wrote:
Thanks for taking a shot at it for me.