Saving custom attributes with a scene file?

On 07/07/2014 at 18:53, xxxxxxxx wrote:

Hi there.  I'm trying to save a few strings with each individual c4d file, ideally, on a node that can't be deleted and is hard to get to.  In Maya, I've been able to add attributes to the "defaultRenderGlobals" node, and in Nuke, I've been able to write them to the "Project Settings" node, both of which can't be deleted.  Does anybody know of a similar node that I could use in c4d?  It would be nice if it's visible, but if values can be written to the file, similar to Maya optionVars, that would work also.  Any idea for non-deletable nodes that can't have duplicates in a scene, that can have attributes added to them?

On 07/07/2014 at 19:40, xxxxxxxx wrote:

Oh yeah, and please no new.c4d or template.c4d recommendations, as this needs to work at various facilities, and for various users, who may or may not want to make their own files like this.  Thanks!

On 08/07/2014 at 08:36, xxxxxxxx wrote:

Please don't save data in the preferences in C4D. Please don't do it in Maya either (I use both).
I don't want people putting data into my applications without me knowing about it.
Plus, if everyone does this. I'll have tons of data in there that I don't want to be there.

C4D lets us save data to the document's container.

#We can save custom data permanently into the document itself using a document subContainer  
#You must use a unique ID# for the sub container!!  
  
import c4d  
def main() :  
    
  subC = c4d.BaseContainer()     #Creates a new container  
  subC.SetString(1111, "hello")  #Put some data in the container  
  doc[UNIQUE ID#] = subC         #Assign the SubContainer to the document's default container  
  
  
  #Check to see if your custom conatiner was saved          
  docBc = doc.GetDataInstance()   
  for id,item in enumerate(docBc) :  
      print id,item  
  
        
  #Get your custom data's value      
  docBc = doc.GetDataInstance()  
  print docBc[UNIQUE ID#].GetData(1111)  
                
  c4d.EventAdd()  
  
if __name__=='__main__':  
  main()

-ScottA

On 08/07/2014 at 09:49, xxxxxxxx wrote:

Don't save data in the scene?  Have you ever worked in a large studio pipeline?  From my experience, it's almost impossible to have a robust pipeline that doesn't find a way to store pertinent data in scene?  Having worked at Imageworks, Walt Disney, PDI/Dreamworks, Rhythm & Hues and other places, I couldn't imagine a pipeline that didn't save data in scene.  Which has been one of the frustrations of working with C4D, being that it's been really troublesome and difficult to integrate into a pipeline, the way that you can do with Maya and Nuke.  Also, I wouldn't save settings with the Preferences, but rather, on an indestructible node that users can't really mess with.  So long as the attributes are hidden from the user and locked off, there shouldn't be any issue.

I'll have to check the container method when I get to work in a little bit.  But, it seems like containers can just be created and deleted by the user at will, yes?  I need something that can't be deleted, and ideally, an object that should never have any duplicate naming issues.  Thanks!

On 08/07/2014 at 10:59, xxxxxxxx wrote:

First off. I'm really not a fan of your attitude.
I answered another one of your questions (which was very basic to solve) and you gave me a rather snarky reply there too.
I don't care how important you THINK you are. Or how many "studios" you claim you've worked for. You're asking very simple questions that many beginners would know how to solve. So it's time for a reality check sir. You ain't as "hot" as you think you are.
We are a very small tight knit group here. And we all check our egos at the door.
This isn't CGTalk where there's tons of elitist egos running around. We're more casual and friendly to each other here.
If you don't dial back your elitist attitude. I'm going to ignore you. And I will ask all of my fellow forum members to ignore you too.
Sometimes we make bad first impressions. And not everyone's personalities mesh. So I'm going to give you one more chance to be less confrontational.
Just please try to relax, and try to be more casual and friendly if you can. And don't play the "I've worked here" card. It makes you sound like an *sshole.

Getting back to the subject.
The document's container does store data in the document. But only in that one single document.
Some people are using the world container to store data. But IMHO that's a bad idea because the data will stay there unless the user knows to delete it. And checking the world container is not something users commonly do. Or even know ow to do.

Yes. The document's container can be edited or even deleted by the user. But the user would have to know how to get at it. And most people don't check their document's container as a habit.
We can also store data in an object's BaseContainer the same way. And then make that object invisible in the OM so the user can't see it and change it.

Nothing is 100% locked away were a smart user can't get at it.
But IMHO. Storing data in the doc's sub container is a fairly secure option.
Perhaps someone else will have another trick they use that you'll like better?

-ScottA

On 08/07/2014 at 11:31, xxxxxxxx wrote:

Since he's talking about pipeline, I don't think he wants to store data in the world container
anyway, since someone the scene is shared with won't get this data with the scene.

The proper way to store data in a scene is to use an Object or Tag plugin that carries the
data. But since this requires a plugin, many developers fall back to storing the data in the
documents container (please use a sub-container if you want to store more than one value,
and always allocate a new plugin-id when assigning custom values to an object/tag/mat/doc).

If it's just a few values, it's not bad storing it in the document itself. But if you want to store
big data like baked simulation results etc. you should go for a Object or Tag plugin that carries
the data as it allows you more easily (and visually) to get rid of the data.

-Niklas

On 08/07/2014 at 12:49, xxxxxxxx wrote:

That's helpful, thanks Niklas!  That is a bit of a setback to hear that I'd have to write another plugin to support my original plugin (which I've already had to split into 5 individual plugins), but I definitely need to be able to store data that will stick with the file, regardless of who opens it.  I'll look into that, but please let me know if you know of any relevant threads or docs that might go along with that.  Thanks!