Re: [Maya-Python] Re: Maya C++ OpenGL linker issues

[Andrew Golubev]

Hey Reza!

Thank you for your answer!
So, an update from me. Good news -  I could build and compile it; thank you 
so much for your help! 

What helped is that, as you said, I added pluginEntry and launched the 
build_plugin() function inside of it.

A small thing to notice: I had to return to my previous semi-manual Qt 
setup because I could not make your solution work. I probably misunderstood 
something.

I'm unsure if I can continue torturing you with silly questions, haha. You 
are probably busy, and you have already helped me a lot. Thank you so much! 

Sorry, I'm still grasping things here and there with C++; just in case you 
have some desire/free time to answer:
1) What does vsvarsall.bat does?
2)  What is the set SDKS location?
SDKS_LOCATION=D:/myPath/sdks?
3) it seems to me, that you are using a separate qt library; maybe that is 
how I should do this. I was just thinking about using Qt, which is included 
in devkit; I mean this line in your offered solution:
set Qt5_DIR=%SDKS_LOCATION%/Qt5/lib/cmake

What I did at the moment and what worked - I manually linked all Qt libs 
and includes, which are included in the devkit. It is probably not the best 
solution (I would argue not even a good one), but it works.

I also wanted to ask on whether this is the only thing you do to include QT 
libraries in your build. If not, how do you link all the include and lib 
files into it? The only thing I can see you do in your reply is add this 
QT-related variable, Qt5_DIR, and that's it. Probably, I am missing 
something!

On Thursday, 9 November 2023 at 20:23:25 UTC Reza Aarabi wrote:

> No problem
>
> I add some other info I hope it helps
>
>
> - you don't need to set DEVKIT_LOCATION when you defined them in your env 
> vars or batch file
>
> - this is wrong: set(ENV{DEVKIT_LOCATION} 
> "${CMAKE_SOURCE_DIR}/external/devkitBase")
> - ENV will be used when you defined your env var outside of the 
> CMakeLists.txt so in this case you just need to use it like: $ENV{
> DEVKIT_LOCATION}
>
> - for Qt dependencies I told you you should use 
>
> find_package(Qt5 COMPONENTS Core Widgets Gui OpenGL REQUIRED)
> target_link_libraries($ENV{TARGET_NAME} Qt5::Core Qt5::Widgets Qt5::Gui 
> Qt5::OpenGL)
>
> - you don't need to add  CMAKE_MODULE_PATH  to your CMakeLists.txt file
> however, (I forgot to mention) you should define this env var 
> set Qt5_DIR=%SDKS_LOCATION%/Qt5/lib/cmake
> in your windows env var or your build.bat file
>
> - if you want to have multithreaded things, instead of 
>
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /MT")
> set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /MT")
>
> you can use this
> set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreadedDLL")
>
> this is my DEVKIT_OCATION
> in batch file:
> set SDKS_LOCATION=D:/myPath/sdks
> set DEVKIT_LOCATION=%SDKS_LOCATION%/Maya_2019
> in CMakeListx.txt file:
> include($ENV{DEVKIT_LOCATION}/cmake/pluginEntry.cmake) 
> - at the end, you don't need to set things like:
> CMAKE_MODULE_PATH 
> MAYA_INCLUDE_DIR
> MAYA_LIBRARIES
>
> all of these settings will be managed automatically
>
> you just need to have a cleaner CMakeLists.txt file and do things based on 
> this order: 
> 1. in *build.bat: * call the vcvarsall.bat
> @REM  VCVARS_LOCATION: C:\Program Files\Microsoft Visual 
> Studio\2022\Community\VC\Auxiliary\Build
> call "%VCVARS_LOCATION%/vcvarsall.bat" x64
> 2. in *build.bat: *Set your env Variables like :QT_DIR, DEVKIT_LOCATION, 
> ...
>
> 3. in *build.bat: *call the cmake command from inside build directory
> cd build
> cmake -G "Visual Studio 17 2022" -A x64 ..
> 4. in *CMakeLists.txt*: active the maya module finder:
> include($ENV{DEVKIT_LOCATION}/cmake/pluginEntry.cmake)
>
> 5. in *CMakeLists.txt*: turn on Automatic builder of QT
> set(CMAKE_AUTOMOC ON)
> set(CMAKE_AUTORCC ON)
> set(CMAKE_AUTOUIC ON)
>
> 6. in *CMakeLists.txt: *Set your Project files and your libraries, or 
> maya libraries like *OpenMaya*, *Foundation*
>
> 7. in *CMakeLists.txt: *call this function of maya cmake module: 
> build_plugin()
> 8. in *CMakeLists.txt: *adding Qt related dependencies:
> find_package(Qt5 COMPONENTS Core Widgets Gui REQUIRED)
> target_link_libraries($ENV{TARGET_NAME} Qt5::Core Qt5::Widgets Qt5::Gui)
> I hope it is detailed enough
> this is the way I usually work, there are lots of ways to build softwares, 
> all experimental and true, just need to follow errors! let us know if you 
> need more data
> cheers 
>
>
> On Wed, Nov 8, 2023 at 6:44 PM Andrew Golubev  wrote:
>
>> Hey Reza! 
>> Thank you so much for your answer, I really appreciate it!
>>
>> So I tried to do as you said and rework a little my cmake files build

Re: [Maya-Python] Re: Maya C++ OpenGL linker issues

[Andrew Golubev]

 PRIVATE 
${MAYA_INCLUDE_DIR}
"${EXTERNAL_DIR}/boost_1_83_0"
"${BULLET_ROOT}/src"
PUBLIC 
"${CMAKE_CURRENT_BINARY_DIR}" 
"${CMAKE_CURRENT_SOURCE_DIR}"
)

target_link_libraries(${PROJECT_NAME} PRIVATE 
${MAYA_LIBRARIES} 
Qt5::Core 
Qt5::Widgets 
Qt5::Gui 
Qt5::OpenGL 
BulletDynamics 
BulletCollision 
LinearMath
)

# Your custom MAYA_PLUGIN function/macro - make sure it is defined before 
this call
MAYA_PLUGIN(${PROJECT_NAME})

install(TARGETS ${PROJECT_NAME} ${MAYA_TARGET_TYPE} DESTINATION plug-ins/
${MAYA_VERSION})

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /MT")
set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /MT")



FindMaya.cmake I took version from Chad Vernon:
https://github.com/chadmv/cgcmake/blob/master/modules/FindMaya.cmake

FindMaya_Qt.cmake from AutodeskUSD repo:
https://github.com/Autodesk/maya-usd/blob/dev/cmake/modules/FindMaya_Qt.cmake
On Wednesday, 8 November 2023 at 00:42:01 UTC Reza Aarabi wrote:

> Hello My Friend
>
> I don't know how did you manage your CMakeLists.txt file and your build 
> system, so it should be related to many things, from Visual Studio version, 
> to debug and release versions of your build ... but specifically about 
> building Qt5 related UIs with *.mll *plugins of maya ( I did it 
> experimentally years ago) and for finding Qt related cmake config, you 
> should be able to build your tool successfully if you have these:
>
> - In your CmakeLists.txt you should have these settings 
> include($ENV{DEVKIT_LOCATION}/cmake/pluginEntry.cmake)
> $ENV{DEVKIT_LOCATION}: is my Env Variable of the Maya SDKS root location
> You should enable these settings for Qt: 
> set(CMAKE_AUTOMOC ON)
> set(CMAKE_AUTORCC ON)
> set(CMAKE_AUTOUIC ON)
>
> After adding your Source files and Maya Libraries 
> # set SOURCE_FILES
> set(SOURCE_FILES
> myPlugin.cpp
> main.cpp
> )
>
> # set linking libraries
> set(LIBRARIES
>  OpenMaya
>  Foundation
> )
>
> You should add codes like this:
> # Build plugin
> build_plugin() # this will be find in maya sdk cmake config file
>
> find_package(Qt5 COMPONENTS Core Widgets Gui OpenGL REQUIRED)
> target_link_libraries($ENV{TARGET_NAME} Qt5::Core Qt5::Widgets Qt5::Gui 
> Qt5::OpenGL)
> $ENV{TARGET_NAME}: you can set TARGET_NAME or PROJECT_NAME as your plugin 
> name 
> - I recommend to build your project through cmake with: 
>
> cd build 
> cmake -G "Visual Studio 17 2022" -A x64 ..
>
> - It seems you are using GL/gl.h that I'm not sure it is related to Maya 
> or QT, but for OpenGL try to add this line to your CMakeLists.txt too 
> find_package(OpenGL REQUIRED)
> Then open .sln file inside Visual Studio and build it in Debug and release 
> mode and see the difference!
> I hope it helps you, if you have more Questions, please provide more data 
> like your CMakeLists.txt or build.bat file We can help more 
>
>
>
> On Tue, Nov 7, 2023 at 10:00 AM Andrew Golubev  wrote:
>
>> Yeah, I downloaded the devkit, extracted it and linked all included QT 
>> Libs.
>> I will have a look with DependencyWalker; it may be more apparent with 
>> which exact dll is missing; thank you!
>> It seems that overall, QT is working there, but when I override some 
>> OpenGL functions, I have this error.
>> On Tuesday, 7 November 2023 at 15:22:02 UTC Marcus Ottosson wrote:
>>
>>> This rings a bell, but it's too late in the day to hear which one. Are 
>>> you linking with QtCore and relevant Qt binaries?
>>>
>>> There's this neat tool you can try, which lists relevant dependencies of 
>>> a binary, including a Maya .mll
>>>
>>> - https://dependencywalker.com/
>>>
>>> [image: Screenshot 2023-11-07 152019.jpg]
>>>
>>> On Tuesday, 7 November 2023 at 15:09:16 UTC golu...@gmail.com wrote:
>>>
>>>> Hey everyone!
>>>> I hope you are all doing well)
>>>>
>>>> I wanted to ask a question about Maya C++ plugin building. I'm 
>>>> currently struggling with an issue I can't resolve for a couple of days.
>>>>
>>>> I created a custom context with manips, and it is working and building 
>>>> very well, but at some point, I needed to create a small QDialog with QT 
>>>> libraries, which uses OpenGL, and this is my main issue. I downloaded Maya 
>>>> Devkit, added a linker and include libs.
>>>>
>>>> I also tried to use FindMaya_Qt.cmake from the Autodesk USD repository. 
>>>> But I can't go over a linker error, which appears during compilation.It 
>&

[Maya-Python] Re: Maya C++ OpenGL linker issues

[Andrew Golubev]

Yeah, I downloaded the devkit, extracted it and linked all included QT Libs.
I will have a look with DependencyWalker; it may be more apparent with 
which exact dll is missing; thank you!
It seems that overall, QT is working there, but when I override some OpenGL 
functions, I have this error.
On Tuesday, 7 November 2023 at 15:22:02 UTC Marcus Ottosson wrote:

> This rings a bell, but it's too late in the day to hear which one. Are you 
> linking with QtCore and relevant Qt binaries?
>
> There's this neat tool you can try, which lists relevant dependencies of a 
> binary, including a Maya .mll
>
> - https://dependencywalker.com/
>
> [image: Screenshot 2023-11-07 152019.jpg]
>
> On Tuesday, 7 November 2023 at 15:09:16 UTC golu...@gmail.com wrote:
>
>> Hey everyone!
>> I hope you are all doing well)
>>
>> I wanted to ask a question about Maya C++ plugin building. I'm currently 
>> struggling with an issue I can't resolve for a couple of days.
>>
>> I created a custom context with manips, and it is working and building 
>> very well, but at some point, I needed to create a small QDialog with QT 
>> libraries, which uses OpenGL, and this is my main issue. I downloaded Maya 
>> Devkit, added a linker and include libs.
>>
>> I also tried to use FindMaya_Qt.cmake from the Autodesk USD repository. 
>> But I can't go over a linker error, which appears during compilation.It 
>> seems to me that some DLLs or libraries are missing, but I don't get which 
>> one. Maybe someone had a similar issue?
>>
>> I also tried to add opengl32.dll but it doesn't do nothing. It seems to 
>> me that something is wrong with my Qt config, or cpp class which uses 
>> OpenGL.
>>
>>  
>>
>> Here is my errors from Visual studio:
>> Severity Code Description Project File Line Suppression State Error 
>> LNK2019 unresolved external symbol __imp_glViewport referenced in function 
>> "protected: 
>> virtual void __cdecl DebugRenderer::resizeGL(int,int)" (?
>> resizeGL@DebugRenderer@@MEAAXHH@Z) maya_plugin C:
>> \Users\golub\Documents\maya_plugin\build\src\debugDialog.obj 1 Error 
>> LNK2019 unresolved external symbol __imp_glBegin referenced in function 
>> "protected: 
>> virtual void __cdecl DebugRenderer::paintGL(void)" (?
>> paintGL@DebugRenderer@@MEAAXXZ) maya_plugin C:
>> \Users\golub\Documents\maya_plugin\build\src\debugDialog.obj 1 Error 
>> LNK2019 unresolved external symbol __imp_glClear referenced in function 
>> "protected: 
>> virtual void __cdecl DebugRenderer::paintGL(void)" (?
>> paintGL@DebugRenderer@@MEAAXXZ) maya_plugin C:
>> \Users\golub\Documents\maya_plugin\build\src\debugDialog.obj 1 Error 
>> LNK2019 unresolved external symbol __imp_glClearColor referenced in 
>> function "protected: virtual void __cdecl 
>> DebugRenderer::initializeGL(void)" (?initializeGL@DebugRenderer@@MEAAXXZ) 
>> maya_plugin C:\Users\golub\Documents\maya_plugin\build\src\debugDialog.obj 
>> 1 Error LNK2019 unresolved external symbol __imp_glColor3f referenced in 
>> function "protected: virtual void __cdecl DebugRenderer::paintGL(void)" (
>> ?paintGL@DebugRenderer@@MEAAXXZ) maya_plugin C:
>> \Users\golub\Documents\maya_plugin\build\src\debugDialog.obj 1 Error 
>> LNK2019 unresolved external symbol __imp_glEnd referenced in function 
>> "protected: 
>> virtual void __cdecl DebugRenderer::paintGL(void)" (?
>> paintGL@DebugRenderer@@MEAAXXZ) maya_plugin C:
>> \Users\golub\Documents\maya_plugin\build\src\debugDialog.obj 1 Error 
>> LNK2019 unresolved external symbol __imp_glVertex3f referenced in function 
>> "protected: 
>> virtual void __cdecl DebugRenderer::paintGL(void)" (?
>> paintGL@DebugRenderer@@MEAAXXZ) maya_plugin C:
>> \Users\golub\Documents\maya_plugin\build\src\debugDialog.obj 1
>>
>>  
>>
>> And also, class which gives me an error:
>> #pragma once #include  #include 
>>  #include  #include 
>>  #include  #include 
>>  #include  #include 
>>  #include  class DebugRenderer : public 
>> QOpenGLWidget, protected QOpenGLFunctions { // Updated inheritance public
>> : DebugRenderer(rp3d::PhysicsWorld* physicsWorld, QWidget* parent = 
>> nullptr); protected: void initializeGL() override; void resizeGL(int w, 
>> int h) override; void paintGL() override; private: rp3d::PhysicsWorld* 
>> physicsWorld; }; class DebugDialog : public QDialog { public: DebugDialog
>> (rp3d::PhysicsWorld* physicsWorld, QWidget* parent = nullptr); };
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to python_inside_maya+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/9e1a9f52-abaf-4f9d-86b1-e1ed43c7ac2fn%40googlegroups.com.

[Maya-Python] Maya C++ OpenGL linker issues

[Andrew Golubev]

Hey everyone!
I hope you are all doing well)

I wanted to ask a question about Maya C++ plugin building. I'm currently 
struggling with an issue I can't resolve for a couple of days.

I created a custom context with manips, and it is working and building very 
well, but at some point, I needed to create a small QDialog with QT 
libraries, which uses OpenGL, and this is my main issue. I downloaded Maya 
Devkit, added a linker and include libs.

I also tried to use FindMaya_Qt.cmake from the Autodesk USD repository. But 
I can't go over a linker error, which appears during compilation.It seems 
to me that some DLLs or libraries are missing, but I don't get which one. 
Maybe someone had a similar issue?

I also tried to add opengl32.dll but it doesn't do nothing. It seems to me 
that something is wrong with my Qt config, or cpp class which uses OpenGL.

 

Here is my errors from Visual studio:
Severity Code Description Project File Line Suppression State Error LNK2019 
unresolved external symbol __imp_glViewport referenced in function "protected: 
virtual void __cdecl DebugRenderer::resizeGL(int,int)" (?
resizeGL@DebugRenderer@@MEAAXHH@Z) maya_plugin C:
\Users\golub\Documents\maya_plugin\build\src\debugDialog.obj 1 Error 
LNK2019 unresolved external symbol __imp_glBegin referenced in function 
"protected: 
virtual void __cdecl DebugRenderer::paintGL(void)" (?
paintGL@DebugRenderer@@MEAAXXZ) maya_plugin C:
\Users\golub\Documents\maya_plugin\build\src\debugDialog.obj 1 Error 
LNK2019 unresolved external symbol __imp_glClear referenced in function 
"protected: 
virtual void __cdecl DebugRenderer::paintGL(void)" (?
paintGL@DebugRenderer@@MEAAXXZ) maya_plugin C:
\Users\golub\Documents\maya_plugin\build\src\debugDialog.obj 1 Error 
LNK2019 unresolved external symbol __imp_glClearColor referenced in 
function "protected: virtual void __cdecl DebugRenderer::initializeGL(void)" 
(?initializeGL@DebugRenderer@@MEAAXXZ) maya_plugin C:
\Users\golub\Documents\maya_plugin\build\src\debugDialog.obj 1 Error 
LNK2019 unresolved external symbol __imp_glColor3f referenced in function 
"protected: 
virtual void __cdecl DebugRenderer::paintGL(void)" (?
paintGL@DebugRenderer@@MEAAXXZ) maya_plugin C:
\Users\golub\Documents\maya_plugin\build\src\debugDialog.obj 1 Error 
LNK2019 unresolved external symbol __imp_glEnd referenced in function 
"protected: 
virtual void __cdecl DebugRenderer::paintGL(void)" (?
paintGL@DebugRenderer@@MEAAXXZ) maya_plugin C:
\Users\golub\Documents\maya_plugin\build\src\debugDialog.obj 1 Error 
LNK2019 unresolved external symbol __imp_glVertex3f referenced in function 
"protected: 
virtual void __cdecl DebugRenderer::paintGL(void)" (?
paintGL@DebugRenderer@@MEAAXXZ) maya_plugin C:
\Users\golub\Documents\maya_plugin\build\src\debugDialog.obj 1

 

And also, class which gives me an error:
#pragma once #include  #include 
 #include  #include 
 #include  #include 
 #include  #include 
 #include  class DebugRenderer : public 
QOpenGLWidget, protected QOpenGLFunctions { // Updated inheritance public: 
DebugRenderer(rp3d::PhysicsWorld* physicsWorld, QWidget* parent = nullptr); 
protected: void initializeGL() override; void resizeGL(int w, int h) 
override; void paintGL() override; private: rp3d::PhysicsWorld* physicsWorld
; }; class DebugDialog : public QDialog { public: DebugDialog(rp3d::
PhysicsWorld* physicsWorld, QWidget* parent = nullptr); };

-- 
You received this message because you are subscribed to the Google Groups 
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to python_inside_maya+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/d4f4a701-9cfe-4ea7-bf4e-ce90ad95e020n%40googlegroups.com.

[Maya-Python] PolygonMesh recreation with same edge indexes

[Andrew Golubev]

Hello everyone!
I stuck with some problem, i have a script which stores polygon data and 
later recreates it, it working all good except one thing - it have broken 
edges index order, so vertex indexes are the same, faces indexes are the 
same, but edges are does not match in source mesh and recreated mesh. Maybe 
someone have something simular?

Simple code example which will created default sphere and recreate it with 
Python API.
And edges order will not match...

import maya.OpenMaya as OpenMaya
import maya.mel as mel

def get_polygon_data(mObj):
conpolyList = []
num_of_vers_per_poly = []
vertex_positions = OpenMaya.MPointArray()

# Create an iterator for the polygons of the mesh
iterPolys = OpenMaya.MItMeshPolygon( mObj )
vtx_offest = 0
# Iterate through polys on current mesh
while not iterPolys.isDone():
verts_positions = OpenMaya.MPointArray ()
iterPolys.getPoints( verts_positions )   

verts = OpenMaya.MIntArray()
iterPolys.getVertices( verts )

for v in reversed(verts):
conpolyList.append (v)
num_of_vers_per_poly.append(verts.length())

iterPolys.next()

iterVertex = OpenMaya.MItMeshVertex( mObj)
while not iterVertex.isDone():
mpoint = iterVertex.position()
vertex_positions.append(mpoint)
iterVertex.next()

vertex_positions = 
convert_mpoint_array_to_float_list_array(vertex_positions)

return vertex_positions, num_of_vers_per_poly, conpolyList

def get_mesh_creation_data(mesh_dag_path):

"""
Returns all mesh data, which needed to recreate surface.
:param mesh_dag_path: string with node dag_path
:returns result: dict with all mesh creation data.
"""

result = dict()

selection_list = OpenMaya.MSelectionList()
selection_list.add(mesh_dag_path)
dag_path = OpenMaya.MDagPath()
mobject = OpenMaya.MObject()
selection_list.getDagPath(0, dag_path)
selection_list.getDependNode(0, mobject)
mfn_mesh = OpenMaya.MFnMesh(dag_path)

vertex_positions, number_of_vertices_per_polygon, polygon_vertex_ids = 
get_polygon_data(mfn_mesh.object())

result["vertex_positions_raw_data"] = vertex_positions
result["number_of_vertices_per_polygon"] = 
number_of_vertices_per_polygon
result["vertex_indexes_per_polygon"] = polygon_vertex_ids
result["polygon_count"] = mfn_mesh.numPolygons()

return result

def create_mesh(mesh_creation_data, parent_mobj = None):
polygon_count = mesh_creation_data["polygon_count"]
vertex_positions_raw_data = 
mesh_creation_data["vertex_positions_raw_data"]
number_of_vertices_per_polygon = 
mesh_creation_data["number_of_vertices_per_polygon"]
vertex_indexes_per_polygon = 
mesh_creation_data["vertex_indexes_per_polygon"]
vertex_positions_mfloatpoints = 
convert_float_lists_array_to_mpoints_array(vertex_positions_raw_data)
meshFn = OpenMaya.MFnMesh()

try:
vertex_count = vertex_positions_mfloatpoints.length()
each_polygon_vertex_count = 
convert_floats_to_MIntArray(number_of_vertices_per_polygon)
polygon_connects = 
convert_floats_to_MIntArray(vertex_indexes_per_polygon)

createdMobject = meshFn.create(vertex_count, polygon_count, 
vertex_positions_mfloatpoints, each_polygon_vertex_count, polygon_connects)
return createdMobject
except Exception as e:
print(e)

def get_polygons_vertex_data(mfn_mesh):

"""
Returns polygon vertex ids for given mesh.
(what vertex each polygon have, vertex defined by vertex id)
:param mesh: string dag path to mesh
:returns list: list of vertex id's per polygon
"""

if mfn_mesh:
connected_polygons_list = []
number_of_vertices_per_polygon = []
# This shows how to use the MItMeshPolygon class to work with 
meshes 
# Create an iterator for the polygons of the mesh
polys_iterator = OpenMaya.MItMeshPolygon( mfn_mesh.object() )
# Iterate through polys on current mesh
while not polys_iterator.isDone():
index_connected_faces = OpenMaya.MIntArray()
polys_iterator.getConnectedFaces(index_connected_faces)

for i in range( index_connected_faces.length() ):
connected_polygons_list.append (index_connected_faces[i])


number_of_vertices_per_polygon.append(index_connected_faces.length())
polys_iterator.next()


return connected_polygons_list, number_of_vertices_per_polygon

def get_vertex_pos_of_mesh(mfn_mesh, as_mpoint_array=False):

"""
Returns vertex positions of given mesh.
:param mesh: string dag path to mesh
:param as_mpoint_array: if True, function will return vertex positions 
as array of OpenMaya.MPoint objects,
by defaul False mean it will return vertex 
positions as as floats array
:returns list: by default returns list of integers with point 

Re: [Maya-Python] How To get the NurbsPlane's "patchesV" & "patchesU" data

[Andrew Golubev]

You can try to get them with OpenMaya:

import maya.OpenMaya as OpenMaya

#nurbs surface sphere name
node_name = "nurbsPlaneShape1"

#get shape m_obj
selList = OpenMaya.MSelectionList()
selList.add(node_name)
mobj = OpenMaya.MObject()
selList.getDependNode(0, mobj)

#create mfnnurbssurface and retrieve data from it
mfnNurbsSurface_from_dag = OpenMaya.MFnNurbsSurface(mobj)
patches_u = mfnNurbsSurface_from_dag.numPatchesInU()
patches_v = mfnNurbsSurface_from_dag.numPatchesInV()

чт, 23 сент. 2021 г. в 19:57, Anas Elkinawy :

> How To get the NurbsPlane's "patchesV" & "patchesU" data for deleted
> history nurbsplane
>
> --
> You received this message because you are subscribed to the Google Groups
> "Python Programming for Autodesk Maya" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to python_inside_maya+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/python_inside_maya/c074570e-7667-4bb1-93d7-5645558cd61en%40googlegroups.com
> <https://groups.google.com/d/msgid/python_inside_maya/c074570e-7667-4bb1-93d7-5645558cd61en%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
---
Best regards,
Andrew Golubev

-- 
You received this message because you are subscribed to the Google Groups 
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to python_inside_maya+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/CAMwYa7qBtY2fQ2GhwnWreMQL3ZNZ8jCNO8ZfC6%2BgTmcqEb%3DEMw%40mail.gmail.com.

Re: [Maya-Python] V Crypt System

[Andrew Golubev]

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, sorry, yes it is already protected, but if this 
protected scene to /myrig.mb will be referenced in the main scene, during 
the main parent scene opening, I will need to decrypt my rig.mb and any 
other child scene which is referenced and send to a remote worker,
or I understand you wrong)

About RAM I'm sorry, that's my mistake, later edited the message, but was 
too late, you absolutely right!

понедельник, 6 сентября 2021 г. в 13:27:48 UTC+3, Marcus Ottosson: 

> 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 
> there’s no end to that. Screenshotting your viewport is a format too, 
> albeit a lossy one. But I’d argue that depending on what you want to 
> protect, if that is rigs and animation, the Maya scene format should be 
> enough.
>
>- OpenMaya.MSceneMessage.addCheckCallback() 
>
> <https://help.autodesk.com/view/MAYAUL/2020/ENU/?guid=__py_ref_class_open_maya_1_1_m_scene_message_html#a2c26fb924ad7939fd6bf50253044a7d3>
>  
>
> And all of it must be done recursively on the whole data tree in scene
>
> I’d argue not. The information you protect is the information in the scene 
> file. If that scene file consists of an absolute path to e.g. 
> c:\myassets\myrig.mb then that is *already* protected; nobody can access 
> that file but you on your local machine.
>
> so at some point how to handle your RAM memory, because you can’t store 
> this encrypted data somewhere…)
>
> I’d argue not (again :)). Is it to protect against hacker-animators and 
> hacker-riggers? Or against the general workforce that has no clue about 
> callbacks and encryption? If the latter, then saving it into a temp 
> directory first, and encrypting it after should suffice. To the user, the 
> file would end up where they said it should. But really, it’s a different 
> file altogether. Then that file is copied back into a temp directory and 
> decrypted whenever they open it. All of that can happen on disk.
>
> And besides, memory is just another location. A motivated-enough 
> hacker-animator could access RAM as easily as any location on disk. Doesn’t 
> increase the level of protection.
>
> On Mon, 6 Sept 2021 at 11:02, Andrew Golubev  wrote:
>
>> 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 exporting of data inside in any format, 
>> hide\lock\encrypt code of all used inside scripts, lock any new plugin 
>> loading\or current plugins disabling. 
>> And lock script editor, or make some sort of interceptor, to ensure, that 
>> no script will run to export or explore private scene data. 
>> Also, if I understand all correctly, it will give a lot of restrictions 
>> for people who work with their tools(it will lock them on the layout of 
>> instruments you gave to them).
>>
>> And this only stuff that comes up to mind immediately, I think during the 
>> development of such Maya launch wrapper lot's of underwater stones will 
>> come up eventually.
>>
>> 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.
>> All of it must be done recursively on the whole data tree in scene,
>> so at some point how to handle your RAM memory, because you can't store 
>> this encrypted data somewhere.
>>
>> And even this will not save you from attempt to try take this decrypted 
>> data from RAM...
>> воскресенье, 5 сентября 2021 г. в 10:27:53 UTC+3, Marcus Ottosson: 
>>
>>> 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 have limited internet access wi

Re: [Maya-Python] V Crypt System

[Andrew Golubev]

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 exporting of data inside in any format, 
hide\lock\encrypt code of all used inside scripts, lock any new plugin 
loading\or current plugins disabling. 
And lock script editor, or make some sort of interceptor, to ensure, that 
no script will run to export or explore private scene data. 
Also, if I understand all correctly, it will give a lot of restrictions for 
people who work with their tools(it will lock them on the layout of 
instruments you gave to them).

And this only stuff that comes up to mind immediately, I think during the 
development of such Maya launch wrapper lot's of underwater stones will 
come up eventually.

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.
All of it must be done recursively on the whole data tree in scene,
so at some point how to handle your RAM memory, because you can't store 
this encrypted data somewhere.

And even this will not save you from attempt to try take this decrypted 
data from RAM...
воскресенье, 5 сентября 2021 г. в 10:27:53 UTC+3, Marcus Ottosson: 

> 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 
> have limited internet access with local browsers accessible only through a 
> virtual machine or local VNC connection, and assets *still* manage to leave 
> the premises.
>
> That not only puts the studio at risk, but the recipient too. Both as a 
> private person, as now your machine can leak confidential material, and as 
> another business. If a leak should happen that leads to loss of cash for 
> any larger entity such as WB there will be investigations and consequences. 
> Private persons can get in trouble and businesses can crumble.
>
> The part I'm sceptical about is whether this particular tool is what 
> solves this problem. If it complicates saving and loading of scenes (and 
> even launching of Maya?) then I'd imagine people simply would not use it. 
> But the idea sounds worth exploring, so off the top of my head I would try 
> implementing a scene save/open callback to perform the encryption live and 
> natively, rather than rely on an external tool. It could be as simple as 
> letting Maya produce that binary `.mb` file of 1's and 0's, and reversing 
> the whole thing on save, and then do the opposite on load. No one would 
> know it happened, and it would unlikely have any noticeable effect on 
> save/load time, and there are equal callbacks for exporting.
>
> On Sat, 4 Sept 2021 at 22:26, Rudi Hammad  wrote:
>
>> 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 will loose a 
>> lot of work.
>> Also  many studios have not the resources , and even if they do, the lag 
>> is some times to high to work remotly.
>>
>> Many times sharing is accidental due to the lack of control, or planning 
>> in a production. In my experience I was doing a freelance work a couple of 
>> month a go. And we where all working remotly in our personal computers.
>> The supervisor at somepoint, sent me a rig from another project as a 
>> reference. So obviously that was accidental because working in this 
>> situations like that, you do always thing that you are doing anywrong.
>> So even if you sign NDAs, and you have good intentions, it can leak. And 
>> of course, there is always people with bad intentions, so we can't be naive 
>> thinking that everyone will be professional. I work with a guy who managed
>> to get rigs that he shouldn't have. When I asked how did he get them, he 
>> told me he took them out of the office in his last day.
>>
>> My point being, that with a system like V Crypt, wheter it is by accident 
>> or not, it might be the solution to encrypt files and safely work as 
>> freelance (specially for me since now I am full time freelancer)
>>
>> I'll keep you posted
>>
>> El sábado, 4 de septiembre de 2021 a las 22:59:06 UTC+2, 
>> justin...@gmail.com escribió:
>>
>>> 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 
 

Re: [Maya-Python] V Crypt System

[Andrew Golubev]

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 point how to handle your RAM memory, because you can't store 
this encrypted data somewhere...)

понедельник, 6 сентября 2021 г. в 12:14:38 UTC+3, Andrew Golubev: 

> 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 exporting of data inside in any format, 
> hide\lock\encrypt code of all used inside scripts, lock any new plugin 
> loading\or current plugins disabling. 
> And lock script editor, or make some sort of interceptor, to ensure, that 
> no script will run to export or explore private scene data. 
> Also, if I understand all correctly, it will give a lot of restrictions 
> for people who work with their tools(it will lock them on the layout of 
> instruments you gave to them).
>
> And this only stuff that comes up to mind immediately, I think during the 
> development of such Maya launch wrapper lot's of underwater stones will 
> come up eventually.
> But I must admit that it is a very cool task to work on!:D
> воскресенье, 5 сентября 2021 г. в 10:27:53 UTC+3, Marcus Ottosson: 
>
>> 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 have limited internet access with local browsers accessible only 
>> through a virtual machine or local VNC connection, and assets *still* 
>> manage to leave the premises.
>>
>> That not only puts the studio at risk, but the recipient too. Both as a 
>> private person, as now your machine can leak confidential material, and as 
>> another business. If a leak should happen that leads to loss of cash for 
>> any larger entity such as WB there will be investigations and consequences. 
>> Private persons can get in trouble and businesses can crumble.
>>
>> The part I'm sceptical about is whether this particular tool is what 
>> solves this problem. If it complicates saving and loading of scenes (and 
>> even launching of Maya?) then I'd imagine people simply would not use it. 
>> But the idea sounds worth exploring, so off the top of my head I would try 
>> implementing a scene save/open callback to perform the encryption live and 
>> natively, rather than rely on an external tool. It could be as simple as 
>> letting Maya produce that binary `.mb` file of 1's and 0's, and reversing 
>> the whole thing on save, and then do the opposite on load. No one would 
>> know it happened, and it would unlikely have any noticeable effect on 
>> save/load time, and there are equal callbacks for exporting.
>>
>> On Sat, 4 Sept 2021 at 22:26, Rudi Hammad  wrote:
>>
>>> 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 will loose a 
>>> lot of work.
>>> Also  many studios have not the resources , and even if they do, the lag 
>>> is some times to high to work remotly.
>>>
>>> Many times sharing is accidental due to the lack of control, or planning 
>>> in a production. In my experience I was doing a freelance work a couple of 
>>> month a go. And we where all working remotly in our personal computers.
>>> The supervisor at somepoint, sent me a rig from another project as a 
>>> reference. So obviously that was accidental because working in this 
>>> situations like that, you do always thing that you are doing anywrong.
>>> So even if you sign NDAs, and you have good intentions, it can leak. And 
>>> of course, there is always people with bad intentions, so we can't be naive 
>>> thinking that everyone will be professional. I work with a guy who managed
>>> to get rigs that he shouldn't have. When I asked how did he get them, he 
>>> told me he took them out of the office in his last day.
>>

Re: [Maya-Python] V Crypt System

[Andrew Golubev]

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 exporting of data inside in any format, 
hide\lock\encrypt code of all used inside scripts, lock any new plugin 
loading\or current plugins disabling. 
And lock script editor, or make some sort of interceptor, to ensure, that 
no script will run to export or explore private scene data. 
Also, if I understand all correctly, it will give a lot of restrictions for 
people who work with their tools(it will lock them on the layout of 
instruments you gave to them).

And this only stuff that comes up to mind immediately, I think during the 
development of such Maya launch wrapper lot's of underwater stones will 
come up eventually.
But I must admit that it is a very cool task to work on!:D
воскресенье, 5 сентября 2021 г. в 10:27:53 UTC+3, Marcus Ottosson: 

> 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 
> have limited internet access with local browsers accessible only through a 
> virtual machine or local VNC connection, and assets *still* manage to leave 
> the premises.
>
> That not only puts the studio at risk, but the recipient too. Both as a 
> private person, as now your machine can leak confidential material, and as 
> another business. If a leak should happen that leads to loss of cash for 
> any larger entity such as WB there will be investigations and consequences. 
> Private persons can get in trouble and businesses can crumble.
>
> The part I'm sceptical about is whether this particular tool is what 
> solves this problem. If it complicates saving and loading of scenes (and 
> even launching of Maya?) then I'd imagine people simply would not use it. 
> But the idea sounds worth exploring, so off the top of my head I would try 
> implementing a scene save/open callback to perform the encryption live and 
> natively, rather than rely on an external tool. It could be as simple as 
> letting Maya produce that binary `.mb` file of 1's and 0's, and reversing 
> the whole thing on save, and then do the opposite on load. No one would 
> know it happened, and it would unlikely have any noticeable effect on 
> save/load time, and there are equal callbacks for exporting.
>
> On Sat, 4 Sept 2021 at 22:26, Rudi Hammad  wrote:
>
>> 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 will loose a 
>> lot of work.
>> Also  many studios have not the resources , and even if they do, the lag 
>> is some times to high to work remotly.
>>
>> Many times sharing is accidental due to the lack of control, or planning 
>> in a production. In my experience I was doing a freelance work a couple of 
>> month a go. And we where all working remotly in our personal computers.
>> The supervisor at somepoint, sent me a rig from another project as a 
>> reference. So obviously that was accidental because working in this 
>> situations like that, you do always thing that you are doing anywrong.
>> So even if you sign NDAs, and you have good intentions, it can leak. And 
>> of course, there is always people with bad intentions, so we can't be naive 
>> thinking that everyone will be professional. I work with a guy who managed
>> to get rigs that he shouldn't have. When I asked how did he get them, he 
>> told me he took them out of the office in his last day.
>>
>> My point being, that with a system like V Crypt, wheter it is by accident 
>> or not, it might be the solution to encrypt files and safely work as 
>> freelance (specially for me since now I am full time freelancer)
>>
>> I'll keep you posted
>>
>> El sábado, 4 de septiembre de 2021 a las 22:59:06 UTC+2, 
>> justin...@gmail.com escribió:
>>
>>> 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 if someone 
 wanted to send some model or some rig, they could still just export it to 
 a 
 new .ma? For that, you’d probably be better off intermingling it with 
 custom nodes. Like how anything rigged with mGear is riddled with mGear 
 nodes, making anyone attempting to open that rig without 

[Maya-Python] Re: Change viewport renderer with Python API

[Andrew Golubev]

Hi! Thank you for reply!
Currently i'm using almoust the same as you written, 
but with python and cmds: cmds.modelEditor() command with proper flags.

I was intrested how to do the same operation with Python API

среда, 25 августа 2021 г. в 06:55:46 UTC+3, wwn150...@gmail.com: 

> you could use mel function 
>
> setRendererInModelPanel $gViewport2  your_model_panel   # viewport 2.0
>
> setRendererInModelPanel $gLegacyViewport  your_model_panel  ;  # viewport 
> 1.0
>
>
>
>
>
> 在2021年8月23日星期一 UTC+8 下午5:26:25 写道：
>
>> Hello everyone!
>>
>> Stuck with some problem, using maya 2017, and i need to change viewport 
>> rendere to viewport 2.0, how can i do this with Python API?
>> Cannot find such option in documentation,
>> what i founded i can check what RendererName 
>> 
>>  currently 
>> used as enum parameter of
>> M3dView  object of current viewport with getRendererName(), but there is 
>> no setRenderer , and i cannot change param directly without setter.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to python_inside_maya+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/fca8870f-e97d-4561-b9cb-ebaf70f9191en%40googlegroups.com.

Re: [Maya-Python] Optimising scene

[Andrew Golubev]

Do you have proxies in your scene? 

If your propses referenced, 
you can use simplified proxy geometries for them, which will be only 
visible in the viewport, it will increase interactivity and loading times, 
but during rendering, it will load full geometry (through Maya Proxy 
Manager).
Also, if you have heavy rigs in the scene it will be a good idea to bake 
them into a cache, rigs can be very heavy, cached geo will significantly 
help.


вторник, 17 августа 2021 г. в 19:15:08 UTC+3, nirmal...@gmail.com: 

> Apologies for being vague. I'm pretty new to optimizing stuff .
>
> I use a  16gb machine , loading the scene from my hard drive and its 
> approximately taking around 2mins to just load , and the frame rate drops 
> as we play the scene.
> I've so far tried turning off the visibility of the items as I load and it 
> loads in 45sec , however once I try to turn on the visibility it becomes 
> very slow and I need to have all my GEOs on .
>
>
>
> On Tuesday, August 17, 2021 at 8:41:49 PM UTC+5:30 Marcus Ottosson wrote:
>
>> A question of few words, huh. :)
>>
>> - What does your "complex environment" look like?
>> - What is performance like currently?
>> - How long does it take to load already?
>> - What performance do you hope to achieve?
>> - What is your computer specs?
>> - What is your environment, e.g. loading files off a shared network 
>> drive, or mounted RAM?
>> - What have you already tried?
>> - What worked?
>> - What didn't work?
>>
>> At this point, we've spent more time asking you about your question then 
>> you have spent asking it haha. Let's turn that around?
>>
>> On Tue, 17 Aug 2021 at 16:03, Nirmal Kumar  wrote:
>>
>>>
>>> I'm optimizing for performance and for quicker loading up the scene . 
>>> I'm basically trying to optimize a complex environment.
>>> On Tuesday, August 17, 2021 at 7:34:03 PM UTC+5:30 golu...@gmail.com 
>>> wrote:
>>>
 Hi!
 What actually you would like to optimize? Viewport interactivity? 
 Render time? Animation interactivity? 
 What do you have in the scene - is it environment, is it includes heavy 
 rigs, and so on. 
 Please provide more information about the problem for us to try to help 
 you.

 вторник, 17 августа 2021 г. в 16:58:36 UTC+3, Marcus Ottosson: 

> Great question, but vague question.
>
> Optimise for what? Performance? Disk space? Memory? Marketability? 
> Ease of use? Monetary value? Maximum Facebook friends? Some of those you 
> can achieve with Python.
>
> On Tue, 17 Aug 2021 at 14:42, Nirmal Kumar  
> wrote:
>
>> Hello everyone , 
>> What are all the possible ways we could optimize a scene inside Maya 
>> . 
>> Can we do any part of it using python ? I'd appreciate any code for 
>> reference.
>>
>> -- 
>> You received this message because you are subscribed to the Google 
>> Groups "Python Programming for Autodesk Maya" group.
>> To unsubscribe from this group and stop receiving emails from it, 
>> send an email to python_inside_m...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/python_inside_maya/e98737c4-0aac-4eab-9040-b163eef82b71n%40googlegroups.com
>>  
>> 
>> .
>>
> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Python Programming for Autodesk Maya" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to python_inside_m...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/python_inside_maya/6f296197-d284-492e-bdb0-1854fa7e2c5an%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to python_inside_maya+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/b2adebb5-300d-41ce-a24e-fc4ab65d67cfn%40googlegroups.com.

[Maya-Python] Change viewport renderer with Python API

[Andrew Golubev]

Hello everyone!

Stuck with some problem, using maya 2017, and i need to change viewport 
rendere to viewport 2.0, how can i do this with Python API?
Cannot find such option in documentation,
what i founded i can check what RendererName 

 currently 
used as enum parameter of
M3dView  object of current viewport with getRendererName(), but there is no 
setRenderer , and i cannot change param directly without setter.

-- 
You received this message because you are subscribed to the Google Groups 
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to python_inside_maya+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/9d9c21c1-e0ec-4226-b80f-990b593cf7b2n%40googlegroups.com.

Re: [Maya-Python] Optimising scene

[Andrew Golubev]

Hi!
What actually you would like to optimize? Viewport interactivity? Render 
time? Animation interactivity? 
What do you have in the scene - is it environment, is it includes heavy 
rigs, and so on. 
Please provide more information about the problem for us to try to help you.

вторник, 17 августа 2021 г. в 16:58:36 UTC+3, Marcus Ottosson: 

> Great question, but vague question.
>
> Optimise for what? Performance? Disk space? Memory? Marketability? Ease of 
> use? Monetary value? Maximum Facebook friends? Some of those you can 
> achieve with Python.
>
> On Tue, 17 Aug 2021 at 14:42, Nirmal Kumar  wrote:
>
>> Hello everyone , 
>> What are all the possible ways we could optimize a scene inside Maya . 
>> Can we do any part of it using python ? I'd appreciate any code for 
>> reference.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Python Programming for Autodesk Maya" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to python_inside_m...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/python_inside_maya/e98737c4-0aac-4eab-9040-b163eef82b71n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to python_inside_maya+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/9d771305-ce9e-4d2d-b30a-0f6b396b866fn%40googlegroups.com.