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 <ml...@carbinestudios.com> 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:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *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 <alok.gandhi2...@gmail.com> 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 <gbo...@gmail.com> 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.
>
>
>
>
>
> --
>
>
>
