Re: [Maya-Python] mayapy playblast

[Fredrik Averpil]

> xvfb

Ah, that was clever!

Following this topic with interest.

-- 
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/CAD%3DwhWO1ze3AiSuuQt8K1kUymrWXE9ttfDXK4S1R6wLrtYa0Mw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Maya-Python] mayapy playblast

[Marcus Ottosson]

Sorry, that yum command should have been:

$ yum install xorg-x11-server-Xvfb

​

On 17 September 2016 at 17:12, Marcus Ottosson 
wrote:

> Got this somewhat further, with newfound knowledge of Xvfb.
>
> $ yum install xorg-x11-server-Xorg
> $ Xvfb :99 -screen 0 1024x768x16 2>/dev/null &
> $ mayapy -c "from maya import standalone, cmds; \
>standalone.initialize(); \
>cmds.playblast(format='image')"
>
> In a nutshell how it works is that as far as Maya is concerned, there is
> an X environment running, only it’s running entirely in-memory.
>
> The problem now is that it tries running a playblast with Viewport 2.0.
>
> # VP2 Error : Failed to initialize graphics device.
>
> Is there any way of playblasting without Viewport 2.0? Or any way of
> disabling it entirely? Alternatively, what kind of drivers can I install to
> emulate whatever it needs, e.g. mesa?
>
> I’m expecting Viewport 2.0 to have more advanced requirements than what
> Mesa is capable of, but could be wrong. It might not work with Legacy
> either.
>
> Thanks!
> ​
>



-- 
*Marcus Ottosson*
konstrukt...@gmail.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/CAFRtmODCaMic%3Du2kx2bKCjRXigSyx9rm_NND-JqdUiBHuER3bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Maya-Python] mayapy playblast

[Marcus Ottosson]

Got this somewhat further, with newfound knowledge of Xvfb.

$ yum install xorg-x11-server-Xorg
$ Xvfb :99 -screen 0 1024x768x16 2>/dev/null &
$ mayapy -c "from maya import standalone, cmds; \
   standalone.initialize(); \
   cmds.playblast(format='image')"

In a nutshell how it works is that as far as Maya is concerned, there is an
X environment running, only it’s running entirely in-memory.

The problem now is that it tries running a playblast with Viewport 2.0.

# VP2 Error : Failed to initialize graphics device.

Is there any way of playblasting without Viewport 2.0? Or any way of
disabling it entirely? Alternatively, what kind of drivers can I install to
emulate whatever it needs, e.g. mesa?

I’m expecting Viewport 2.0 to have more advanced requirements than what
Mesa is capable of, but could be wrong. It might not work with Legacy
either.

Thanks!
​

-- 
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/CAFRtmODa2QzbXkKJuHqHU%3DeEW59EZ1dTbzgCFXxaGnsA1WYm7w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Maya-Python] Optimise this: Hierarchy from String

[Justin Israel]

On Sat, 17 Sep 2016, 6:12 PM Alok Gandhi  wrote:

> Also I would like to throw my 2 cents in as someone that develops not as
>> one that writes scripts and tools on a per-show basis to get shots finaled,
>> but as one that works on longer term projects to serve the ongoing
>> pipeline. The advise from that conference might be more applicable to
>> situations like that, where a shot-delivery time frame is not the case. It
>> really just depends on whether your deliverable is a shot, or software.
>
>
> I agree, I am also employed as a Pipeline Engineer and do not have the
> pressing need to script  for a single shot but rather develop Pipeline
> Tools and APIs that are consumed by various departments. I can totally
> understand where you are coming from and it makes complete sense. I started
> out as an artist (animator, rigger, and generalist) and then a TD and
> gradually segway into Pipeline. During this journey, I clearly saw my
> development focus shift from 'just make it work' to 'make it beautiful and
> readable'.
>

100% agree!


> On Sat, Sep 17, 2016 at 1:47 PM, Justin Israel 
> wrote:
>
>>
>>
>> On Sat, Sep 17, 2016 at 5:34 PM Alok Gandhi 
>> wrote:
>>
>>> @Justin: I agree with readability trumping performance, and almost at
>>> all times, I follow almost the same tenets. However, in our trade,
>>> performance is ever more critical and is becoming important every single
>>> day. The entertainment industry is one of the major stakeholders when
>>> it comes to demand for processing power. We need that water to look real,
>>> 10 million polygon processing, we need that. And on top of that, we work on
>>> deadlines, sometimes unreal. When there is a pressing need to process huge
>>> amounts of data so that the shot can be approved, we have to do that. And
>>> it is at such moments, readability might take a back seat. This by no means
>>> is a justification for ignoring readability but rather the state of
>>> affairs. There is sometimes a tradeoff involved, sometimes not. You can get
>>> the best of both the worlds if you have enough time on your hand.
>>>
>>
>> I appreciate this need. Ultimately we have to deliver shots and meet
>> deadlines. Ultimately we are in the business of making
>> Movies/Television/Games/, and not necessarily software.
>>
>> But really, it doesn't change the point of the advise from that
>> conference speaker. Even if performance ends up becoming the primary focus,
>> then naturally the other points become secondary. And you have to weigh
>> those decisions, right? Do we need this solution beyond this shot? This
>> show? Who gets to maintain it? How easy it is to continue to be adapted to
>> the next challenge.
>>
>> Also I would like to throw my 2 cents in as someone that develops not as
>> one that writes scripts and tools on a per-show basis to get shots finaled,
>> but as one that works on longer term projects to serve the ongoing
>> pipeline. The advise from that conference might be more applicable to
>> situations like that, where a shot-delivery time frame is not the case. It
>> really just depends on whether your deliverable is a shot, or software.
>>
>>
>>>
>>> It is good that we have a growing and healthy open source community,
>>> with studios investing in making amazing open source projects
>>> - OpenVDB exr, Alembic, USD etc. to name a few. With neatly written API to
>>> handle low-level high-processing procedures, all abstracted for the benefit
>>> of writing clean yet power packed code.
>>>
>>> That's my two cents.
>>>
>>> On Sat, Sep 17, 2016 at 9:15 AM, Justin Israel 
>>> wrote:
>>>


 On Sat, 17 Sep 2016, 1:09 PM yury nedelin  wrote:

> Is performance something you are concerned with for this process?
> Yury
>
 Marcus had said it was not a concern. I was just sharing some
 interesting info on the topic of readability and maintainability

> On Sep 16, 2016 6:16 PM, "Justin Israel" 
> wrote:
>
>>
>>
>> On Sat, Sep 17, 2016 at 5:27 AM Alok Gandhi <
>> alok.gandhi2...@gmail.com> wrote:
>>
>>>
>>> Coming back to some of the points that Ian raised:
>>> > Readability is a perfectly valid goal to seek but I
>>> find maintainability is often overlooked.
>>>
>>> IMHO more readable code is more maintainable. Readability goes hand
>>> in hand with maintainability. In fact, I very much agree that code lasts
>>> longer than an author and if you write readable code it will be easier 
>>> to
>>> read and understand for the people after you are gone and are not 
>>> available
>>> to explain why you did what. If by maintainability you meant actually
>>> extensibility, then it is a completely different aspect.
>>>
>>
>> As an aside, I just recently went to a convention, and in one of the
>> 

Re: [Maya-Python] Optimise this: Hierarchy from String

[Alok Gandhi]

>
> Also I would like to throw my 2 cents in as someone that develops not as
> one that writes scripts and tools on a per-show basis to get shots finaled,
> but as one that works on longer term projects to serve the ongoing
> pipeline. The advise from that conference might be more applicable to
> situations like that, where a shot-delivery time frame is not the case. It
> really just depends on whether your deliverable is a shot, or software.


I agree, I am also employed as a Pipeline Engineer and do not have the
pressing need to script  for a single shot but rather develop Pipeline
Tools and APIs that are consumed by various departments. I can totally
understand where you are coming from and it makes complete sense. I started
out as an artist (animator, rigger, and generalist) and then a TD and
gradually segway into Pipeline. During this journey, I clearly saw my
development focus shift from 'just make it work' to 'make it beautiful and
readable'.

On Sat, Sep 17, 2016 at 1:47 PM, Justin Israel 
wrote:

>
>
> On Sat, Sep 17, 2016 at 5:34 PM Alok Gandhi 
> wrote:
>
>> @Justin: I agree with readability trumping performance, and almost at all
>> times, I follow almost the same tenets. However, in our trade, performance
>> is ever more critical and is becoming important every single day. The
>> entertainment industry is one of the major stakeholders when it comes to
>> demand for processing power. We need that water to look real, 10 million
>> polygon processing, we need that. And on top of that, we work on deadlines,
>> sometimes unreal. When there is a pressing need to process huge amounts of
>> data so that the shot can be approved, we have to do that. And it is at
>> such moments, readability might take a back seat. This by no means is a
>> justification for ignoring readability but rather the state of affairs.
>> There is sometimes a tradeoff involved, sometimes not. You can get the best
>> of both the worlds if you have enough time on your hand.
>>
>
> I appreciate this need. Ultimately we have to deliver shots and meet
> deadlines. Ultimately we are in the business of making
> Movies/Television/Games/, and not necessarily software.
>
> But really, it doesn't change the point of the advise from that conference
> speaker. Even if performance ends up becoming the primary focus, then
> naturally the other points become secondary. And you have to weigh those
> decisions, right? Do we need this solution beyond this shot? This show? Who
> gets to maintain it? How easy it is to continue to be adapted to the next
> challenge.
>
> Also I would like to throw my 2 cents in as someone that develops not as
> one that writes scripts and tools on a per-show basis to get shots finaled,
> but as one that works on longer term projects to serve the ongoing
> pipeline. The advise from that conference might be more applicable to
> situations like that, where a shot-delivery time frame is not the case. It
> really just depends on whether your deliverable is a shot, or software.
>
>
>>
>> It is good that we have a growing and healthy open source community, with
>> studios investing in making amazing open source projects - OpenVDB exr,
>> Alembic, USD etc. to name a few. With neatly written API to handle
>> low-level high-processing procedures, all abstracted for the benefit of
>> writing clean yet power packed code.
>>
>> That's my two cents.
>>
>> On Sat, Sep 17, 2016 at 9:15 AM, Justin Israel 
>> wrote:
>>
>>>
>>>
>>> On Sat, 17 Sep 2016, 1:09 PM yury nedelin  wrote:
>>>
 Is performance something you are concerned with for this process?
 Yury

>>> Marcus had said it was not a concern. I was just sharing some
>>> interesting info on the topic of readability and maintainability
>>>
 On Sep 16, 2016 6:16 PM, "Justin Israel" 
 wrote:

>
>
> On Sat, Sep 17, 2016 at 5:27 AM Alok Gandhi 
> wrote:
>
>>
>> Coming back to some of the points that Ian raised:
>> > Readability is a perfectly valid goal to seek but I
>> find maintainability is often overlooked.
>>
>> IMHO more readable code is more maintainable. Readability goes hand
>> in hand with maintainability. In fact, I very much agree that code lasts
>> longer than an author and if you write readable code it will be easier to
>> read and understand for the people after you are gone and are not 
>> available
>> to explain why you did what. If by maintainability you meant actually
>> extensibility, then it is a completely different aspect.
>>
>
> As an aside, I just recently went to a convention, and in one of the
> talks the speaker opened with his list of priorities for designing
> software:
>
> 1. Integrity - The software should operate in a predictable manner,
> respond appropriately to exceptional