GetVirtualObjects - do not recreate objects

Maybe this does not make any sense, I don't know:)
I have an objectPlugin and I create a sphere object in GetVirtualObject. Also I have sliders (in res file) that control the radius of that sphere. Here's a code:

Each time I change RADIUS, the GetVirtualObjects regenerates sphere object and sets that new radius value.
Is there a way to AVOID all those repetitive task in GVO such as create null, create sphere, insert it into project etc BUT only affect/change the radius of the sphere with the sliders?
I will have bunch of objects in GVO, so if I change one small slider value, all virtual objects are "regenerated" - I hope you understand what I am saying:)

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.

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!)

@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.

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.

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.

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.

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.