Maya Vr Plugin

[Kemal Allan]

HiOne way to do this would be to add an engine_init hook to your configuration and add some code in there to check and load the plugin - just copy this hook into your config core hooks folder: -core/blob/master/hooks/engine_init.py

Hello all thank you so much for the help. Sorry it took so long to respond here. What I ended up doing was creating a maya setup tool that loads plugins sets scene units etc based on project configurations and I called that through the engine init hook.

I want them to be able to use just the .mll file. I'm assuming I would need to also package up other .dll dependencies needed in the same folder, but am I missing anything else? (There are no .mel scripts otherwise used, it's just a pure C++ plugin).

i recommend to check the following article which covers the most common causes (of course you have to adapt it to your plug-in, but incorrect paths, missing environment variables, PATH variables or dll files can cause this):

2. I then made sure a few of the .dll's (including standard ones like foundation.dll, openmayaui.dll, etc.) were in the same directory. Dependency walker displays a little yellow box or otherwise some warning if they are missing.

There are probably other paths that need to be set like MAYA_PATH or something similar, and I would probably be able to set those through an installer with my plugin, but the above should otherwise work.

After some digging, it turned out these slowdowns where due to the drawUfe.so plugin, and disabling that brings back normal performances.

This is mostly noticeable when there are a few rigs in the scene - I suspect that it's actually heavy meshes causing this, more than rigs as a whole themselves - and one tries to switch manipulators (from translate to rotate, or to scale and back and forth).

This is with the rig we were using during the test, and we had 4 references of them in the scene. Of course all this data changes with more rigs referenced in the scene. With 10 it became 2800ms for the latest scenario. There doesn't seem to be any change in performances with the drawUfe.so plugin unloaded, so it's definitely the culprit here - and also explains why this issue is not there in previous versions of Maya, where the plugin doesn't exist.

I'm trying to create a reproducible case to file an issue, because we can't send the scene we have been testing this on, but I also wanted to flag this issue over here and hear if anyone experienced something similar when adopting 2023 in production.

Found some time to record a video of the issue. I referenced 4 versions of Kiel Figgins' Deadpool Rig (thanks ) and I managed to reproduce exactly the issue we found at work, although this is on Ubuntu 20.04 instead of CentOS, so I can probably say this affects at the very least the Linux realm.

You can spot the timeline lagging when both plugins are loaded and I switch manipulators, and a little bit also when only drawUfe.so is loaded, while without none of them everything runs fine. I actually just realised I should have recorded the results with just the mayaUSDplugin ON, but at this point I can say for sure that it didn't have issues as I tested it at work.

It's pretty late here so don't have time to file a proper bug report right now, but I'll definitely do so after I get to test Maya 2024 as well, still have to get that installed along with the latest USD to check everything.

Whether this works properly in 2024 or not, it would be great to backport any fix to 2023 as I suppose many companies are pretty far from upgrading to Red Hat 8 from 7, which is the new minimum requirement, and a lot of USD stuff is not entirely usable before 2023.

if you are using an earlier version of maya, and your files are in ASCII format, then you can open each file in python, omit the offending lines, and write the file back out. if your files are in binary format, there is nothing you can do.

I have been trying to get a metahuman into Maya 2023. My firewalls are fine and I only have one version of Maya installed. I have the Maya pluginas well, but the options to export it just are not there. I have tried Bridge as a standalone and also from in UE5 (see image), but nothing seems to allow the downloaded Metahuman to be exported.

All I see when I open bridge from inside UE5 (with Maya open) is a megascans option. I dont have the ability to install a previous version of Maya, so it doesnt look like I will be able to use this as intended until there is some form of update or find a way to make it happen.

Unless its something I am not doing, but I have read a few threads and looked at various videos claiming they know how to do it, but they are usually old versions of Bridge and earlier versions of Maya.

If there is a proper, well documented and helpful metjhod to achieve what I want to do, I would appreciate the pointer. The docs do not seem up to date either, so its a maze of confusion and unhelpful content currently.

I am unable to load the omniverse usd plugin in Maya 2020 Update 4 on Windows 10. I get the error seen in the attached snapshot. I looked at this thread and ensured that the Maya USD plugin was not loaded but the issue seems to persist.

I installed the plugin via the Omniverse app so I assume it installed cleanly although I could try installing again. Initially I started Maya 2020.4 and loaded the omniverse usd plugin and it failed to load with a generic plugin initialisation failed error. I searched the forums here and found a thread about first unloading the maya-usd plugin which as on auto-load in my case. So, I turned that off and restarted Maya and verified that maya-usd plugin was not loaded anymore. Then I tried to load the omnivores plugin and ran into the error message attached in my first post.

Thanks a ton Aron and TJ! The issue is resolved now! I think previously I was only unloading the mayausd plugin and not the hydra plugin which was causing the issue. Its working as expected now. Thank you very much! Looking forward to omniverse!

The exporter plugin which comes with Verge3D for Maya is well-maintained and provides the most consistent support for glTF 2.0 features, plus several extensions to support various stuff beyond glTF standard.

Just for debugging purposes, could you copy/paste the full path to your prefs folder? In your screenshots, it looks normal, but just in case. (If you shift-right-click on a file in Windows, you can copy the full path.)

So maybe you need to include /maya/ in that path. But I suggest, until you have it working, or unless you are absolutely clear what $MAYA_APP_DIR returns on your system and OS, to just explicitly use the full path in your Maya.env file until you have this debugged.

I wonder if your work environment or any other plugins are still somehow interfering. Do you have animBot installed? Do you have any other plugins installed which perhaps install themselves in a directory that Maya would call even with clean prefs?

For example, if you navigate to the Maya installation folder under Program Files, there also exists a plug-ins and modules directory, which Maya also loads. That is where plugins like xgen, MASH, or Substance are installed.

There is also a chance your work may have added other environment variables for other installation locations. If you go look there, you may find some other paths that are related to Maya.

Oracle Help Center Installation and Administration GuideIf the PATH, ORACLE_SID, and ORACLE_HOME environment variables do not exist, you must create them.

The Redshift installer for Windows will automatically register the redshift4maya plugin based on the versions of Maya you selected on the 'Auto-configure Redshift plugins' installer screen. This is done by modifying the Maya.env file for the versions of Maya that were selected.

The section below describes how to perform the same steps that the installer performs automatically, as well as an alternative method of registering the redshift4maya plugin by using a module file.

The Redshift for Maya plugin installation directory includes batch files that let you perform the same registration step that are performed during installation. These batch files can be used, for example, if Maya is installed after Redshift and you wish to register the redshift4maya plugin without reinstalling Redshift. Simply run the batch file associated with the particular version of Maya you want to register the redshift4maya plugin.

An alternative method of registering the redshift4maya plugin is to use a Maya module file. Create a file namedredshift4maya.mod containing the following text (adjust the Maya version as necessary) and place the file in one of Maya's module directories (e.g.Documents\maya\modules).

This can be accomplished either by creating a Maya module file for Redshift, modifying the Maya.env file or by defining system environment variables. We recommend using a Maya module file as it requires the fewest steps as is the least prone to errors.

The installer for macOS automatically installs a module file for each version of Maya it detects on your system. If you have Maya installed in a non-standard location, or you install Mayaafter installing Redshift, you should copy the template module file/Applications/redshift//redshift4maya/redshift4maya.mod.template to a location that is part of Maya's module search paths. Note that the copy of the module template file redshift4maya.mod.template should be renamed to redshift4maya.mod.

Having gone through the Software Setup at least once you should be able to find the Maya.env file in the default location. C:/Users/Name/Documents/maya/VERSION/Maya.env for your VERSION of Maya. The other location will be in the result of the MEL script just used.

Open both Maya.env files and copy the lines that start with KB3D_ to the correct file (KB3D_PLUG_IN_PATH, KB3D_SCRIPT_PATH and KB3D_XBMLANGPATH). Make sure that the MAYA_PLUG_IN_PATH, MAYA_SCRIPT_PATH and XBMLANGPATH all have references to the Cargo-related environment variables.

3a8082e126