yes, something like that might work, but if I am working locally from home
sending files to someone else that is also in his own personal computer I
can't really force that persone to set the usertSetup.py or the other
alternative you mentioned.
aarrggg...callbacks are nice, but
oh noI had no idea you can open files disabeling script nodes.
Bummer...good thing I am not working in security.
El miércoles, 15 de septiembre de 2021 a las 5:02:23 UTC+2,
justin...@gmail.com escribió:
> On Wed, Sep 15, 2021 at 11:36 AM Rudi Hammad wrote:
>
>> So I cam up with a evil
it work is you execute that at the beginning of every maya session (for
instance putting it in the userSetup.py), but then you just have to find
this part of the code and remove it…
About MSceneMessage.addCheckCallback, there are a few ways of installing it.
- userSetup.py
- plug-in
-
On Wed, Sep 15, 2021 at 11:36 AM Rudi Hammad wrote:
> So I cam up with a evil idea that seems to work.
> . I create a script node that travels with the scene that will check your
> mac address out from a list of valid addresses (that would be the ones
> corresponding to the people working
So I cam up with a evil idea that seems to work.
. I create a script node that travels with the scene that will check your
mac address out from a list of valid addresses (that would be the ones
corresponding to the people working remotly on their personal computers).
if the address doesn't
On Tue, Sep 14, 2021 at 7:52 AM Rudi Hammad wrote:
> About V crypt, I got in thouch with them and they sent me the system to
> test it in demo mode. It work pretty well, but as Justin anticipated and as
> the video showed, all clients are requiered to have the app.
> So maya is should be
About V crypt, I got in thouch with them and they sent me the system to
test it in demo mode. It work pretty well, but as Justin anticipated and as
the video showed, all clients are requiered to have the app.
So maya is should be launched from V Crypt, and then you can open the
encrypted files.
It was still kind in the context of encrypting a maya scene that derived
from the main V Crypt topic, but we'll do.
El lunes, 13 de septiembre de 2021 a las 19:07:28 UTC+2,
justin...@gmail.com escribió:
> Please make sure to start a new thread if you want to engage in new
> topics. It seems
agreed!
On Mon, Sep 13, 2021 at 10:07 AM Justin Israel
wrote:
> Please make sure to start a new thread if you want to engage in new
> topics. It seems two completely new questions have been asked since the
> original thread was started about V Crypt, and are entirely unrelated.
> Thanks!
>
> On
Please make sure to start a new thread if you want to engage in new topics.
It seems two completely new questions have been asked since the original
thread was started about V Crypt, and are entirely unrelated. Thanks!
On Tue, 14 Sep 2021, 4:25 am Rudi Hammad, wrote:
> That's it! thanks Juan
>
That's it! thanks Juan
El lunes, 13 de septiembre de 2021 a las 15:33:57 UTC+2, Juan Moraga
escribió:
> Try using "def onOpenCallBack(*args):" instead.
> Callbacks may pass on arguments to you method, which you can use or not.
> But you need to allow the function to receive these arguments,
Try using "def onOpenCallBack(*args):" instead.
Callbacks may pass on arguments to you method, which you can use or not.
But you need to allow the function to receive these arguments, otherwise it
will raise an exception.
On Mon, 13 Sep 2021, 15:09 Rudi Hammad, wrote:
> Hello,
> any idea why
Hello,
any idea why this is not working?
I opened a scene and created this callback, and then saved the scene
def onOpenCallBack():
print "this is a test"
checkCallback =
OpenMaya.MSceneMessage.addCheckCallback(OpenMaya.MSceneMessage.kBeforeOpenCheck,
onOpenCallBack)
Now when I open the
oh, about the screenshots. If the rig is encapsulated in a black box, maybe
it would be possible set a callback preventing from unlocking the blackbox?
That way you can check want is inside and take screenshot.
El lunes, 6 de septiembre de 2021 a las 22:02:29 UTC+2, Rudi Hammad
escribió:
>
Quick question, I haven't use mel in 4 years now so it is probably
something foolish but why is this not working?
string $toEval = "def foo():import uuid; macAddress = uuid.getnode();
return macAddress; foo()";
string $macAddress = python($toEval);
print $x;
I would expect $x to print my
Marcus, thanks for your comment!
When I talked about export I meant not to ma or mb, I meant for example to
alembic or other, because as I knew alembic export is like a separate
plugin, and .correct me if I am wrong export to alembic will be ignored by
this callback.
I've not understood you,
The part of Maya that does the serialisation to ma and mb - be it via
export or save - is a singular point of access. The scene callbacks should
account for all ways in which creating those is possible, including via
Python and MEL. It wouldn’t account for manual export to other formats, but
It is a very interesting discussion.
Yeah, I will agree that it definitely must be invisible - so artists don't
even know that encryption happened.
But you can't stop on scene saving and loading, you should create lots of
workarounds in this "secure Maya client".
Somehow you need to lock any
And additionally, if in your scene you will have references,
during reference load you will need to decrypt this data,
the same will go to any geometry\textures or any files - you will need to
decrypt on the run.
And all of it must be done recursively on the whole data tree in scene,
so at some
It is a very interesting discussion.
Yeah, I will agree that it definitely must be invisible - so artists don't
even know that encryption happened.
But you can't stop on scene saving and loading, you should create lots of
workarounds in this "secure Maya client".
Somehow you need to lock any
I agree with you. This would not solve all problems with working remotely,
but it would solve some. Perhaps the biggest problems, namely accidental
sharing and theft. I have also personally received material from artists at
studios that really shouldn't have managed to leave the studio. Some even
I think they must have thought about the export aswell. Otherwise it
wouldn't make any sense.
Of course ideally you would each person would work in their office stations
remotly, but it is not up to me. So if I choose not work with a client
unless he guaranties remote workstation solutions, I
oh yea, nothing protects it from sending it to anyone, but you can encrypt
the MAC address of your client's computer, so if it doesn't match it won't
open. Or something like that.
Maybe you ask the client to give you his MAX address and generate a license
number mapped to it.
El sábado, 4 de
I don't know about the export...h..., but saveas is safe. I am talking
with them via email and that's what they said. I will ask about the export
too.
(About custom nodes I am not using any at the moment, I might implement
that later as an alternative option to the client. It is all maya
On Sun, Sep 5, 2021 at 8:38 AM Marcus Ottosson
wrote:
> That is true, that does sound like a good idea. Assuming the software
> actually does what it says on the tin, it would at least protect against
> theft and accidental sharing.
>
> It wouldn’t protect against sending files though, because
That is true, that does sound like a good idea. Assuming the software
actually does what it says on the tin, it would at least protect against
theft and accidental sharing.
It wouldn’t protect against sending files though, because if someone wanted
to send some model or some rig, they could still
Yes I am refereing to the actual file, not source code.
Here's a usecase:
due to covid a lot of production are done remotly. In somecase you can
connect by logging remotly to office computers to work, in which case no
protection is needed since it pretty much as if you where in the office.
But
To protect the contents of a Maya file? Typically protection would involve
software, like Python source, but you mean to protect like a model or some
animation? At that point, why wouldn’t you just hold onto the file, and not
send it or make it publicly available? Maybe you have a particualr
28 matches
Mail list logo