Announcements

Between mid-October and November, the content on AREA will be relocated to the Autodesk Community M&E Hub and the Autodesk Community Gallery. Learn more HERE.

Consistantly get Modifiers Nodes Transforms

Consistantly get Modifiers Nodes Transforms

tim-bot
Advocate Advocate
775 Views
6 Replies
Message 1 of 7

Consistantly get Modifiers Nodes Transforms

tim-bot
Advocate
Advocate

Currently i'm using IObjParam->GetModContexts to get the mod contexts associated with my modifier. then i'm just grabbing the first  node returned to use it's transform. which works great when one of the nodes is selected. however, when another node that is referenced by my modifier is selected, GetModContexts doesn't return anything. this is as the comments on GetModContexts specifies. what i'm looking for is a consistent way of getting one of the transforms of one of the nodes my modifier is applied to.

 

to give context, i'm referencing a path and using it for positioning within my modifier and would like the positions to line up on the path even if a node is transformed. understanding the limitations associated with referencing and instancing. 

 

it may end up being a moot point though, I need to find out what usage my user is needing the transform to be away from world center if the results end up being on the spline anyway. because it would in theory cancel out any animations anyway. but if someone knows a better way, it would be good to know.

 

also, this won't work as a world space modifier or a singleton type using things like IsWorldSpaceObject because it needs to be able to be instanced among many items (parametric in nature).

 

0 Likes
Accepted solutions (1)
776 Views
6 Replies
Replies (6)
Message 2 of 7

denisT.MaxDoctor
Advisor
Advisor

You have to use ModContextEnumProc to find all ModCoxtexts. So you have go from a Modifier side, not from an Object side. In this case you can get and check all nodes modcontexts what your modifier applied to   

0 Likes
Message 3 of 7

tim-bot
Advocate
Advocate

thanks for that. it does help a bit. but it's only giving me the offset that the transform is from the actual transform. not the actual world space coordinates. but I did get an idea to just cache the position I get from your solution along with the original GetModContexts when all is  valid and I just use the cached version when it's not valid. which seems to be working pretty good. the user can't animate the modified node or scale the pivot, but neither of those should be happening anyway. especially animating the node, because it would just cancel out the animation anyway.

 

another issue I discovered though is that the ObjectState of my path (Path->EvalWorldState(t).Validity(t)) doesn't take into account the nodes actual transform controller validity? is that correct? I've changed to Path->GetTMController()->GetValue(t, &m, valid) to get the validity properly updated to include that. is there a better way than that?

 

thanks again for the input, always appreciated!

0 Likes
Message 4 of 7

denisT.MaxDoctor
Advisor
Advisor

honestly I don't understand well the concept of your modifier. A modifier should modify an object or a object's mesh, and not node's transform. Could you explain what your modifier has to do a little better?

0 Likes
Message 5 of 7

klvnk
Collaborator
Collaborator
Accepted solution

you need to use a dependent enumerator

 

class EnumProc : public DependentEnumProc 
	{
      public :
      virtual int proc(ReferenceMaker *rmaker); 
      INodeTab Nodes;              
	};

int EnumProc::proc(ReferenceMaker *rmaker) 
{ 
	if (rmaker->SuperClassID()==BASENODE_CLASS_ID)    
	{
		Nodes.Append(1, (INode **)&rmaker);  
		return DEP_ENUM_SKIP;
	}

	return DEP_ENUM_CONTINUE;
}

 then anywhere in the modifier code you can call it like this

 

EnumProc enumerator;              
DoEnumDependents(&enumerator);

 

it is quite unusual to need a dependent node transform in an object space modifier (though there are a couple of examples in the samples) it is usually a sign that it may be better suited to being a world space modifier  in which case the INode argument of Modifier::ModifyObject has a valid value.

0 Likes
Message 6 of 7

tim-bot
Advocate
Advocate

ok, that seems to do the trick. it's exactly what I was looking for. however, you are correct, I think i'm going down the wrong rabbit hole here... I should definitely be doing this as a world space modifier. turns out when it's instanced, things don't go so well. I think I may just end up splitting my modifier into an object space that doesn't have the move to path functionality, and a second world space version that does.

 

and denisT.MaxDoctor, i'm not actually messing with the transform of the nodes, just using the transform to basically find out what the difference is between the modified object and the path I want to move my verticies to.

 

thanks for all the suggestions, I think I get this better now. and i'm starting to see the role that enums play in the modifier stack a lot better too.

0 Likes
Message 7 of 7

tim-bot
Advocate
Advocate

in case you were curious, here's what ultimately came of this

https://apps.autodesk.com/ACD/en/Detail/Index?id=7221085778557027350&appLang=en&os=Win64

0 Likes