You could definitely write through python and read through CPP. You can also read binary / ascii file on disk from CPP using streams if you want.
I think your problem lies in reading the value in context of a CPP operator. The way to access data from the input port is where you are having a glitch, at least that's what I think. I am not near a machine right now so I cannot provide you with a specific code. But I will do so later today or tomorrow in case somebody does not answer before that. Sent from my iPhone > On Feb 4, 2014, at 14:29, Tyler Fox <[email protected]> wrote: > > HI there, > I'm the Tyler that Jeremie was talking about in the original post. > > Writing the data generation in c++ is gonna be a really tough sell due to > time/knowledge/expertise constraints on this end. It's been a LONG time since > I've written any c++, and I'm doing some not easily portable stuff in the > python code. > > Would a possible workaround be to write a custom command that reads a file on > disk, builds my class structure using that data, and send that over to my > custom operator? > > Which leads to the question, is an operator's userData saved with the file? > > ~T.Fox > > > > > >> On Tue, Feb 4, 2014 at 10:31 AM, Matt Lind <[email protected]> wrote: >> Write it in CPP. >> >> >> >> If your data requirements are small, you can use a userdatablob template to >> store basic values to make them language agnostic (mostly). A template is >> essentially a customparamset applied to the object and flagged to be read by >> a userdatablob. Templates also exist for userdatamaps. >> >> >> >> >> >> Matt >> >> >> >> >> >> >> >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Jeremie >> Passerin >> Sent: Tuesday, February 04, 2014 10:28 AM >> To: softimage >> Subject: Re: [C++] Reading UserDataBlob as JSON String >> >> >> >> Thanks for the inputs guys. This is where I am wrong assuming that assuming >> I can write Cpp just like I write Python. >> >> >> >> So let me explain you the root of the problem so maybe someone has an idea >> how to solve it with another way. >> >> >> >> We have a solver in Cpp (for optimization purpose). This solver needs to be >> initialized with some values that only need to be computed once. We did a >> prototype in Python and it works just fine. The init values is just a bunch >> of list of strings, integers and floats. Nothing weird. >> >> Rather than rewriting this whole initial computation in Cpp, which would >> take us a lot of time (and is using some external python libraries), we >> though we could just do the init in Python store the result in a datablob >> and read this from the Cpp solver. >> >> >> >> What would be the best way to ready array of strings, integers and floats >> stored somewhere in the scene from a Cpp solver ? >> >> >> >> thanks for your help ! >> >> >> >> Jeremie >> >> >> >> >> >> >> >> On 3 February 2014 18:25, Alok Gandhi <[email protected]> wrote: >> >> I'd side with exactly what Matt and Oleg are saying, the data stored in a >> user data blob through C++ is essentially binary. That might be the cause of >> the issue. I wrote some plugin for userdatablob using c++ but I was writing >> the data instead of reading it. You can probably do the inverse of what I >> did. >> >> >> >> Here is the code from my plugin: >> >> ---------------------------------------------------------------------------------------------------------- >> >> struct DataForBlob >> >> { >> >> const char* blobVal; >> >> } ; >> >> >> >> DataForBlob blobData; blobData.blobVal = >> CString(L"MSVDATA").GetAsciiString(); UserDataBlob blob ; >> agentModel.AddProperty( L"UserDataBlob", false, L"msvResource", blob); >> blob.PutValue((unsigned char*)&blobData, sizeof(blobData)) ; >> blob.SetLock(siLockLevelAll); >> >> >> >> -------------------------------------------------------------------------------------------------------- >> >> >> >> On Mon, Feb 3, 2014 at 9:15 PM, Oleg Bliznuk <[email protected]> wrote: >> >> casting from char* to CString* is unsafe as you dont know how CString is >> implemented. It can be even not null-terminated ( and most likely this is >> true as its responsible to hold both wide and non-wide characters ) inside >> and in such case the "LogMEssage" internally may call something like >> "GetLength() {return m_Length;}" but physically there is only >> null-terminated char buffer or whatever JSON stuff can holds. First check if >> the "x" is not NULL after GetVall call and then try to create CString >> stringObj ( x ) and log it. >> >> >> >> >> >> >> -- >
