Re: [Maya2osg-users] Discussion of next changes

[Javier T. <jav...@gm...>]

  Hi J-S,

On Fri, May 20, 2011 at 1:31 PM, Jean-Sébastien Guay
<jea...@cm...> wrote:
>
>>    I don't know if we are understanding each other. My point is that
>> you cannot add support for every attribute and attribute combination
>> possible, and each user will have its own needs structured in its own
>> way, maybe incompatible among them and doesn't seem to be a good place
>> to implement that kind of thing the plug-in C++ code.
>
> I understand your point, but I don't see an unlimited amount of
> attributes. Essentially, there are a fixed number of things that will be
> useful to users once the scene is exported. I will have mine and others
> will have theirs which might not be the same set, sure, but once they
> are done they are done.

  I don't agree here. I think that with this reasoning there is an
unlimited amount of attributes.

> I see it as the role of the plugin to specify what it exports (at least
> a base set). If the user wants more than that, sure he can write a
> pre-export script to get out other things, but the basic set should be
> fairly complete. If you don't agree with this point then I guess I'll

  OK. Let's define this basic set then.

> just write a pre-export script, so I just need to add code to maya2osg
> that will export notes into OSG node descriptions and we'll be done.
>
>>    Are you sure? Please, post a real example of the information you
>> want to retrieve from the Maya scene and where do you read it and
>> where do you want to write it.
>
> For example, for a material (say a Blinn/Phong), the osg::Material
> already contains the diffuse color, specular color, shininess, etc. Plus
> there is a diffuse texture in the same StateSet as the Material.

  One question: is all this discussion limited to Material attributes
or are we talking about every kind of Maya node?

> But if the user attached a texture to the bump attribute, I would need
> the filename of the texture, the amount of bump it contributes, and the
> coordinate space it is used in (bump = object space, normal = tangent
> space generally).

  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.

> Likewise, if the user attached a texture to the specular attribute,
> that's a specular map, and we could export again the texture and the
> amount of contribution.
>
> Since the exported information contains these different types of maps, I
> don't see any harm in putting the diffuse texture there either, just for
> completeness.
>
> So I would add to the OSG node description this kind of string:
>
> <maya2osg_material>
> Material_name Diffuse <filename> <amount>
> Material_name Normal <filename> <amount> <coordinate space>
> Material_name Specular <filename> <amount>
> </maya2osg_material>
>
> or more concretely:
>
> <maya2osg_material>
> Ship_hull Diffuse textures/ship_hull_d.jpg 100
> Ship_hull Normal textures/ship_hull_n.jpg 100 tangent
> Ship_hull Specular textures/ship_hull_s.jpg 30
> </maya2osg_material>
>
> 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.

> In general, artists are not programmers, they have their own workflow
> and if they build their scene in Maya so that it looks like they want,
> then the exporter should export that correctly without needing other
> operations / scripts.
>
> For comparison, here's what was recently added to the 3DSMax exporter
> (OSGExp) to do the same thing:
>
> ---------------------------------------------------------------------
> I've just committed support for the material description strings. Each
> material will have its own description string added to the root node.
> Here is a sample description:
>
> # osgmaxexp material data
> Name    Basketball
> Map     Diffuse 0       1       images\bball_diffuse.jpg
> Map     Bump    1       0.3     images\bball_normal.jpg
> ---------------------------------------------------------------------
>
> (the separator they chose is tab)
>
> I think something similar would work. The only remaining point really is
> whether the plugin creates this string or a pre-export script does.
>
>>    The reason to put it in the notes is to have a transparent way of
>> specifying whatever you can send and to what OSG node exactly.
>
> As I said, exporting notes is fine and IMHO is orthogonal to exporting
> attributes in the scene. If the artist put notes in the notes field in
> Maya, they should be exported as OSG node descriptions. This does not
> affect the discussion above. Rather, if exporting notes is added to the
> plugin, and we decide that what I want above will be done by a
> pre-export script that adds text to the notes, then we are done and I
> can start using it immediately.

  OK. I let you take the decission. I think our opinions are clear
right now. If you want to define a basic set of "autoexported"
attributes, it is OK. I have only two requests: to have one config
parameter (export option) to enable/disable this feature and to
document the process and the exported attributes in a wiki page.


  Regards,

-- 
Javier Taibo