PDA

View Full Version : Xpresso details


Kuroyume0161
04-16-2006, 05:04 AM
Before taking the drastic step of making my own master/slave control system (why am I always forced to construct everything from scratch?), there are a few questions on Xpresso that will aid in my decision to go forward with them or not.

1. What is the order of evaluation of Xpresso tags? Is this the same as objects/tags - objects top to bottom, tags left to right? I've had success with controls going forward in the hierarchy and backwards, but this may just be a case of simple chaining.

2. Is there any way to have cross-controls, such as: A->B and B->A. I note that when I setup, for instance, the left and right eyes to control each other's Y rotation, only the one eye's control seems to work while the other eye's control does nothing (the slider value just jumps back to default).

3. Chaining of controls through different Xpresso tags. For instance, you have a master in the root bone and slaves connected to this in succession (slave->master): Head->Neck->Chest->Body. The idea here is that a slider on the Body is controlling a cascading sequence of slaves. Can Xpresso really handle this as I've had mixed results?

I'm going to say this, but take it in light of what I'm trying to accomplish. Poser's master-slave system, albeit not as sophisticated as Cinema 4D's Xpresso system, is definitely much more flexible in setting up any combination of relationships. Although the Poser 'valueOpDeltaAdd' (slave + (master * constant)) is used almost exclusively, the system supports multiple masters per slaves, multiple slaves per master, and cyclical connections (without contention (?)). Xpresso does not seem to be capable of handling this flexibility. Neither chains nor cyclic controls are responding.

Thanks,
Robert

Srek
04-16-2006, 10:04 AM
1. The order is of execution for all Xpresso Tags with the same priority is from top of the OM to bottom and from left to right.
2. Yes, but since every expression is only executed one time per refresh (frame/subframe) the last expression will override all previously executed.
Example: A changes B, B changes A. The change to A will only have an effect on B in the next execution (frame/subframe).
3. Yes it can, you have to observe oder of execution and if neccesary adjust it via priority settings.

Cheers
Björn

Kuroyume0161
04-16-2006, 08:02 PM
1. The order is of execution for all Xpresso Tags with the same priority is from top of the OM to bottom and from left to right.

As expected, thanks! :)

2. Yes, but since every expression is only executed one time per refresh (frame/subframe) the last expression will override all previously executed.
Example: A changes B, B changes A. The change to A will only have an effect on B in the next execution (frame/subframe).

I should call them more or less 'coupled'. Is there any way to do this sort of coupling with Xpresso so that either A changes B or B changes A irrespective of execution order?

3. Yes it can, you have to observe oder of execution and if neccesary adjust it via priority settings.

That could be difficult. Would require that I not only parse and construct the node equivalents for these master/slave connections, but also somehow deduce the pattern of operation (F is affected by E is affected by D etc.). Some of these 'figures' have hundreds or thousands of master/slave connections and, again, 'branching' is allowed. So a terminal slave could be controlled by another slave-master which is in turn controlled by several slave-masters which in turn splits off to all of its masters. And since forward and backward chaining is allowed, well... Fun, isn't it? :) Determining priorities could get complicated very fast.

Any links to algorithms/code for master/slave control systems?

Thanks,
Robert

Darter
04-16-2006, 09:40 PM
I should call them more or less 'coupled'. Is there any way to do this sort of coupling with Xpresso so that either A changes B or B changes A irrespective of execution order?

This can be done by arranging the nodes correctly in the X-Manager. In the attached file, the heading of the cube drives the heading of the pyramid and vice versa. However, this only seems to work correctly when using rotation handles. Accessing heading via the HUD makes things go wonky.

Srek
04-17-2006, 08:22 AM
If you work with memory nodes to compare current and previous states you should be able to do this.
Cheers
Björn

Kuroyume0161
04-17-2006, 07:44 PM
This can be done by arranging the nodes correctly in the X-Manager. In the attached file, the heading of the cube drives the heading of the pyramid and vice versa. However, this only seems to work correctly when using rotation handles. Accessing heading via the HUD makes things go wonky.

Okay, I've look at your example, but I think the scenario is unlike what I'm dealing with. Now, theoretically, I could allocate one XPresso tag for the entire figure and put all of these master/slave connections within it, but it would be a bloody mess. For instance, Hiro3 has 542 of these (each with between 2 and 6 connected nodes, depending upon the optimizations that my code can employ) and this is probably a midrange example for some of the more complex figures.

What I'm doing instead is allocating an XPresso tag for each slaved slider on a 'bodypart' (represented by a plugin object) and putting the nodes in there. This could be reduced by clumping all of the slaved sliders into one XPresso tag on the bodypart, but keeping the node 'groups' (not real group nodes) from stacking would require some care.

It appears that putting all of the slaved sliders for a figure into one XPresso tag may alleviate the contentions but there would definitely be a need to employ group nodes to somehow corral the mess into something visually and organizationally less chaotic.

If you work with memory nodes to compare current and previous states you should be able to do this.

Do you think that this would still be required if what I'm suggesting is tried ala Darter's example?

Forgot about this question related to clumping all of the controls in one XPresso tag: Does the order of node groups/grouped nodes in the XManager make a difference and what would be the criteria?

Thanks,
Robert

Kuroyume0161
04-18-2006, 03:25 AM
No change with clumping all of these into one XPresso tag - it appears that sliders are handled differently than standard PSR - still the contention exists as when separated.

Srek, can you post an example of how to utilize the Memory node for this A<->B situation? I'm definitely no XPresso wizard - like you. :) Thank you very much so far!

Should also mention, as it may have relevance, that these sliders have tracks/sequences/keys. Could this be part of the problem?

Robert - who needs to update avatar.

Kuroyume0161
04-19-2006, 01:40 AM
Looks like I may be on my way to writing my own master/slave system here. Two points of interest concerning Poser's master/slave system:

1. Master chaining. In a Poser file, you can have multiple 'valueOp' operators on a single bodypart channel. The way these work is by chaining from top to bottom. The general scheme is this:

result = (...((((c op1) op2) op3) op4) ... opN)

where c is the constant value of the slave channel (more of this in 2.) and each op is an operation including the master value. As you see, each subresult is fed into the next operation. This is easily accomplished with XPresso nodes, but the situation is not resolved...

2. Initially, I thought that 'initValue' (a true constant) was fed as the constant value, but it turns out that it is the actual 'dial' value (stored in the 'k 0' key). If you can see the problem, it involves the way XPresso nodes are affecting the sliders and how Poser doesn't. In Poser, when the user sets the slave dial value, this becomes the new constant value, but master affects do not change the dial value so that this value remains constant, the result is fed directly into the process beyond the dial. Since the XPresso nodes directly affect the slider values (per my current setup), this scenario is not preserved. Now, it may be possible to get around this somehow by having the slave node port be some other description on the tag representing the dial/channel.

Even if I go with my own master/slave system, it will be difficult to distinguish user-set and file-set constant values on the slave slider from those caused by masters or keys through masters.

Robert

Kuroyume0161
04-22-2006, 11:07 PM
Okay, I've found a way to continue to use XPresso nodes for the slaving. What I've done is create a chain of nodes, starting with the constant (slave slider value) but ending with a Real description element (slave result) and not the slave slider. This slave result then supercedes the value on the slave slider in the areas where the values are being applied (transforms/morphs/other slaves). This is working so far (haven't had a change to thoroughly test this yet).

The problem is that when the master slider value is changed, the slaves are not updating. Yes, I am calling a method (from SetDParameter()) that starts the ball rolling as it were. First, the master does its update if any and then it calls all of its slaves with the same method so that they should update from the 'supposedly' XPresso-calculated slave result (and this continues down the mater-slave chain). But it doesn't seem to do anything unless you wiggle the master slider (get another change). I've tried AnimateObject(), AnimateDocument(), EventAdd(), SendMessage(), and a couple of other more eccentric ideas - nothing. The real problem is that this is putting things out of synch - especially morphs which are applied directly to the mesh and therefore must have the previous value for a delta determination. Once the morphs are out of synch, there is no way back.

Srek, are you going to chime in here with the 'use Memory node' solution (in more detail)?

Thanks,

Robert

Srek
04-23-2006, 08:23 AM
Hi Robert, sorry i'm pretty busy right now and what you are looking for would take some seriuos time to find an elegant solution. I doubt that i can provide on any time soon.
Cheers
Björn

Kuroyume0161
04-23-2006, 08:40 AM
Working on 9.something? ;) Cool.

My intuition is that when the master slider is changed and calls SetDParameter() on my plugin object to set the value (etc.), the XPresso nodes have not been evaluated yet. The problem is that there is no way to force them to do so. I've tried placing the XPresso tags on the top/root object of the document with 'Initial' priority set to -499. That's about as 'do me first' as you can get, but the issue still remains. And again, all of the Message(), Animate(), Event() prods have been tried in various locations.

Yes, elegant solutions seem to be lacking... :)

What is interesting is this (if you find time or can pass this on): each slider has an "Edit" button which opens a modal dialog for changing parameters of the 'dial' slider. If I edit the value there and say "OK", the slider value changes (as expected) ... ah, but the slaves react properly. I'd love to know what that triggers that everything else (sometimes in excess) cannot.

Since you are 'busy' (for good reason one suspects), I may cart this over to PluginCafe while experimenting continues.

Thanks,
Robert

Srek
04-23-2006, 08:46 AM
Since you are 'busy' (for good reason one suspects), I may cart this over to PluginCafe while experimenting continues.
Currently it's mainly wrapping up 9.6 and MoGraph so you all can get to play with the new toys. You won't believe how boring it is to test installers/updaters :/
Thanks for your understanding :)

Cheers
Björn

Kuroyume0161
04-23-2006, 08:54 AM
Currently it's mainly wrapping up 9.6 and MoGraph so you all can get to play with the new toys. You won't believe how boring it is to test installers/updaters :/
Thanks for your understanding :)

Cheers
Björn

I understand completely. You should see what it takes to test every Poser figure that I have installed when a major feature is implemented in this mess of mine - one to two 16-hour days of loading and noting issues. So I can sympathize. :)

Good luck and can't wait to see the update!

Robert

P.S. (I.E.: how to make Srek's mind wander): I have a Harley SoftTail FatBoy (although it is having battery recharging issues currently). I see that you are a motorcycle afficianado. That Honda F6C is one interesting bike. :)

CGTalk Moderation
04-23-2006, 08:54 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.