GetVirtualObjects - do not recreate objects

Helper

On 24/01/2013 at 05:32, xxxxxxxx wrote:

You can use op.GetCache() to get the object returned by the last call to GVO, modify it, and return it again. This is however rather unsafe, because the cache could've been modified from the outside.

Best,
Nik

Helper

On 24/01/2013 at 05:37, xxxxxxxx wrote:

It's unsafe? Well, then nonono:)

On the other hand, is it OK if GVO is always recreating objects? Maybe I am trying to achieve something that is not necessary or odd and I am just being paranoid?

Will this kill Cinema if I have lets say 1000 virtual objects but will be modifying only one of them?

Helper

On 24/01/2013 at 05:45, xxxxxxxx wrote:

lol, cpt capslock has arrived you can also just manually cache parts of your object
tree in your class and then create a copy of that root on each call of GetVirtualObjects.
however navigating in that tree will become difficult as you cannot use pointer/references
for it as you actually create a new tree each time you copy it.

however if you are doing this for performance reasons, this does not make much sense.
getvirtualobjects is already cached. getvirtualobjects only is executed when your object is
dirty.

Helper

On 24/01/2013 at 05:47, xxxxxxxx wrote:

Unsafe, because the hierarchy could've been modifed from outside influence and the hierarchy
might not be what you'd expect it to be. You can of course still obtain the cache and do the
modifications, but you should not expect the hiersrchy to be the same as you returned it from
GVO.

It would of course be ideal when you are able to re-use objects that have already been created,
but the question is, if it's worth. For 100 objects (assuming they can all be treated the same), I'd say it's worth.
But if the complexity reaches a much higher level, it might be not worth the work behind it

It wouldn't kill Cinema (unless you trigger a crash), but it will lead to unexpected results
when you assume an object to be what it not is (therefore: check it's type!)

Best,
Niklas

Helper

On 24/01/2013 at 05:51, xxxxxxxx wrote:

@littledevil: The plugin object is dirty when eg. an attribute is changed. If that slider would
only affect the spheres' radius, but the sphere has already been generated in the previous
pass (call to GVO), I think it would indeed an optimization to re-use this object instead of creating
a new one and dropping the old.

Not fundamentally necessary, but one way to achieve optimization.

Helper

On 24/01/2013 at 05:57, xxxxxxxx wrote:

Wow, that's the best replies I've ever had:) Awesome.
Ant ways, I don't really want to become a Einstein, so will just ignore that GVO is regenerated each time I change sphere radius. Of course, if my fully working plugin will crash, then I'll have in mind to optimise it.

So thank you guys for your input. Thank you thank you thank you.

Helper

On 24/01/2013 at 06:06, xxxxxxxx wrote:

with the dirty stuff i just wanted to clarify that your plugins gvo isn't executed on each
pass, because i am not so sure that the op is aware of that. i also wanted to stress
with my posting that you cannot just store a static part A and insert your non static part
into the same object A on each call.

the op seems to be a beginner and there is messing with the actual cache of limits
imho.

Helper

On 24/01/2013 at 06:10, xxxxxxxx wrote:

While still on same topic, where should I put UNDO steps? I tried few versions with no good result - I have to press UNDO twice to get to previous state.

  
    def GetVirtualObjects(self, op, hierarchyhelp) :   
        doc = c4d.documents.GetActiveDocument()   
        doc.StartUndo()   
        myData = op.GetDataInstance()   
        scale = myData.GetReal(RADIUS)   
        baseNull = c4d.BaseObject(c4d.Onull)   
        sphere = c4d.BaseObject(c4d.Osphere)   
        sphere.InsertUnder(baseNull)   
        sphere.SetPhong(True, 1, utils.Rad(80.0))   
  
        doc.AddUndo(c4d.UNDOTYPE_CHANGE, op)   
        sphere[c4d.PRIM_SPHERE_RAD] = scale*100   
  
        doc.EndUndo()   
        print "Virtual END"   
        return baseNull

Helper

On 24/01/2013 at 06:13, xxxxxxxx wrote:

You do not need to add undo steps in GetVirtulObjects().

Helper

On 24/01/2013 at 06:19, xxxxxxxx wrote:

If I don't, then values snap back to it's default values when I press CMD+Z

Helper

On 24/01/2013 at 06:45, xxxxxxxx wrote:

When implementing an ObjectData plugin, you usually do not have to care about undos at all. What
values snap back to their defaults? The ones of your object in the Attribute Manager?

Helper

On 24/01/2013 at 07:52, xxxxxxxx wrote:

Default value for slider and sphere radius is 100.
I change values with a slider number of times, but when I press CMD+Z, values and sphere radius jumps back to default 100. No matter how many times I change that value - one undo always sets default values. If I press undo second time, I see my object disappears from project.

But if I do those undos the way I have done now in above code, once I do UNDO - nothing happens, second time - it goes one step back, third time - nothing, fourth - second step back.

Maybe I am just doing something stupid here in my code, but you can see all my code above.

Helper

On 24/01/2013 at 07:57, xxxxxxxx wrote:

Any chance to get a copy of the whole project? If you don't want to make the complete source code
public, you could send a PM to with a download link and I'll try to catch out the issue.

-Nik

Helper

On 24/01/2013 at 08:08, xxxxxxxx wrote:

funny undo/ gui behaviour can be caused by a corrupted symbolcache. just delete the file and
restart c4d. the file is located in the prefs folder.

Helper

On 24/01/2013 at 08:13, xxxxxxxx wrote:

Niklas, no problem.
[link removed]
oh by the way, there are few sliders in GUI, but only one of them is hooked, it's SCALE slider. Just ignore other ones

and thanks for taking a look at it.

littledevil, that's interesting idea, will check it out. What should I be looking for in prefs folder?

Helper

On 24/01/2013 at 08:15, xxxxxxxx wrote:

@Ferdinand: Huh, really? Never experience such an issue. May be due to the fact that I haven't run
accross the symbolcache-issue often.

Did you mean me with "cpt. capslock"? xD Dunno why the font is so big in my first post, seems to be
some kind of bug in the chrome browser for android in combination with the rich-text editor...

Best,
-Nik

Helper

On 24/01/2013 at 08:18, xxxxxxxx wrote:

Originally posted by xxxxxxxx

littledevil, that's interesting idea, will check it out. What should I be looking for in prefs folder?

well, a file called symbolcache

Helper

On 24/01/2013 at 08:25, xxxxxxxx wrote:

never heard of symbolcache before:) But there's always a first time:)

Any ways, I tried on different mac, and still getting save behavior. So my guess is it's not symbolcache related:) There's just some weird bug in my code (maybe)

Helper

On 24/01/2013 at 08:59, xxxxxxxx wrote:

Hi Tomas,

first, you can get the document your object is in using op.GetDocument(). It is possible that GVO
is called, where the object it is called for, is not in the document currently being active (eg. when
rendering).

As for your "bug": I just realized it is not a bug. When you change the same attribute multiple
times without any other action in between, an undo will reset it to the value it started with
before you began modifieng it. Try it with some other object.

I never really realized this behavior, maybe because it feels more "natural". This behavior is
the same in R12 (just checked it), possibly even before this release.

Best,
Niklas

Helper

On 24/01/2013 at 09:09, xxxxxxxx wrote:

interesting.
I just noticed that if I have my undos the way I have them right now (see above), INIT function is called twice, but if I don't have StartUndo, AddUndo, EndUndo - then INIT is called only once.

Does that make any sence?

However, I am not really sure what you mean with your first statement:) (sorry, dummy here). You say it's better to use op.GetDocument() instead of doc = c4d.documents.GetActiveDocument(), right? I just want to be sure:)

By the way, R12 and R13 does act the same. I just tested it aswell.