Jump to content

rdm

Members
  • Content count

    5
  • Joined

  • Last visited

  • Days Won

    1

rdm last won the day on September 18 2018

rdm had the most liked content!

Community Reputation

1 Neutral

About rdm

  • Rank
    Junior Member
  1. So... after some more playing around and a lot of help from Tomas I found out what was wrong. I'm writing it here shall anyone happen to have my same issue. The problem is related to Apple's Gatekeeper that allows or denies unsigned code to be executed. Up until before Sierra and High Sierra, users had the option of selecting "Allow from anywhere". That option is missing now. My specific problem was that I had tried to launch Camera and/or Camera_64 before disabling the gatekeeper. This had probably created a blocking rule that was stopping Camera_64 from starting. So if you happen to have my same problems do these things: 1. Download a fresh copy of EIAS. No you can't use the one already installed. 2. Open your terminal and type "sudo spctl --master-disable" (without the quotes). You will be asked for your password. 3. Open System Preferences and go into the Security & Privacy panel. Unlock the panel with your password and switch the "Allow apps downloaded from" setting back and forth to App Store and then back to Anywhere. This will trigger a confirmation dialog. If you don't see the "Anywhere" option it means step 2 did not work. Try again. 4. Only now, attempt to launch any EIAS app. The rest should be straightforward.
  2. Ok I fidgeted a little more with the issue. It's related to the MacOS gatekeeper and the need for developers to sign their code. Obviously I forgot to mention that I HAD already disabled the gatekeeper before attempting to render. Disabling the gatekeeper was previously available as a switch in System Preferences > Security & Privacy > General. Not anymore... to completely disable the gatekeeper you need to use the spctl command line tool. Unfortunately, even with a disabled keeper the app still reports that Camera_64 can't be run. That's weird. I re-enabled the keeper and tried to assess Camera_64 from the command line and I got: “Camera_64” rejected (the code is valid but does not seem to be an app). Googling this I found other developers hitting the same wall when trying to distribute command line tools. Some of these just solved the issue by creating a fake app bundle around their tool and then allowing/signing that one. Not an option for me to try because I assume regular Camera expects Camera_64 to be in that specific place. Can you folks on the dev team come up with a temporary workaround. Thank you.
  3. Hi, I'm having issues after upgrading to High Sierra. I downloaded a fresh copy of EIAS9.1. Moved it to the Desktop, plugged in the dongle, launched both Animator and Camera. Animater triggered the serial number insertion which I did and was accepted. Camera alone starts without complaining. I can open any project and work in animator but if I try to render, when camera opens (with a task this time as opposed to not having to do anything), I get a MacOS modal dialog with: “Camera_64” can’t be opened because the identity of the developer cannot be confirmed. And then an EI Modal Dialog with: An OS exception occurred inside Camera. I'm not sure this issue is related to high sierra specifically. It could just be a permission issue that I missed. Can anyone help me with this?
  4. Hi, Since this is a brand new company I was wondering what happened to the original project of coming out with an EI modeler. I was a huge fan of the old EIM (and I actually still keep an old g5 just so I can model with that) and I've been waiting for it's rebirth. But now? Is the code-name -Tesla modeler part of what was transferred to this new company or was it left behind? I've seen the thread about the integrated modeler and, sure it would be fantastic, but before that, even the simple non integrated one would be nice. I'd love a honest answer to this question I've been asking over and over again during the years. Will this company commit to write something to model as well or should I definitely desist and start learning something else? Thank you, rdm
  5. Hi all, I wonder if someone can point me out a way to work around this issue. I’m trying to reproduce a spongy material that’s part of a woman pad (don’t laugh… someone has to do those animations as well, after all ). I’m having issues when I combine raytraced transmission with bump maps. It looks like the areas where the bump is acting don’t get the transmission calculated for them. Here’s an example of what I’m saying: http://pink.tuorlo.net/transmissionglitch.jpg In the first two images (the second has GI light turned off to highlight the issue) I have a transmission thickness of 0.013. That’s what I would want as it very much looks like the behavior of the real object. Problem is that all the areas where the fractal noise and erosion bumps are acting (it’s 3 shaders piled in a reactive sequence… don’t know if it can matter) seem to be impenetrable to transmitted light. As if the raytraced transmission light rays fail to pass through areas with bumps. On the third picture you can see the effect of reducing the transmission thickness to 0.003. It looks like the best thing I found to keep the bump and at least a light transmission thin line. But I’m loosing a lot of what I’d want. Is there a work around? Is camera supposed to behave like this? Any advice is appreciated, rdm
×