ObjectData Spline Priority
-
On 16/11/2015 at 09:40, xxxxxxxx wrote:
Hi Joe,
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. -
On 16/11/2015 at 09:45, xxxxxxxx wrote:
Cool. Thanks Andreas.
-
On 16/11/2015 at 10:51, xxxxxxxx wrote:
Hi Andreas,
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?Much Thanks,
Joe Buck
-
On 20/11/2015 at 09:42, xxxxxxxx wrote:
Hi,
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:
Hi Andreas,
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.
Joe Buck
-
On 23/11/2015 at 12:19, xxxxxxxx wrote:
Hi Joe,
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?
edit:
you have a cage object, which got a rig, this cage object is used inside a mesh deformer.old Hierarchy:
+your_cage
++skin_deformer (or any deformer)+your_spline
++mesh_deformer(using your_cage)in a typical case, this may lag at some point "happened a lot here"
what I usually do:
+your_cage
++skin_deformer
++correction_cage+your_spline
++mesh_deformer(using your correction_cage)
++correction_splineuse correction_spline deformer as your input, it shouldn't lag.
edit 2:
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:
Hi Andreas,
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.
Joe Buck
-
On 23/11/2015 at 13:21, xxxxxxxx wrote:
@ MohamedSakr
Thanks for taking a shot at it for me.
Joe