The scroll bar in the details view resets to the top whenever changing frames or parms that affect information being shown.. Man is that frustrating.. especially when you have a desktop with a thin details pane in it. Say you want to monitor your values in the vel field under an objects position data.. It's way at the bottom and when you want to either scrub back and forth or just compare one frame to the next, the dang window jumps right back to the top.. I would really like to see it just stay where it is while working so i can monitor whatever it is i need to.

Also, this is just a suggestion, but I would also change the default data name parm on solvers to “`opname(”.“)`” instead of “Solver”.. i realize i can set it as a permanent default myself, but I don't see why it wouldn't be a good idea to do this from the begining.. “Solver” just doesn't cut it when hunting things down in the details view..

The issue with the Dtails View scrolling on it's own is already in our database. However if there is a specific value you are monitoring, select that value in the tree view. That value should remain selected and in view even as you play the simulation.

The reason for the name “Solver” on all solvers is that DOPs finds the solver to use for an object by looking for the data named “Solver”. If you attached an RBD Solver to your objects but give it the data name “foo”, your objects won't solve.

I'm not sure what you mean about hunting things down in the details view. What is it that you're trying to find, and how would having a different name for the solver data help? If you are trying to find all objects which are using a particular solver, I would suggest naming your objects so that they give an indication of what solver is being used on them (e.g. the object named clothobject probably has a coth solver attached to it). Would this not accomplish the same thing?

Mark

The issue with the Dtails View scrolling on it's own is already in our database. However if there is a specific value you are monitoring, select that value in the tree view. That value should remain selected and in view even as you play the simulation.

Yup, a selected value in the tree stays no matter what, so that's atleast a good thing.. Maybe we should be able to select/highlight specific properties and it could stay with that as well.

The reason for the name “Solver” on all solvers is that DOPs finds the solver to use for an object by looking for the data named “Solver”. If you attached an RBD Solver to your objects but give it the data name “foo”, your objects won't solve.

Hmm.. wasn't aware of that.. But i just did this and it was fine.. Simple RBD Object->Gravity->RBDSolver->Merge with ground plane.. Data name for solver was set to “foo” and nothing seemed to break.. Unless I'm missing something.. :?

I'm not sure what you mean about hunting things down in the details view. What is it that you're trying to find, and how would having a different name for the solver data help? If you are trying to find all objects which are using a particular solver, I would suggest naming your objects so that they give an indication of what solver is being used on them (e.g. the object named clothobject probably has a coth solver attached to it). Would this not accomplish the same thing?

Yes, naming objects according to solvers is appropriate but I guess I was more so getting at a single object with multiple solvers attached to it rather than the other way around. For example, say I have a RBD solver and a SOP solver piped in to a multisolver dop that is attached to an RBD object.. If i go to that specific object in the Details View, I get two identically named “Solver_multisolver1” entries with the only way to determine which is the RBD and which is the SOP is by selecting them and checking out the datatype property. If i name the data correctly in the solver before hand, I can just quickly view and know which one is which by browsing the tree.

For example, say I have a RBD solver and a SOP solver piped in to a multisolver dop that is attached to an RBD object.. If i go to that specific object in the Details View, I get two identically named “Solver_multisolver1” entries with the only way to determine which is the RBD and which is the SOP is by selecting them and checking out the datatype property.

You do? If I understand this correctly, when I build that network, I get a Solver that contains data called Solver, and in fact it doesn't work properly unless you I toggle “Unique Data Name” on either the RBD Solver or the SOP Solver. Because otherwise, they are both named Solver, and only one gets used.

I think you are inadvertently solving your problem by naming one solver “foo”. That way, they have different names and both get used.

If I check the “Unique Data Name” toggle on both solvers, then I get a pair of solvers named
Solver_multisolver1_1
Solver_multisolver1_2
(see attached)

You do? If I understand this correctly, when I build that network, I get a Solver that contains data called Solver, and in fact it doesn't work properly unless you I toggle “Unique Data Name” on either the RBD Solver or the SOP Solver. Because otherwise, they are both named Solver, and only one gets used.

yea, sorry.. i guess i should have been more specific.. you are right, without the unique data name toggled, the multisolver will only pass through the last solver piped in to it because of the naming confliction.. the situation i presented above assumed that checkbox to be on.. sorry about that..

I think you are inadvertently solving your problem by naming one solver “foo”. That way, they have different names and both get used.

actually i was just using foo in place of a simple single rbd sover sim that i mentioned above.. it was in response to mark saying “If you attached an RBD Solver to your objects but give it the data name ”foo“, your objects won't solve. ” But this wasn't the case and it worked just fine. Plus I don't understand why there would be a name parm in the first place if we couldn't change it..

If I check the “Unique Data Name” toggle on both solvers, then I get a pair of solvers named
Solver_multisolver1_1
Solver_multisolver1_2

Yes, this is true, and is what i was getting about above. These names are useless when browsing the tree. Unless you select them and check out their datatype or remember the order in which you piped them in to the multisolver, you can't quickly determine which is which. So if the default data name was “`opname(”.“)`”, you would be fine with or without the “unique data name” toggle. Without it would show rbdsolver1, sopsolver1 and with it would show rbdsolver1_multisolver1_1, sopsolver1_multisolver1_2.. either way, seeing these names listed in the tree helps identify which is which immediately..


unless changing the name does break it somehow like mark says, then all of this would be thrown out the window..

Hmm.. wasn't aware of that.. But i just did this and it was fine.. Simple RBD Object->Gravity->RBDSolver->Merge with ground plane.. Data name for solver was set to “foo” and nothing seemed to break.. Unless I'm missing something..

How did you set the Data Name of the RBD Solver to “foo”? When I do this setup, the Data Name parameter is disabled. The reason it is disabled is because the value in the parameter is ignored, and “Solver” is always used when the input to the Solver DOP is an object stream (grey instead of green). The Data Name on a Solver DOP is only used when you are using an Apply Data DOP to attach the solver to an object, or when you are using the Solver as subdata for another solver. I had actually forgotten about this behavior…

Given this behavior, I may change the defaults as you suggest. But there are still situations (using an Apply Data DOP to attach solver data to an object) where the default of “Solver” makes the most sense. It just depends on which situation is more common…

Mark

ya know, i have no idea what the heck i did yesterday.. i'm redoing this again now and you're completely right mark.. if the solver is inline, then the parm get's disabled.. And if you try to attach it as foo, it busts.. (well it doesn't “bust”, just doesn't recognize it as a solver anymore.. details just see it as a new piece of data called ‘foo’..)

god knows what setup i had going on, but i was messing around with multisolvers left and right yesterday so maybe i just cheated and had a single renamed rbd solver attached to a multisolver that was inline after a rbd object->gravity setup.. but of course that was working because the multisolver passed along ‘Solver’ with subdata as ‘foo’ or whatever.. so i dunno, but i wouldn't change it now that i've looked in to this farther. it's like you said, it just depends on which situation is more common and i guess i would rather keep it as is now since many solvers will be put inline. sorry ‘bout all that.. ops:

just thinking out loud.. maybe something can be done when you toggle “unique data name”.. maybe it changes the data name from solver to opname.. but no, that just may confuse some people.. hmm.. well i can’t think of a better solution so all seems to be well. i would leave as is and i think it's safe to just ignore all my ramblings as usual. :roll:

thanks for the clear up mark and craig..