Re: [Maya2osg-users] Discussion of next changes

[Peter W. <pp...@cg...>]

Hi all,

now I am confused ... @J-S, I thought, that this is what you wanted ? :

1.) Collect Maya Shading Attributes as far as possible through the plug-in
2.) Add any ( un ) imaginable Attributes as Tags added as maya notes 
into osg::Node Descriptions

@Javier, in the end I don't care as well, any string attribute should be 
as good as the notes field.
Anyway, the phase of implementing and testing this feature will surely 
show the "right" way :-)

  Cheers, PP
> On Wed, May 25, 2011 at 8:34 PM, Jean-Sébastien Guay
> <jea...@cm...>  wrote:
>> Sorry for the length of time I took to answer, I've been busy training a
>    Don't worry about that. We all have jobs and family and... even a
> life outside OSG!  :)
>
>> new employee (we're now a team of 2 graphics programmers at my company,
>> after being the only one for over 3.5 years).
>    I know what you're talking about. It's quite time consuming.
> Especially in this case that you have doubled the team :)
>
>>>     What if the user instead of a texture connected to the bump2D has a
>>> more complex shading network (e.g. combining several textures and
>>> other utility nodes)? You just ignore these cases and define a set
>>> that is supported, I presume. But maybe other user needs it. This is
>>> where I see a complicated situation to reach all the needs that can
>>> raise, that are very user-specific. And this is why I see a virtually
>>> unlimited set of attributes to export.
>> I am really thinking only of what is useful right now in real-time
>> rendering. But yes, this is not totally obvious to users, just to me. I
>> don't think anyone will need to export a file that has a complex shader
>> network with procedural textures and I don't know what else, simply
>> because it is obvious to me that the final file will be used in an OSG
>> program, and therefore we can't do everything a user making a model for
>> offline rendering for film use would expect...
>>
>> Just a few basic things that are not supported by the fixed pipeline and
>> most general file formats, but that we want to use in our engine.
>
>>>> I would prefer this kind of string never be visible / editable by the
>>>> user, since it's already specified by the Maya material. Putting it in 2
>>>> places (and one which the user could just delete if they're not paying
>>>> attention) is asking for trouble.
>>>     We absolutely agree in this point. I'll never say the contrary.
>>> Artists should not be able to touch anything more than the minimum
>>> necessary. It wasn't at any time what I was defending. The logic we
>>> are talking about, be it on the C++ code or in MEL scripts, is
>>> responsibility of the programmers and should automate the process to
>>> the artist.
>> But your suggested solution was to have a script that would place
>> strings either in the Notes on a Maya node, or in a custom attribute.
>> Both of these are user-visible in Maya, are they not?
>    You can create the attributes editable or visible as you need. This
> avoid users to touch them, even see them (though seeing them should be
> useful for debugging, and artists still can't break anything)
>
>> My point in doing it in the C++ code was that it's a (mostly) one-way
>> layer between Maya and the .osg file you export. Thus, anything created
>> in the C++ code will never be visible to the Maya user. If you have a
>> way of doing the same thing from script, then I have no argument
>> anymore. I'll do it in script, because I agree with all your other
>> points (the set of things to export being different for everyone, the
>> ease of doing it in script instead of in C++, etc.)
>    I am wondering... is the way you export materials and treat them in
> your engine incompatible with Maya2OSG exported GLSL shaders?
>
>    This part of GLSL export is a work in progress, so it is being
> modified. I even don't know how to do some things. There are some
> tradeoffs between flexibility and efficiency I have in my TO-DO list.
>
>
>> I just don't want it to be in Notes or something like that, because then
>> the user can edit it / break it.
>    That seems reasonable. I didn't like to have it there also. I
> disagree there with Peter.
>
>> Sorry for being difficult on this...
>    Don't worry. difficulties is where the fun is  ;)
>
>
>