Nested Cloners [SOLVED]
-
On 15/09/2015 at 03:46, xxxxxxxx wrote:
did you check activeobject plugin?
-
On 15/09/2015 at 03:50, xxxxxxxx wrote:
activeobject plugin? What do you mean by that Mohamed? All pointers are verified yes, if you mean that.
-
On 15/09/2015 at 06:01, xxxxxxxx wrote:
no, not meaning that Samir, there is a plugin example in the SDK, under GUI plugins, ActiveObject.cpp
-
On 15/09/2015 at 06:10, xxxxxxxx wrote:
Ok. Yes, I know the gui example, but how is it supposed to help me with this issue? Not sure I understand. Can you elaborate?
Except for the effector examples there's nothing MoGraph related in the sdk examples.
-
On 15/09/2015 at 06:13, xxxxxxxx wrote:
just create your nested clones in the object manager, then open the plugin, check how the hierarchy looks, it should do exactly what you want.
-
On 15/09/2015 at 06:20, xxxxxxxx wrote:
No, it does nothing what I want (at least I don't see anything helpful in my situation but I could be blind).
Please be more exact or post some code that shows how to retrieve the Modata/motag from a nested cloner with valid transformation matrix informations, so I know what you mean.Imo the activeobject example does nothing but showing the hierarchy in a treeview. All the classes there are meant to let the treeview element handle a hierarchy. How is it supposed to help me with nested cloners and modata retrieval?
The hierarchy is known and I don't need direct access to the clones geometry (that is retrieved with GetDeformedCache for example) but to the internal procedural clone data of the cloner which the modata provides.
-
On 15/09/2015 at 07:04, xxxxxxxx wrote:
you will need to get that cached object, access its container.
-
On 15/09/2015 at 09:08, xxxxxxxx wrote:
Hello,
I could no reproduce any problems. You told that you browse the cloner's children with GetDown(). But these children (objects you see in the Object Manager) are no clones. The only clones exist in the cache of the cloner. When you access the cache of the cloner and access the cloned cloners there, they will have a MoGraph tag.
Best wishes,
Sebastian -
On 15/09/2015 at 10:36, xxxxxxxx wrote:
ok, I am absof**kinglutely stupid and you guys are totally darn right! Really, this is so basic, I feel ashamed. I haven't had the slightest thought about virtuality of the result that it never even crossed my mind to look that way (even though I was talking about the procedural data. Someone please hit me).
My apologies to Mohamed as well. You pointed in the right direction but as I mentioned I was totally ignorant about thinking this out further. Apparently I don't need sleep, I need vacation.
Anyway, will try this first thing in the morning but it seems that was my missing piece. Hate myself right now.
Thanks guys (also for being patient sometimes with me !
Ermm
[URL-REMOVED])!!
[URL-REMOVED] @maxon: This section contained a non-resolving link which has been removed.
-
On 15/09/2015 at 11:22, xxxxxxxx wrote:
this is common Samir, I always do this "test a lot , get a whole picture, and miss a small detail".
glad that it helped -
On 23/10/2015 at 04:43, xxxxxxxx wrote:
Hi,
sorry guys, gotta steal your time once again as I now know why I used the "normal" clones in the first place (sorry, didn't recall before but only today when I indeed tried this). I am in a SceneHook Execute() function and GetCache as well as GetDeformCache always return a nullptr.
SendModellingCommand only seems to return the final polygonal hierarchy. So is there a way to access the virtual cache from here anyhow?
Maybe I need to clone the doc somehow, let the cache be rebuilt (which would probably impose a performance penalty if dynamics need to be recalculated for the frame of retrieval?) and read the cache then? I'd rather not because this would also include my own dynamic calculations to be redone which is really no option (it could be hours of simulation time for previous frames...worst case scenario).
Maybe there is a way to rebuilt the caches?
Thanks again!
-
On 26/10/2015 at 01:53, xxxxxxxx wrote:
Hello,
what exactly are you doing in you SceneHook and when? In AddToExecution() you can define when in the execution pipeline your scene hook is called.
Best wishes,
Sebastian -
On 26/10/2015 at 05:49, xxxxxxxx wrote:
Hi,
what exactly do you mean by "what exactly are you doing"?
I am grabbing an object from the OM (my own object plugin) and reading out an object (in this case the Cloner but it doesn't matter what object, it's always nullptr) from a link field of it. Then trying to get the cache.
obj = my_op->GetDataInstance()->GetObjectLink(ID);
obj->GetCache()execution pipeline priority is EXECUTIONPRIORITY_DYNAMICS (which I want to be in btw.)
-
On 26/10/2015 at 06:06, xxxxxxxx wrote:
I assume caches are not yet built (but will be only in EXECUTIONPRIORITY_GENERATORS) so I guess I need pre-built caches?
Can I use the Hierarchy class for this purpose?
-
On 26/10/2015 at 06:47, xxxxxxxx wrote:
Ok, the hierarchy class seems to go through all objects in the scene. This seems a bit overload. I just need the single cloner object (and its children) to build its cache I guess.
-
On 26/10/2015 at 09:42, xxxxxxxx wrote:
Hello,
I just tried to access the cache of a MoGraph cloner in a SceneHook::Execute() with EXECUTIONPRIORITY_DYNAMICS and it seems to work fine in R17. Does the problem also happen for you with R17?
Best wishes,
Sebastian -
On 27/10/2015 at 02:54, xxxxxxxx wrote:
Thanks, I will have to try that!
-
On 03/11/2015 at 03:56, xxxxxxxx wrote:
You are right, trying it with a minimal sample in r17 works! Ok, then it must be an implementation problem on my side for the r16 version.
Cheers and finally solved!
-
On 03/11/2015 at 15:54, xxxxxxxx wrote:
@Katachi: Are you able to make changes to the cache that are actually reflected with nested cloners?
I never could get it to work (regarding the topic that you have linked). -
On 04/11/2015 at 03:14, xxxxxxxx wrote:
Not directly. What I am doing is using an additional Effector that reports back any changes to the clones (which means tracking the mograph objects, their deletion etc on my own). This works quite alright though of course that's not optimal.