GetVirtualObjects - do not recreate objects
-
On 24/01/2013 at 04:40, xxxxxxxx wrote:
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:RADIUS = 1002 class MYPLUGIN(c4d.plugins.ObjectData) : def __init__(self) : self.SetOptimizeCache(True) def Init(self, op) : self.InitAttr(op, float, [RADIUS]) op[RADIUS] = 1.2 return True def GetVirtualObjects(self, op, hierarchyhelp) : doc = c4d.documents.GetActiveDocument() 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)) sphere[c4d.PRIM_SPHERE_RAD] = scale*100 print "Virtual END" return baseNull
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:)I am new to python and coding in general. Sorry:)
-
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 -
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?
-
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. -
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 itIt 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 -
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.
-
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.
-
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. -
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
-
On 24/01/2013 at 06:13, xxxxxxxx wrote:
You do not need to add undo steps in GetVirtulObjects().
-
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
-
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? -
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.
-
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
-
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. -
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 onesand 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?
-
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 -
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
-
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)
-
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