Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Farshid, I just added the support for normal map details in the description string. The format is the following: Normal unit amount method flip_red flip_green swap_red_green The method field can be one of the following strings: Tangent Local XYZ Screen World Try it out and let me know if there are any issues. I tried this, and I notice it's an extra line in the material description string. I'm wondering why you didn't just put the extra attributes at the end of the Map ... line for the same map (after the filename)? Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Jean-Sébastien, On Thu, May 26, 2011 at 6:31 AM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: I tried this, and I notice it's an extra line in the material description string. I'm wondering why you didn't just put the extra attributes at the end of the Map ... line for the same map (after the filename)? The reason I separated the attributes is because in Max there is a difference between a map channel (diffuse, specular, bump, etc...) and a bitmap type (bitmap, normal, mix, reflection, etc..). Technically, you can have a normal bitmap on the diffuse channel, or any other channel. I might add keywords for the other supported bitmap types in the future. Also, placing the bitmap attributes on a separate line should make parsing the description more future-proof. If a new Map attribute is added in the future, that would move the bitmap attributes over one column, which could break compatibility with older parsers. Having the bitmap attributes on a separate line should avoid this issue. Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Luca, On Thu, May 19, 2011 at 11:59 PM, Luca Vezzadini luca.vezzad...@gmail.comwrote: That would be perfect, so go ahead with that. I just added the support for normal map details in the description string. The format is the following: Normal unit amount method flip_red flip_green swap_red_green The method field can be one of the following strings: Tangent Local XYZ Screen World Try it out and let me know if there are any issues. Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Farshid Lashkari wrote: Normal unit amount method Normal 2 1.0 Tangent [...] Does this sound reasonable to you? That would be perfect, so go ahead with that. Thanks, Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39590#39590 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Farshid,
I gave it a try, the description lines are there. I just see a minor issue: you
did not add the MaterialData.{h,cpp} to Cmake.
About the results, looks like what is there is fine! I'll do more testing in
the next days, trying to use the definitions in my shaders as well, and let you
know.
One more thing. it looks like you now have code to handle the normal maps also.
But I think there is still no way to know if you were using a bump or a normal
map for the Bump channel. While in Max there is a clear distinction (different
texture types there), the exporter does not distinguish them. Look at this
example:
# osgmaxexp material data
NameTestMat
Map Diffuse 0 1 images\\casaterr_02.tga
Map Specular Level 1 1 images\\testRefMap.tga
Map Bump2 0.5 images\\casaterr_01norm.tga
# osgmaxexp material data
NameTestMat2
Map Bump0 0.3 images\\casaterr_01norm.tga
The testMat2 is using the tx directly as a bitmap, while TestMap first has a
NormalMap texture, then the bitmap. In the output they look totally equivalent
though. Looking at the code, it seems that you treat them as separate cases:
so, what about adding an extra field at the end of TestMap to indicate it's a
normal map? The field could actually be even smarter and indicate the active
texture space (tangent, screen, ...).
Great work anyway, really thanks for this.
Luca
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39530#39530
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi guys, Cool that this is done, I'll check it out soon and try reading the files back in our engine. Thanks a lot for your work! J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Luca,
On Thu, May 19, 2011 at 12:59 AM, Luca Vezzadini
luca.vezzad...@gmail.comwrote:
I gave it a try, the description lines are there. I just see a minor issue:
you did not add the MaterialData.{h,cpp} to Cmake.
About the results, looks like what is there is fine! I'll do more testing
in the next days, trying to use the definitions in my shaders as well, and
let you know.
Laurens just submitted a patch that fixes the Cmake issue.
The testMat2 is using the tx directly as a bitmap, while TestMap first has
a NormalMap texture, then the bitmap. In the output they look totally
equivalent though. Looking at the code, it seems that you treat them as
separate cases: so, what about adding an extra field at the end of TestMap
to indicate it's a normal map? The field could actually be even smarter and
indicate the active texture space (tangent, screen, ...).
My intention was to add more keywords that would describe each map in more
detail, depending on the texture type. In your example, I could add the
following line to provide more information regarding the bump map on unit 2:
Normal unit amount method
Normal 2 1.0 Tangent
This let's you know that the bitmap type on unit 2 is a normal map with the
specified settings. I could eventually add keywords to provide additional
info for Mix maps and Reflection maps.
Does this sound reasonable to you?
Cheers,
Farshid
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Farshid, hi Jean-Sébastien, I'll let you choose the separator, even if I'd vote for tabs or vertical bars, not spaces. About where to place the descriptions and the syntax for them, let's keep in mind that each description is treated as a separate string, so I'd say each one must bring all the info it needs. Which now seems to include also the material ID. So each line should probably be something like (still using bars for now): Material_32|Diffuse|Unit_0|myFile.jpg|80 It's true we could have quite a bunch of these depending on how many materials are in your exported file. But if we can't have them on the single stateset, then to me it would much better to see them all in a single place rather them spread on various geodes. This could mean we will see a long section in the beginning of the file that contains ALL the material definitions for the whole file. The code on our side would just have to get the root node of the imported file, get all these description and process them in a single shot. And even for debugging purposes, being able to open the file and check all the materials at one is easier. Bottom line for me is: everything at the root node is better... Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39497#39497 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Luca, On Wed, May 18, 2011 at 3:24 AM, Luca Vezzadini luca.vezzad...@gmail.comwrote: About where to place the descriptions and the syntax for them, let's keep in mind that each description is treated as a separate string, so I'd say each one must bring all the info it needs. Which now seems to include also the material ID. So each line should probably be something like (still using bars for now): Material_32|Diffuse|Unit_0|myFile.jpg|80 It's true we could have quite a bunch of these depending on how many materials are in your exported file. But if we can't have them on the single stateset, then to me it would much better to see them all in a single place rather them spread on various geodes. This could mean we will see a long section in the beginning of the file that contains ALL the material definitions for the whole file. The code on our side would just have to get the root node of the imported file, get all these description and process them in a single shot. And even for debugging purposes, being able to open the file and check all the materials at one is easier. Bottom line for me is: everything at the root node is better... I agree. Since the information is going to be decoupled from the stateset anyway, might as well have it all in once place. Regarding the format, are you suggesting that there should be a single description string that contains information for all the materials? Or each material should still be a separate description, but include the material name on each map entry line? Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Farshid Lashkari wrote: Regarding the format, are you suggesting that there should be a single description string that contains information for all the materials? Or each material should still be a separate description, but include the material name on each map entry line? I'm suggesting that we have one line per each map; so if you have 5 materials each with 3 maps you'll see 15 description lines in total. And each line should include the material ID it refers to so it's straightforward to parse (each line carries all the info you need, regardless of other strings). Then, as each node (so, in our case, the root node) can have multiple description strings (it's a vector), we can choose if we pack all the lines as a single string, if we group them by materials or if we have one string per line. Maybe we can make a few tests and see what is easier to read; but they are functionally equivalent anyway. Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39505#39505 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Luca, On Wed, May 18, 2011 at 8:02 AM, Luca Vezzadini luca.vezzad...@gmail.comwrote: I'm suggesting that we have one line per each map; so if you have 5 materials each with 3 maps you'll see 15 description lines in total. And each line should include the material ID it refers to so it's straightforward to parse (each line carries all the info you need, regardless of other strings). Then, as each node (so, in our case, the root node) can have multiple description strings (it's a vector), we can choose if we pack all the lines as a single string, if we group them by materials or if we have one string per line. Maybe we can make a few tests and see what is easier to read; but they are functionally equivalent anyway. I'm going to start playing around with this today. I'm leaning towards each material having its own description string. I'll let you know when I get something working. Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Luca, 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 Try it out and let me know if you encounter any issues. Cheers, Farshid On Wed, May 18, 2011 at 8:15 AM, Farshid Lashkari fla...@gmail.com wrote: Hi Luca, On Wed, May 18, 2011 at 8:02 AM, Luca Vezzadini luca.vezzad...@gmail.comwrote: I'm suggesting that we have one line per each map; so if you have 5 materials each with 3 maps you'll see 15 description lines in total. And each line should include the material ID it refers to so it's straightforward to parse (each line carries all the info you need, regardless of other strings). Then, as each node (so, in our case, the root node) can have multiple description strings (it's a vector), we can choose if we pack all the lines as a single string, if we group them by materials or if we have one string per line. Maybe we can make a few tests and see what is easier to read; but they are functionally equivalent anyway. I'm going to start playing around with this today. I'm leaning towards each material having its own description string. I'll let you know when I get something working. Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Farshid Lashkari wrote: # osgmaxexp material data Name Basketball Map Diffuse 0 1 imagesbball_diffuse.jpg Map Bump1 0.3 imagesbball_normal.jpg Cool! I'll give it a try tomorrow (I'm in Europe, different time...). Just to be sure I've got it right, the fields after the keyword Map are, in order: map name, tx unit, blend amount (in [0,1] range), file name. Is that right? Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39514#39514 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
On Wed, May 18, 2011 at 1:06 PM, Luca Vezzadini luca.vezzad...@gmail.comwrote: Cool! I'll give it a try tomorrow (I'm in Europe, different time...). Just to be sure I've got it right, the fields after the keyword Map are, in order: map name, tx unit, blend amount (in [0,1] range), file name. Is that right? That's right. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Ciao, So, looks like we have a decision, cool! To summarize, if I've got it right, for every texture map in the material we will find a description string like the following (assuming we use the | as a separator): Diffuse|Unit_0|c:\program files\whatever\file.png|80 where: - the first field is the texture map name followed by a | sign; - the second field is the map file name, followed by a | sign - the third field is the blend amount (in the [0-100] range) Any additional parameter that might be needed by the specific channel would just be an additional field (and it would be up to the parser to know its meaning of course). Is that right? Note that I would avoid the = and just use the | to separate all fields; this makes it easier to tokenize the string (I'm lazy...). About bump, as far as I know Max allows you to create for that channel a map of type normal and therefore you should be able to distinguish between regular bump mapping and normal mapping. Actually Max allows even to specify what space to use for the normal map (tangent, local, screen...) so maybe we could even add that extra param in the description string. Anything we can do here to help on this, apart from testing? Can't wait to give it a try... Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39447#39447 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
vezza wrote: About bump, as far as I know Max allows you to create for that channel a map of type normal and therefore you should be able to distinguish between regular bump mapping and normal mapping. Actually Max allows even to specify what space to use for the normal map (tangent, local, screen...) so maybe we could even add that extra param in the description string. I've made a few tests with the current (trunk) version of the exporter and I'd say it doesn't handle the normal maps for now. In Max, to use a normal map you don't assign directly a bitmap to the bump channel, you first create the map of type normal, then assign the bit map to it. So there is an extra texture node to go through. I guess the exporter could be extended to check if the bump texture is not a bitmap in which case it could try to interpret is as a normal map. No idea how to do it though as I don't know the max SDK ... :( Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39455#39455 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Guys Been following this with interest. Having a method to know what map type is in what texture unit will be great. Regarding the normal mapping, is there any chance of getting the exporter to also generate tangent vectors (either from max or using osgUtils). Would be ace if you could also specify the channel to bind and the name to use in the shader e.g. channels 6 and 7 with names osg_tangent, osg_binormal Or do people feel tangents should always be generated at runtime? Cheers Tom ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Farshid Lashkari wrote: The description would be added to the osg::StateSet object. Our use of the word material is referring to the Max material object. Mmm... StateSet does not derive from osg::Node so it does not have the DescriptionList member... So are you planning to extend the StateSet class, its serializer and so on? Or did I miss something?... Thanks, Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39463#39463 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Luca, On Tue, May 17, 2011 at 4:29 AM, Luca Vezzadini luca.vezzad...@gmail.comwrote: I've made a few tests with the current (trunk) version of the exporter and I'd say it doesn't handle the normal maps for now. In Max, to use a normal map you don't assign directly a bitmap to the bump channel, you first create the map of type normal, then assign the bit map to it. So there is an extra texture node to go through. I guess the exporter could be extended to check if the bump texture is not a bitmap in which case it could try to interpret is as a normal map. No idea how to do it though as I don't know the max SDK ... :( It should export if you enable unknown maps in the export options. However, this seems to force the normal map to 256x256. I'll see about adding direct support for normal maps. Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Luca, On Tue, May 17, 2011 at 6:12 AM, Luca Vezzadini luca.vezzad...@gmail.comwrote: Mmm... StateSet does not derive from osg::Node so it does not have the DescriptionList member... So are you planning to extend the StateSet class, its serializer and so on? Or did I miss something?... You are absolutely right! I had mistakenly assumed that the description list was supported by all osg::Object derived classes. Well, that puts a big dent in our plans :( Does anybody know if the new meta-data system will support all osg::Object derived classes? One option would be to put the description string in the name of the stateset object. Another option would be to use the user data field, but that would require a custom serializer. Let me know if you have another idea. Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Farshid, Luca, You are absolutely right! I had mistakenly assumed that the description list was supported by all osg::Object derived classes. Well, that puts a big dent in our plans :( Argh, I had made the same assumption. Does anybody know if the new meta-data system will support all osg::Object derived classes? I think so, since it will essentially supersede the UserData. I think that's why we made the wrong assumption above. One option would be to put the description string in the name of the stateset object. Another option would be to use the user data field, but that would require a custom serializer. In the name, that would make a really long name! In the UserData might be a good idea if we can think of a way to make it readable for anyone. I guess it would also limit us to using the new formats (osgt, osgb, osgx) and not the old ones (osg, ive). Let me know if you have another idea. Nope, not for now... I'll keep thinking about it though. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi, I have no idea about the new metadata stuff. But if that doesn't work, wouldn't it be easier to just move the description stuff from Node to Object? The name is already in the Object class, having the description there too would make a lot of sense anyway. And I don't this this would be a major refactor, right? Of course we need Robert's buy-in for this. For sure I would avoid using the name to encode all that info, that would really be ugly. I'd rather go back to the idea of predefined mapping among map channels and texture units... Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39482#39482 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Luca, Jean-Sébastien On Tue, May 17, 2011 at 12:46 PM, Luca Vezzadini luca.vezzad...@gmail.comwrote: I have no idea about the new metadata stuff. But if that doesn't work, wouldn't it be easier to just move the description stuff from Node to Object? The name is already in the Object class, having the description there too would make a lot of sense anyway. And I don't this this would be a major refactor, right? Of course we need Robert's buy-in for this. If the new meta-data system is going to support all osg::Object derived classes, then all we need to do is just wait until it is complete. I think the bigger issue is being able to support older versions of osg and older formats like .osg/.ive. How about adding all the material descriptions to the root node of the model? Each material would have a separate entry in the description list of the node. This would require no changes to osg and would support the older model formats. We would just need to add the material name to the description string. Example: # osgmaxexp material info Material Name # Maps Diffuse 0 images/diffuse.jpg 100 Bump 1 images/bump.jpg 80 Does this seem like an acceptable solution? Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Farshid, If the new meta-data system is going to support all osg::Object derived classes, then all we need to do is just wait until it is complete. I think the bigger issue is being able to support older versions of osg and older formats like .osg/.ive. Yes. How about adding all the material descriptions to the root node of the model? Each material would have a separate entry in the description list of the node. This would require no changes to osg and would support the older model formats. I would prefer to add it to the description string of the node(s) on which a material is applied, since a model might have multiple materials on different nodes... i.e. your way would work if the model was made using a texture atlas so the same texture applies to the whole model, but if that isn't the case and multiple textures need to be applied to different parts of the model then we can't just put the material at the root node... We would just need to add the material name to the description string. Example: # osgmaxexp material info Material Name # Maps Diffuse 0 images/diffuse.jpg 100 Bump 1 images/bump.jpg 80 Does this seem like an acceptable solution? The format seems fine to me. Your separator is space, which seems more readable to me than the vertical bar we were discussing before, but it means parsers will have to handle the case where the filename is quoted and has spaces in it. Plus do any map names have spaces in them? In your list in a previous post, there was Specular Level that has a space... If you output it as Specular_Level for example, that's perfect I think. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Jean-Sébastien, On Tue, May 17, 2011 at 4:16 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: I would prefer to add it to the description string of the node(s) on which a material is applied, since a model might have multiple materials on different nodes... i.e. your way would work if the model was made using a texture atlas so the same texture applies to the whole model, but if that isn't the case and multiple textures need to be applied to different parts of the model then we can't just put the material at the root node... The exporter applies the material statesets to the osg::Drawable object, which does not support description strings. I can add the description to the parent osg::Geode. However, keep in mind that the geode can contain multiple drawables, where each drawable has a unique material applied. So you could still have multiple descriptions applied to the geode. So would you prefer adding the descriptions to the geode or root node? The format seems fine to me. Your separator is space, which seems more readable to me than the vertical bar we were discussing before, but it means parsers will have to handle the case where the filename is quoted and has spaces in it. Plus do any map names have spaces in them? In your list in a previous post, there was Specular Level that has a space... If you output it as Specular_Level for example, that's perfect I think. Actually, I've decided on using the tab character. This should avoid conflicts with filenames and seems more readable to me. Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Farshid, The exporter applies the material statesets to the osg::Drawable object, which does not support description strings. I can add the description to the parent osg::Geode. However, keep in mind that the geode can contain multiple drawables, where each drawable has a unique material applied. So you could still have multiple descriptions applied to the geode. So would you prefer adding the descriptions to the geode or root node? I think Geode is closer to the real intent than the root... Does the exporter give unique names to the Drawables? If so, then the description strings added to the Geode could say that Drawable named A has this material, Drawable named B has this material, and so on. This same scheme could be used at the root of the model, sure, but that would be much messier as lots of information would be at the same place. In the Geodes, at least it's just a small set of information (for the Geode's Drawables) that needs to be there. I agree it's not ideal... But until the metadata system on osg::Object lands (and for formats that won't support metadata), it's better than putting it on the root of the model IMHO. Actually, I've decided on using the tab character. This should avoid conflicts with filenames and seems more readable to me. Hmm, are you adamant on that? I personally don't like tabs, to the point that I configure all my editors to insert spaces instead of tabs when I press the Tab key... Plus, it can happen that the length of a token is 1 less than the tab length, and then your tab looks like a space visually, so you have to check it's really a tab... Tabs are unambiguous for the machine but seem ambiguous for humans to me. If you really want tab it's ok, as the strings will most of the time not be edited by hand, but space is just as readable and less ambiguous (visually) I think, apart for the filename issue. I tend to prefer things that are unambiguous to humans, even if it means more trouble to parse. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi, I'd like to share a few comments about the OSGExp for Max (I've recently sent them directly to Farshid, and also on the Delta3D forum, but it's probably better to share them here). I see a few limitations right now and the main ones are the following: - you can only export diffuse and light maps, no other texture that you might have in your material (e.g. bump/normal and specular); - the exporter does not have a predefined texture layer for every texture; i.e., if you just have a constant diffuse color and a light map, that texture will go to TextureUnit 0; if you have both a diffuse and a light map, the first will be on Unit 0 and the lightmap on Unit 1. For creating shaders this is quite annoying as you cannot make a safe assumption of where your textures are. And it gets of course more problematic if we add more maps like bump/normal, reflection, ... (As a side note, the Blender exporter is fine for this, every map is always assigned to the same unit, no matter what texture combination is used for the specific material.) Also, as OSG is changing quite a lot and as even the underlying geometry structures are evolving (VBOs for example), this may mean that the exporter could need an update even at that level. Is there any plan in that direction? Thanks, Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39398#39398 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Luca, On Mon, May 16, 2011 at 4:44 AM, Luca Vezzadini luca.vezzad...@gmail.comwrote: I'd like to share a few comments about the OSGExp for Max (I've recently sent them directly to Farshid, and also on the Delta3D forum, but it's probably better to share them here). I responded to your email from a few days ago, but the reply bounced. I see a few limitations right now and the main ones are the following: - you can only export diffuse and light maps, no other texture that you might have in your material (e.g. bump/normal and specular); I recently added support for exporting all standard material map types. Try building the plugin from the current svn trunk. - the exporter does not have a predefined texture layer for every texture; i.e., if you just have a constant diffuse color and a light map, that texture will go to TextureUnit 0; if you have both a diffuse and a light map, the first will be on Unit 0 and the lightmap on Unit 1. For creating shaders this is quite annoying as you cannot make a safe assumption of where your textures are. And it gets of course more problematic if we add more maps like bump/normal, reflection, ... (As a side note, the Blender exporter is fine for this, every map is always assigned to the same unit, no matter what texture combination is used for the specific material.) I have two ideas to help with this issue: 1) Add an option that will use fixed texture units for all the standard map types. (ie. unit 0 contains diffuse, unit 5 is self-illumination, etc..). Not sure how this would work with composite materials though. 2) Add a specially formatted description string to the stateset that tells what map type each unit contains. The benefit of this approach is that other map related settings can also be saved (e.g. blend amount). For example, the string could look like the following: # Maps 0=Diffuse 1=Specular 2=Self-Illumination # Blend Amount 0=100 1=60 2=100 Thoughts? Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Farshid, Thanks for the reply; about the new version that can export all maps, that is surely great news, I'll have a look as soon as possible and get back with feedback. Farshid Lashkari wrote: I have two ideas to help with this issue: 1) Add an option that will use fixed texture units for all the standard map types. (ie. unit 0 contains diffuse, unit 5 is self-illumination, etc..). Not sure how this would work with composite materials though. 2) Add a specially formatted description string to the stateset that tells what map type each unit contains. The benefit of this approach is that other map related settings can also be saved (e.g. blend amount). I'd say that both options are interesting; the first one is probably more straightforward, but it's true that the second one opens more possibilities. What about a radio button in the exporter options to choose which strategy to use? I know this means coding both version but it would leave more margin on the end-user side... Thanks, Luca PS About the reply that bounced, no idea why, I'll look into that. Thanks for letting me know. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39429#39429 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Luca, On Mon, May 16, 2011 at 1:57 PM, Luca Vezzadini luca.vezzad...@gmail.comwrote: I'd say that both options are interesting; the first one is probably more straightforward, but it's true that the second one opens more possibilities. What about a radio button in the exporter options to choose which strategy to use? I know this means coding both version but it would leave more margin on the end-user side... The second method doesn't necessarily need to be an option. I don't see any harm in always adding a description string to the stateset. My main concern is coming up with a format that can be easy to parse. I'd like to avoid the first method, since it introduces a couple issues. As I mentioned in my last email, how would composite materials be handled? Should the assigned texture unit for each map type be customizable, and if so, how would the interface for assigning the texture units work? If you are not concerned with composite materials and are fine with hard-coded texture units, then this seems like something I can add soon. Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Farshid Lashkari wrote: I'd like to avoid the first method, since it introduces a couple issues. As I mentioned in my last email, how would composite materials be handled? Should the assigned texture unit for each map type be customizable, and if so, how would the interface for assigning the texture units work? If you are not concerned with composite materials and are fine with hard-coded texture units, then this seems like something I can add soon. I'm not too clear about the composite material issue you mention: what is exactly the problem you see? And how is that case handled today? Anyway, what I would like from the standpoint of who uses the exported geometry is a well-defined way to interpret the material definitions. As I mentioned, if you export an object from Blender you have a clear mapping between texture units and map types. This is probably the easiest way for me to start coding my shaders. It requires writing additional maps compared to the diffuse+selfIllum ones you can write today; and with a well-defined way to know which maps you have in your material. Something else we should probably keep in mind is backward compatibility, in the sense that what was exported by the previous version should look similar to what we can write today, as many people have probably built code to parse materials and create shaders. Maybe we could start by assigning units 0 and 1 for diffuse and self-illum, as this is what you were getting before in most cases. And then use higher layers for the newly exported channels. Maybe for the new description strings we still need more brainstorming but let's start it :) Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39432#39432 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Farshid Lashkari wrote: Should the assigned texture unit for each map type be customizable, and if so, how would the interface for assigning the texture units work? About the texture unit - map type mapping, is that something that you really need on a per-material basis or is it more of a global definition for you whole file? I would say it's more a global thing. If so, we could have in the export dialog a choice between the predefined (hardcoded) mapping - like the one I was suggesting in the previous post - or a custom one (to be defined in some way still to be decided...). Then you may write it as a description string for every material (but if you do all materials will have the same string I guess). Of course the description string is still a great idea for everything that is specific to a given material instance (like the blend values you were mentioning). As this is fully Max-specific, the syntax to use could rely on Max definitions; for example, use the texture type IDs from the Max SDK to indicate the blend amount (ID_DI=0.7) and leave it up to the end-user code to do whatever it needs with that. Does this make sense? Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39434#39434 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Farshid, The second method doesn't necessarily need to be an option. I don't see any harm in always adding a description string to the stateset. My main concern is coming up with a format that can be easy to parse. I totally agree. I'd like to avoid the first method, since it introduces a couple issues. As I mentioned in my last email, how would composite materials be handled? Should the assigned texture unit for each map type be customizable, and if so, how would the interface for assigning the texture units work? If you are not concerned with composite materials and are fine with hard-coded texture units, then this seems like something I can add soon. In the case of our use of the exporter, we'd want to implement the second case anyways, as our engine uses specific shaders and a pipeline that the exporter doesn't (and shouldn't) know about. So we really need a way for the exporter to embed all the information needed to be able to do the effects specified by the artist, but without putting the actual shaders in the exported file. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Luca, On Mon, May 16, 2011 at 3:39 PM, Luca Vezzadini luca.vezzad...@gmail.comwrote: About the texture unit - map type mapping, is that something that you really need on a per-material basis or is it more of a global definition for you whole file? I would say it's more a global thing. If so, we could have in the export dialog a choice between the predefined (hardcoded) mapping - like the one I was suggesting in the previous post - or a custom one (to be defined in some way still to be decided...). Then you may write it as a description string for every material (but if you do all materials will have the same string I guess). Of course the description string is still a great idea for everything that is specific to a given material instance (like the blend values you were mentioning). As this is fully Max-specific, the syntax to use could rely on Max definitions; for example, use the texture type IDs from the Max SDK to indicate the blend amount (ID_DI=0.7) and leave it up to the end-user code to do whatever it needs with that. I don't really see the need for per-material texture unit mappings, having the mapping be global seem reasonable enough. My main concern was whether this mapping would be hard-coded or if it should be customizable. Making it customizable requires a lot more interface related coding, which is not very fun ;) Either way, I'd like to first add the description string support for the material map data. If we can come up with reasonable format, I could probably add this within the next few days. What do you feel about the following example? # osgmaxexp texture maps MapUnits=0,1,5 MapTypes=Diffuse,Self-Illumination,Bump MapBlendAmounts=100,80,100 Another option would be having each map definition on its own line: # osgmaxexp texture maps Type_0=Diffuse Type_1=Self-Illumination Type_5=Bump BlendAmount_0=100 BlendAmount_1=80 BlendAmount_5=100 I was thinking of an xml-based description format, but that might be overkill and require more coding work to parse. Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Jean-Sébastien, On Mon, May 16, 2011 at 3:58 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: In the case of our use of the exporter, we'd want to implement the second case anyways, as our engine uses specific shaders and a pipeline that the exporter doesn't (and shouldn't) know about. So we really need a way for the exporter to embed all the information needed to be able to do the effects specified by the artist, but without putting the actual shaders in the exported file. Same here, our application already determines texture units at runtime, so I personally have no need for hard-coded units. Do you have any suggestions for how the material description strings should be formatted? Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
We could probably start off with the hardcoded version first, then later on add the customizable version. Baby steps... :) About the description syntax, I think the main decision is: is this a Max-specific feature or do we want it to be generic? Generic would be better of course but then we have things like the blend amount which is max-only... And to be generic we need the buy-in from the whole OSG community (ideally other exporters should use it too); and this may take some time. My vote then is for a Max-specific thing, using the SDK definitions and putting everything on a single line. A syntax using something like texture_ID=texture unit, blend value; for example: - ID_DI=Unit_0, 80 Simple and clear, a single line for each map... And if later we need to add other info about each map, just append them there. My 2 cents. Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39438#39438 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Farshid, Same here, our application already determines texture units at runtime, so I personally have no need for hard-coded units. Do you have any suggestions for how the material description strings should be formatted? Both your and Luca's suggestions are good, but I think I like Luca's better, as it doesn't assume any ID number (yours has Type_0, Type_1, ... which seems to suggest a certain texture unit, but at the same time you don't want hard-coded texture unit numbers, so you seem to contradict yourself). A few extra bytes to Luca's suggestion would add more clarity, for example: Diffuse=filename, 100 Self_Illumination=filename, 80 Bump=filename, 100 I would suggest as you can see that we add the filename there, even if the exported file might already have the relevant images loaded in the graph. I can imagine a case where we might want the exported file to be viewable on the fixed pipeline only (without normal maps etc.) and in that case, we might strip all textures except the diffuse one, so having the filename there, while not hurting anyone, preserves some hint that a normal map was associated with that material. BTW, a bump map is not a normal map (object-space vs tangent-space etc.) so I think there should be a distinction there too. BTW, where would you put those description strings? osg::Material? Or osg::StateSet? Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Jean-Sébastien, On Mon, May 16, 2011 at 4:56 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Both your and Luca's suggestions are good, but I think I like Luca's better, as it doesn't assume any ID number (yours has Type_0, Type_1, ... which seems to suggest a certain texture unit, but at the same time you don't want hard-coded texture unit numbers, so you seem to contradict yourself). I personally don't need them, but if a hard-coded texture unit option were to be added to the exporter in the future, then we might as well add this information to the description string now. If we are 100% sure that this option will never be added, then I'm fine with leaving this information out since it can be inferred from the definition order. A few extra bytes to Luca's suggestion would add more clarity, for example: Diffuse=filename, 100 Self_Illumination=filename, 80 Bump=filename, 100 I would suggest as you can see that we add the filename there, even if the exported file might already have the relevant images loaded in the graph. I can imagine a case where we might want the exported file to be viewable on the fixed pipeline only (without normal maps etc.) and in that case, we might strip all textures except the diffuse one, so having the filename there, while not hurting anyone, preserves some hint that a normal map was associated with that material. This seems useful to me too. But we need to be careful, since commas are allowed in filenames. We might need to choose a different separator character in this case then. How about the vertical line character | ? BTW, a bump map is not a normal map (object-space vs tangent-space etc.) so I think there should be a distinction there too. I'm just going with the Max naming conventions. Here is the list of all standard material map names: Ambient Diffuse Specular Specular Level Glossiness Self-Illumination Opacity Filter Bump Reflection Refraction Displacement BTW, where would you put those description strings? osg::Material? Or osg::StateSet? The description would be added to the osg::StateSet object. Our use of the word material is referring to the Max material object. Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Farshid, I personally don't need them, but if a hard-coded texture unit option were to be added to the exporter in the future, then we might as well add this information to the description string now. If we are 100% sure that this option will never be added, then I'm fine with leaving this information out since it can be inferred from the definition order. Sounds good to me. This seems useful to me too. But we need to be careful, since commas are allowed in filenames. We might need to choose a different separator character in this case then. How about the vertical line character | ? Sure, that's good. Semicolon might be good too, since it's a command separator so can't be used for filenames (without being escaped) in most shells. Space might be ok too, but would require filenames to be quoted if they have spaces, so it becomes a bit more ambiguous... I'm just going with the Max naming conventions. Here is the list of all standard material map names: Ambient Diffuse Specular Specular Level Glossiness Self-Illumination Opacity Filter Bump Reflection Refraction Displacement I suggest using those full names in the description string. But for Bump, does Max have a setting to interpret a bump map as object-space, tangent-space, etc.? If so, then the value of that setting might be useful to add to the Bump description string. The description would be added to the osg::StateSet object. Our use of the word material is referring to the Max material object. OK, great. Thanks a bunch, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Farshid, 1) Adding prefix/suffix to image filename. I believe this is the easiest method. The filename will be applied to the exported osg::Image object. For example, you can append _[normal] to all normal map images. I think this is a bit too intrusive. The artist should be able to name their images however they want... 2) Adding tags to the material name. Using the Material Editor in Max, you can set the name of a material to any arbitrary string. The name will be applied to the corresponding osg::StateSet and osg::Drawable object. I'm thinking of changing this so it is only applied to the osg::StateSet object. Using the previous example, you can append _[normal] to the material name to flag that it contains a normal map. That's a better idea I think. And then on load, when we have interpreted the file and determined we need to load the normal map, we can remove the suffix so that the real name is there again. 3) Modifying the object properties. I wouldn't recommend this technique for material related settings. We use it for node related settings. Right-click an object in the scene and select Object Properties. Select the User Defined tab and enter any mult-line string within the textbox. This gets exported as a description string of the corresponding osg::Node object. Do even materials have user defined object properties? If so, then I think this is the best option for all settings, as it can be arbitrary settings and arbitrary length. For example, the exporter might want to set a tag saying that the material needs a normal map, but also include the filename of the normal map texture and the amount of bump. Other types of effects might have other settings too. Including all that in the material name will get hard to parse, whereas with user defined properties, we could have one setting per line and it's easy to parse. I'll have a look at what I can do to do that. Thanks for the examples. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Javier, I have to get deeper in this issue, but unfortunately I won't have much time for it. I'll let you know if I get to something. I've found out what the problem is: When the Phong class tries to generate a shader code block ( Phong::getCodeBlock() ), if the material was actually a Blinn, then it has no cosinePower plug, so it gives a runtime error there. For some reason when the plugin is compiled with optimization enabled, when printing that runtime error it crashes. I'll fix it correctly and send you the changes. I initially didn't want to duplicate the Phong class to make a Blinn class for so little difference between the two, but in retrospect it will be cleaner. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Javier,
In the end, the fact that the shader generation code in phong.cpp was
trying to access a plug that didn't exist for a blinn material wasn't
the cause of the crash (the code is well guarded so it just returns an
empty plug). Plus, that plug is never used anyways (the
gl_FrontMaterial.shininess is used, and that was set according to my
approximation in shader.cpp, so that should be fine). Still, I made the
Blinn class anyways so it's a starting point if we ever want to refine it.
What I did to remove the crash (at least until we can find the real
cause) is to disable optimization for the function where it crashes.
I also saw that one of the plugs was missing in phong.cpp, and even if
it's empty, for completeness I added it.
So find the modified files attached. They all go in src/GLSL, except the
CMakeLists.txt which goes into the root.
Thanks in advance,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
#Maya2OSG - A toolkit for exporting Maya scenes to OpenSceneGraph
#Copyright (C) 2010 Javier Taibo javier.ta...@gmail.com
#
#This file is part of Maya2OSG.
#
#Maya2OSG is free software: you can redistribute it and/or modify
#it under the terms of the GNU General Public License as published by
#the Free Software Foundation, either version 3 of the License, or
#(at your option) any later version.
#
#Maya2OSG is distributed in the hope that it will be useful,
#but WITHOUT ANY WARRANTY; without even the implied warranty of
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
#GNU General Public License for more details.
#
#You should have received a copy of the GNU General Public License
#along with Maya2OSG. If not, see http://www.gnu.org/licenses/.
#
# Thanks to Diego/ScEngMan for some hints on the creation of this CMake script
#
#
http://area.autodesk.com/forum/autodesk-maya/sdk/build-maya-plug-ins-using-cmake-40a-howto41
# http://crackart.org/wiki/HowTo/CMakeForMaya
CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
PROJECT(Maya2OSG)
list( APPEND CMAKE_MODULE_PATH ${Maya2OSG_SOURCE_DIR}/CMakeModules )
SET(VERSION_MAJOR 0)
SET(VERSION_MINOR 4)
SET(VERSION_RELEASE 2)
SET(VERSION_PATCH c)
# Platform specific definitions
IF(WIN32)
IF(MSVC)
# To enable /MP, parralel build on MSVC
OPTION(WIN32_USE_MP Set to OFF to diable /MP. ON)
MARK_AS_ADVANCED(WIN32_USE_MP)
IF(WIN32_USE_MP)
SET(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} /MP)
ENDIF(WIN32_USE_MP)
# Other MSVC compilation flags
ADD_DEFINITIONS(-D_SCL_SECURE_NO_WARNINGS)
ADD_DEFINITIONS(-D_CRT_SECURE_NO_DEPRECATE)
ENDIF(MSVC)
ENDIF (WIN32)
# Set the Maya version and architecture (default values)
SET(MAYA_VERSION 2011 CACHE STRING Maya Version)
SET(MAYA_ARCH x64 CACHE STRING HW Architecture)
IF(WIN32)
SET( MAYA_USER_DIR $ENV{USERPROFILE}/Documents/maya CACHE PATH Maya
user home directory )
SET( MAYA_ROOT $ENV{PROGRAMFILES}/Autodesk/Maya${MAYA_VERSION} CACHE
PATH Maya installation directory )
SET( MAYA_SDK_DEFINITIONS _AFXDLL;_MBCS;NT_PLUGIN;REQUIRE_IOSTREAM )
ELSE()
SET( MAYA_USER_DIR $ENV{HOME}/maya CACHE PATH Maya user home
directory )
SET( MAYA_ROOT /usr/autodesk/maya${MAYA_VERSION}-${MAYA_ARCH} )
ENDIF()
SET( MAYA_HEADERS_DIR ${MAYA_ROOT}/include )
SET( MAYA_LIBRARY_DIR ${MAYA_ROOT}/lib )
IF (EXISTS $ENV{MAYA_PLUG_IN_PATH})
SET ( MAYA_PLUGINS_DIR $ENV{MAYA_PLUG_IN_PATH} CACHE PATH Maya plug-in
installation directory )
ELSE ()
SET( MAYA_PLUGINS_DIR ${MAYA_ROOT}/bin/plug-ins CACHE PATH Maya
plug-in installation directory )
ENDIF ()
FIND_PACKAGE(OpenGL)
include( FindOSGHelper )
# Set all postfixes to nothing so we can compile other versions and they will
# be loaded instead of the release version by Maya.
SET(CMAKE_DEBUG_POSTFIX )
SET(CMAKE_RELWITHDEBINFO_POSTFIX )
SET(CMAKE_MINSIZEREL_POSTFIX )
SET ( LOCAL_WARNING_FLAGS /W3 )
SET ( LOCAL_RTTI_FLAGS /GR )
SET(CMAKE_INSTALL_PREFIX ${MAYA_PLUGINS_DIR})
SET(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
SET ( TARGET maya2osg )
SET ( SOURCE_FILES
src/animation.cpp
src/animation.h
src/camera.cpp
src/camera.h
src/cameraanimation.cpp
src/cameraanimation.h
src/common.cpp
src/common.h
src/config.cpp
src/config.h
src/dagnode.cpp
src/dagnode.h
src/directionallight.cpp
src/directionallight.h
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi J-S, On Mon, May 9, 2011 at 5:15 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: In the end, the fact that the shader generation code in phong.cpp was trying to access a plug that didn't exist for a blinn material wasn't the cause of the crash (the code is well guarded so it just returns an empty plug). Plus, that plug is never used anyways (the gl_FrontMaterial.shininess is used, and that was set according to my approximation in shader.cpp, so that should be fine). Still, I made the Blinn class anyways so it's a starting point if we ever want to refine it. What I did to remove the crash (at least until we can find the real cause) is to disable optimization for the function where it crashes. I also saw that one of the plugs was missing in phong.cpp, and even if it's empty, for completeness I added it. Great! Thanks for the corrections. Submitted to svn/trunk. So find the modified files attached. They all go in src/GLSL, except the CMakeLists.txt which goes into the root. Do you know of an easy way for CMake to create the folders (e.g., GLSL) inside the Visual Studio project source tree? Cheers! -- Javier Taibo ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Javier,
Great! Thanks for the corrections. Submitted to svn/trunk.
Thanks!
Do you know of an easy way for CMake to create the folders (e.g.,
GLSL) inside the Visual Studio project source tree?
See the attached file. :-)
Hope this helps,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
#Maya2OSG - A toolkit for exporting Maya scenes to OpenSceneGraph
#Copyright (C) 2010 Javier Taibo javier.ta...@gmail.com
#
#This file is part of Maya2OSG.
#
#Maya2OSG is free software: you can redistribute it and/or modify
#it under the terms of the GNU General Public License as published by
#the Free Software Foundation, either version 3 of the License, or
#(at your option) any later version.
#
#Maya2OSG is distributed in the hope that it will be useful,
#but WITHOUT ANY WARRANTY; without even the implied warranty of
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
#GNU General Public License for more details.
#
#You should have received a copy of the GNU General Public License
#along with Maya2OSG. If not, see http://www.gnu.org/licenses/.
#
# Thanks to Diego/ScEngMan for some hints on the creation of this CMake script
#
#
http://area.autodesk.com/forum/autodesk-maya/sdk/build-maya-plug-ins-using-cmake-40a-howto41
# http://crackart.org/wiki/HowTo/CMakeForMaya
CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
PROJECT(Maya2OSG)
list( APPEND CMAKE_MODULE_PATH ${Maya2OSG_SOURCE_DIR}/CMakeModules )
SET(VERSION_MAJOR 0)
SET(VERSION_MINOR 4)
SET(VERSION_RELEASE 2)
SET(VERSION_PATCH c)
# Platform specific definitions
IF(WIN32)
IF(MSVC)
# To enable /MP, parralel build on MSVC
OPTION(WIN32_USE_MP Set to OFF to diable /MP. ON)
MARK_AS_ADVANCED(WIN32_USE_MP)
IF(WIN32_USE_MP)
SET(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} /MP)
ENDIF(WIN32_USE_MP)
# Other MSVC compilation flags
ADD_DEFINITIONS(-D_SCL_SECURE_NO_WARNINGS)
ADD_DEFINITIONS(-D_CRT_SECURE_NO_DEPRECATE)
ENDIF(MSVC)
ENDIF (WIN32)
# Set the Maya version and architecture (default values)
SET(MAYA_VERSION 2011 CACHE STRING Maya Version)
SET(MAYA_ARCH x64 CACHE STRING HW Architecture)
IF(WIN32)
SET( MAYA_USER_DIR $ENV{USERPROFILE}/Documents/maya CACHE PATH Maya
user home directory )
SET( MAYA_ROOT $ENV{PROGRAMFILES}/Autodesk/Maya${MAYA_VERSION} CACHE
PATH Maya installation directory )
SET( MAYA_SDK_DEFINITIONS _AFXDLL;_MBCS;NT_PLUGIN;REQUIRE_IOSTREAM )
ELSE()
SET( MAYA_USER_DIR $ENV{HOME}/maya CACHE PATH Maya user home
directory )
SET( MAYA_ROOT /usr/autodesk/maya${MAYA_VERSION}-${MAYA_ARCH} )
ENDIF()
SET( MAYA_HEADERS_DIR ${MAYA_ROOT}/include )
SET( MAYA_LIBRARY_DIR ${MAYA_ROOT}/lib )
IF (EXISTS $ENV{MAYA_PLUG_IN_PATH})
SET ( MAYA_PLUGINS_DIR $ENV{MAYA_PLUG_IN_PATH} CACHE PATH Maya plug-in
installation directory )
ELSE ()
SET( MAYA_PLUGINS_DIR ${MAYA_ROOT}/bin/plug-ins CACHE PATH Maya
plug-in installation directory )
ENDIF ()
FIND_PACKAGE(OpenGL)
include( FindOSGHelper )
# Set all postfixes to nothing so we can compile other versions and they will
# be loaded instead of the release version by Maya.
SET(CMAKE_DEBUG_POSTFIX )
SET(CMAKE_RELWITHDEBINFO_POSTFIX )
SET(CMAKE_MINSIZEREL_POSTFIX )
SET ( LOCAL_WARNING_FLAGS /W3 )
SET ( LOCAL_RTTI_FLAGS /GR )
SET(CMAKE_INSTALL_PREFIX ${MAYA_PLUGINS_DIR})
SET(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
SET ( TARGET maya2osg )
SET ( SOURCE_FILES
src/animation.cpp
src/animation.h
src/camera.cpp
src/camera.h
src/cameraanimation.cpp
src/cameraanimation.h
src/common.cpp
src/common.h
src/config.cpp
src/config.h
src/dagnode.cpp
src/dagnode.h
src/directionallight.cpp
src/directionallight.h
src/field.cpp
src/field.h
src/group.cpp
src/group.h
src/importervisitor.cpp
src/importervisitor.h
src/lights.cpp
src/lights.h
src/maya2osg.cpp
src/maya2osg.h
src/mesh.cpp
src/mesh.h
src/nparticle.cpp
src/nparticle.h
src/osg2maya.cpp
src/osg2maya.h
src/osgfiletranslator.cpp
src/osgfiletranslator.h
src/osgwrite.cpp
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
On Mon, May 9, 2011 at 9:58 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Do you know of an easy way for CMake to create the folders (e.g., GLSL) inside the Visual Studio project source tree? See the attached file. :-) Hope this helps, You're my CMake hero! :-) -- Javier Taibo ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi J-S, On Fri, May 6, 2011 at 10:45 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Good, pardon the negativism but it's a relief that you're seeing the crash too now, at least it's not something totally trivial on my side :-) I've gotten pretty far debugging this in release with debug symbols. First it looked as if adding the shading node to the map (ShadingNetwork::registerShadingNode()) was causing it, but I debugged deeper and it's not that. If I comment out shadingnode.cpp line 67: plug.codeBlock = plug.connectedShadingNode-getCodeBlock( rp_name ); it doesn't crash anymore. In release with debug symbols it seems like the debugger sometimes gives bad information (for example sometimes the call stack looks whack, or a pointer will look invalid but will be ok) but it looks as if when rp_name is outColor it will crash shortly after. I'm sure that line is not the cause but the symptom, but maybe this info will help you debug it. I reached the same point as you, activating debugging information in the release configuration. Moreover, I converted the Maya scene to Maya 2010 and tested it in my laptop with Vista + VS 2008 Express + Maya 2010 + OSG 2.9.11 and the crash is exactly the same, only two stack frames before (surfaceshader.cpp line 158). I have to get deeper in this issue, but unfortunately I won't have much time for it. I'll let you know if I get to something. In favor of Peter I must say I am pretty sure it is my fault. I tested it in a version prior to the osgAnimation stuff and mesh export changes and it crashes the same way. It is not at all a random crash. I suppose I didn't noticed that because I always use the Debug configuration. Regards, -- Javier Taibo ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi, On Fri, May 6, 2011 at 3:24 AM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: This can actually be handled automatically with the right usage of FindOSG. But I agree that it's not always obvious how to do that. When you start writing tons of ifs for each configuration, it's a clear sign that you're not using CMake to its full potential. Yes. That is *exactly* the point :) I'll have a look at it tomorrow morning. Thank you very much. I really appreciate it. -- Javier Taibo ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Farshid, OK. The different ways you mention above, are they all currently supported by OSGExp? Meaning, the material name is exported? The object properties field is exported as descriptions you say? (I haven't gone through the code to OSGExp yet) Yes, all the methods I described are supported by the existing exporter. Question then, where do I go in Max to set these kinds of tags? Can you give me an example of what your artist would do to say that a given object (or a given material) has a normal map? Have you perhaps not seen this question? I would like to take the same approach as you as much as possible... Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Just jumping into this thread, I admit that I haven't read it all the way through, so hopefully this is relevant. What I have done to support things like specular maps and bump maps in models exported from Maya is to modify the dae loader found to support the extra tags that are added to the Collada file from OpenCollada exporter The OpenCollada exporter will add a bump tag to the dae file and also export a spec map to the specular material. Obviously this doesn't export shaders etc, so there still a bit of manual setup but it's a start. If you'd like the source changes I'm happy to let you have them. K. On 6 May 2011 15:11, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.comwrote: Hi Farshid, OK. The different ways you mention above, are they all currently supported by OSGExp? Meaning, the material name is exported? The object properties field is exported as descriptions you say? (I haven't gone through the code to OSGExp yet) Yes, all the methods I described are supported by the existing exporter. Question then, where do I go in Max to set these kinds of tags? Can you give me an example of what your artist would do to say that a given object (or a given material) has a normal map? Have you perhaps not seen this question? I would like to take the same approach as you as much as possible... Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Kim, Just jumping into this thread, I admit that I haven't read it all the way through, so hopefully this is relevant. Of course, jump in whenever you want :-) What I have done to support things like specular maps and bump maps in models exported from Maya is to modify the dae loader found to support the extra tags that are added to the Collada file from OpenCollada exporter The OpenCollada exporter will add a bump tag to the dae file and also export a spec map to the specular material. Obviously this doesn't export shaders etc, so there still a bit of manual setup but it's a start. I had considered Collada, but I'd prefer to avoid using it because it's just another intermediate format that may be interpreted one way or another. I need to support the same content pipeline coming from either Maya or 3DSMax, and both the stock and the OpenCollada exporters for these software give different results (not only the extra tags are different but other things as well). Combined with the fact that OSG's Collada reader is involved in getting the data into OSG, it'll be hard to get the same results. I'm currently working on both the Maya and Max exporters to OSG format. It's 2 plugins to maintain, but if I can get the same results from both, at least I won't have an intermediate format and an import plugin to worry about, the data will be in native OSG format straight out of the content creation tool (Maya or Max). Still, thanks for your input, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi J-S, On Fri, May 6, 2011 at 3:49 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Here are the changes I have made to maya2osg. 1. I have modified the CMake config so it will use the OSG release and debug versions correctly. 2. I made the Maya install directory user-visible because it might not be in Program Files... It is settable at install time. 3. I set the debug, release with debug info and min size release postfixes to empty so that you can compile/install either version and Maya will load it correctly (by default they are d, rd and s). 4. I removed the CONFIG_PROJECT macro since it was now being used only for OpenGL (since FindOSGHelper does all the work for OSG). 5. I aded the possibility for parallel building on MSVC. On my 8 core it builds much quicker :-) 6. The only code change is that I added .get() where needed so the plugin would compile when OSG is built with OSG_REF_PTR_IMPLICIT_CONVERSION disabled. Thank you very much. They are submitted to svn/trunk. Now the CMake script works like a charm. I hope to port it to Linux next monday. Now in VS debug mode works like a charm, did you finally manage to debug Maya and Maya2OSG from VS? I noticed that you've made changes to fix the normal mapping, but for me the plugin seems to make Maya crash when I press the Export button. I tried to debug the crash, but the plugin built in debug doesn't crash... And in release with debug symbols, the crash doesn't seem to happen in the plugin itself, because I don't get a coherent stack trace. I'm assuming you tested your change and it doesn't crash for you, so it's probably something specific to my setup. I'll let you know when I have more information. Actually, I didn't change anything there yet. It was Peter who submitted some changes related with the bumpmapping problems we detected. It was an UI option that accidentally disappeared that allowed to enable/disable bumpmapping export. I also noticed a bug in this code that make the plug-in crash when the bump texture cannot be loaded. It is already fixed, but I don't think it is the same problem you're finding. I am still working on all these and haven't reviewed yet all the changes in the last months that could cause the bump problems. However, if you can send me the scene that is crashing on your system, in case it is not too complex, I can test directly with it. Regards, -- Javier Taibo ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi all, Here it is. Argh, I didn't realize how big that was. I got a message from the list saying it awaited moderator approval, you can safely refuse it, I'll send it to Javier directly. Sorry, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi J-S, On Fri, May 6, 2011 at 7:02 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: 1. Named the osg::Light according to the MFnLight/MFnSpotLight name (i.e. if the light's MatrixTransform is directionalLight1, then the osg::Light will be directionalLightShape1) 2. Blinn materials will be shaded like Phong, with an empirical conversion of the eccentricity to an OpenGL shininess value. I haven't found any good online sources on converting the value (and the Maya doc was no help either), so I came up with my own conversion after a bit of experimentation in a spreadsheet... Seems to give roughly the right curve in specular highlight. If we can get a better conversion later I'm all for it. 3. The file connected to a Bump2d node would be converted to a tangent space normal map with the bump2normal() function. Our normal map textures are already tangent space normal maps, so they need no conversion (and converting them gave really bad results). The Bump2d node has a setting called Use As: Bump / Tangent Space Normals / Object Space Normals. I think that if the setting is not set to Bump, there should be no conversion done. So I did that, I hope you agree (or if there's some other way to do that let me know). Thank you for the changes. They are already submitted to svn/trunk. The Blinn shader was something in my to-do list. I wanted to do some research to discover what computations does Maya for it. Now we have a first approximation :) However, I don't know if it is working I saw your change in bump2normal.cpp, but it didn't help. I'm still getting a crash only in release build of the plugin, after pressing Export. I'll probably put in some prints to try and track it down, since the debug version of the plugin doesn't crash. Don't worry about it. By the way, I tested the file you sent me with tangent space normal maps, and worked OK. At least nobody crashed. The mapping is a bit weird however, but I suppose it is just a test to see if it is working. I can send you a snapshot if you want. Regards, -- Javier Taibo ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
On Fri, May 6, 2011 at 7:41 PM, Javier Taibo javier.ta...@gmail.com wrote: research to discover what computations does Maya for it. Now we have a first approximation :) However, I don't know if it is working ^ Please, ignore this line. It should not be there X-D -- Javier Taibo ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Javier, Thank you for the changes. They are already submitted to svn/trunk. Great, thanks. Can you please replace the filetexture.cpp by this one as it's the behavior I think we want - if the Use As: field is anything OTHER than Bump, don't convert bump2normal. The Blinn shader was something in my to-do list. I wanted to do some research to discover what computations does Maya for it. Now we have a first approximation :) Yep, and we can easily replace the calculation I did with anything else. By the way, I tested the file you sent me with tangent space normal maps, and worked OK. At least nobody crashed. The mapping is a bit weird however, but I suppose it is just a test to see if it is working. I can send you a snapshot if you want. No, I know the mapping is weird, I didn't do anything for that (I just wanted to have something to test with). Weird (good) that it doesn't crash for you. I'll continue testing... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Javier,
Great, thanks. Can you please replace the filetexture.cpp by this one as
it's the behavior I think we want - if the Use As: field is anything
OTHER than Bump, don't convert bump2normal.
Sorry I forgot the file, here it is.
BTW, it's fine to leave my e-mail in the AUTHORS file.
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
/**
Maya2OSG - A toolkit for exporting Maya scenes to OpenSceneGraph
Copyright (C) 2010 Javier Taibo javier.ta...@gmail.com
This file is part of Maya2OSG.
Maya2OSG is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
Maya2OSG is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with Maya2OSG. If not, see http://www.gnu.org/licenses/.
*/
#include filetexture.h
#include shadingnetwork.h
#include bump2normal.h
#include ../texture.h
#include ../shader.h
#include ../config.h
#include ../common.h
#include maya/MFnDependencyNode.h
#include maya/MPlugArray.h
#include osgDB/FileNameUtils
#include sstream
/**
* Constructor
*/
FileTexture::FileTexture( const MObject shading_node, ShadingNetwork
shading_network ) :
ShadingNode( shading_node, shading_network )
{
}
/**
* Get the GLSL Codeblock for a plug
*/
ShadingNode::CodeBlock FileTexture::getCodeBlock( const std::string plug_name )
{
CodeBlock code_block;
std::string variable_name;
MFnDependencyNode dn(_mayaShadingNode);
std::string maya_tex_name = dn.name().asChar();
// Check the plug name. Supported ones: outColor, outTransparency, outAlpha
if ( plug_name == outColor ||
plug_name == outTransparency ||
plug_name == outAlpha )
{
std::string maya_tex_name_clean = maya_tex_name;
hygienizeName( maya_tex_name_clean );
variable_name = sn_filetexture_ + maya_tex_name_clean + _output;
MPlugArray remote_plugs;
Shader::getPlugConnectedFromChannel(_mayaShadingNode, plug_name,
remote_plugs);
bool is_bump = false;
bool convert_bump = false;
if ( Config::instance()-getEnableBumpMapping() ) {
for ( int i=0 ; !is_bump i remote_plugs.length() ;
i++ ) {
std::string remote_plug_name =
remote_plugs[i].partialName(false, false, false, false, false, true).asChar();
bool has_Fn_kBump =
remote_plugs[i].node().hasFn(MFn::kBump);
if ( remote_plug_name == bumpValue
has_Fn_kBump )
{
is_bump = true;
// If the bump used is already a tangent space normal map,
no conversion is needed.
MFnDependencyNode bumpNode(remote_plugs[i].node());
MPlug plug_bumpInterp;
plug_bumpInterp = bumpNode.findPlug(bumpInterp);
// bumpInterp values: 0 = Bump, 1 = Tangent Space Normals,
2 = Object Space Normals
int bumpInterp = 0;
plug_bumpInterp.getValue(bumpInterp);
convert_bump = (bumpInterp == 0); // Convert only if
used as Bump
break;
}
}
}
std::string filename_nm;
if ( is_bump convert_bump) {
MPlug plug_filename;
MString texname;
plug_filename = dn.findPlug(fileTextureName);
plug_filename.getValue(texname);
// This texture is used as a bump (height) map, we should convert
it to a normal map
std::string filename_orig = texname.asChar();
// Convert bump map (height map) to normal map
filename_nm = bump2Normal( filename_orig );
}
// If variable not available, we compute them
if ( ! variableIsAvailable(variable_name) ) {
int tc_set_unit = _shadingNetwork.getTexturingConfig().getTCSet(
maya_tex_name );
int texture_unit =
_shadingNetwork.getTexturingConfig().getTextureUnit( maya_tex_name );
std::stringstream ss_sampler_name;
ss_sampler_name tex texture_unit _
maya_tex_name_clean;
std::string sampler_name = ss_sampler_name.str();
// Set the texture in the stateset
osg::ref_ptrosg::Texture2D tex;
if ( is_bump
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
On Fri, May 6, 2011 at 8:29 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Javier, Great, thanks. Can you please replace the filetexture.cpp by this one as it's the behavior I think we want - if the Use As: field is anything OTHER than Bump, don't convert bump2normal. Sorry I forgot the file, here it is. Updated! Now bump mapping seems to be working fine again, btw... And I must apologize, I absolutely lied to you in the other message. Your scene crashes in Release mode. Just tested it on Debug only. My mistake! I don't know where the problem is... I'm taking a look at it. If I discover something I'll let you know... -- Javier Taibo ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi J-S, jumping in to say hello, and sorry that I coudn't answer your post earlier. I'm student, and as Javier mentioned my time is very limitted these days and for the next two months. At Holiday time I contribute frequently, and I think this won't cahnge too soon. So for now this is it, I'll join discussions about topics regarding Animation/Character Export and the current Polygon Export. Cheers, PP -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39128#39128 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi, about the crash, I tried the file and it crashes on my system as well in release mode. The polygon Export creates a Log nemad Maya2OSG_Write.log, stored in the same directory of exported file. This might help a little. It exports the mesh as geometry, but than creashes. I guss in Shading stage, hope this helps a little, but can't dive deeper. Thank you! Cheers, Peter -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39130#39130 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
On Fri, May 6, 2011 at 7:11 AM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Question then, where do I go in Max to set these kinds of tags? Can you give me an example of what your artist would do to say that a given object (or a given material) has a normal map? Have you perhaps not seen this question? I would like to take the same approach as you as much as possible... Sorry, I must have missed the question. Regarding the various tagging approaches: 1) Adding prefix/suffix to image filename. I believe this is the easiest method. The filename will be applied to the exported osg::Image object. For example, you can append _[normal] to all normal map images. 2) Adding tags to the material name. Using the Material Editor in Max, you can set the name of a material to any arbitrary string. The name will be applied to the corresponding osg::StateSet and osg::Drawable object. I'm thinking of changing this so it is only applied to the osg::StateSet object. Using the previous example, you can append _[normal] to the material name to flag that it contains a normal map. 3) Modifying the object properties. I wouldn't recommend this technique for material related settings. We use it for node related settings. Right-click an object in the scene and select Object Properties. Select the User Defined tab and enter any mult-line string within the textbox. This gets exported as a description string of the corresponding osg::Node object. Let me know anything is unclear. Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Javier, Now bump mapping seems to be working fine again, btw... Yes, I agree, when I run the plugin in Debug and get an output file as a result it works well. Thanks. And I must apologize, I absolutely lied to you in the other message. Your scene crashes in Release mode. Just tested it on Debug only. My mistake! I don't know where the problem is... I'm taking a look at it. If I discover something I'll let you know... Good, pardon the negativism but it's a relief that you're seeing the crash too now, at least it's not something totally trivial on my side :-) I've gotten pretty far debugging this in release with debug symbols. First it looked as if adding the shading node to the map (ShadingNetwork::registerShadingNode()) was causing it, but I debugged deeper and it's not that. If I comment out shadingnode.cpp line 67: plug.codeBlock = plug.connectedShadingNode-getCodeBlock( rp_name ); it doesn't crash anymore. In release with debug symbols it seems like the debugger sometimes gives bad information (for example sometimes the call stack looks whack, or a pointer will look invalid but will be ok) but it looks as if when rp_name is outColor it will crash shortly after. I'm sure that line is not the cause but the symptom, but maybe this info will help you debug it. So in short, if you place a breakpoint at the line I said above (shadingnode.cpp line 67), you'll be close to the site of the crash. Thanks in advance for looking into this, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Farshid, The problem I had with my own compiled version of OSGExp was indeed caused by mismatched DLLs. The prebuilt version's installer copied the OSG DLLs into the 3dsmax directory, as well as the Previewer.dll. When compiling my own version, I was able to just have my own version of OSG on the PATH, and had to replace the Previewer.dll with my compiled version. Yes, all the methods I described are supported by the existing exporter. I agree that it's not ideal, but we came up with these methods before I was even a developer on the osgmaxexp project. So we had to work with what we had at the time. That's totally understandable. I'll look at adding some automation for this process soon. Thanks for your support, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hello again Farshid, OK. The different ways you mention above, are they all currently supported by OSGExp? Meaning, the material name is exported? The object properties field is exported as descriptions you say? (I haven't gone through the code to OSGExp yet) Yes, all the methods I described are supported by the existing exporter. Question then, where do I go in Max to set these kinds of tags? Can you give me an example of what your artist would do to say that a given object (or a given material) has a normal map? Thanks in advance, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi J-S! On Wed, May 4, 2011 at 10:27 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: maya2osg (Maya plugin) --- As for maya2osg, it also seems active (last checkin Apr. 24th) and I was able to compile it myself and use my compiled version without any problems. But again there are unanswered messages on the sourceforge forum. I've subscribed to its mailing list and posted a few questions to which I haven't yet gotten an answer but it hasn't been that long yet. However from the OMG! X-D How many minutes did you wait??? :) archives it doesn't seem the mailing list is much more active than the forum. Again, the main developer is also a member of this list, ParticlePeter. So the same question applies, where do we discuss this, here or on the project's sourceforge forums / its own mailing list? I have been quite busy last months and didn't work too much on the plug-in. Actually, the active developer was ParticlePeter, integrating osgAnimation export. I am retaking the project these days, and I'm afraid Peter is under heavy workload, so it seems we are playing turns :) About where to discuss, wherever you prefer, the OSG list, the maya2osg list. Personally I don't like forums very much. About the unanswered questions in the forum, it's a matter of time availability. I released the code in case someone finds it useful, but cannot guarantee user support. In both cases, I'd like to ask how active are the projects, really. If I do some work on them, will it likely be accepted and integrated quickly, or will it sit as a patch for a few months? Patches will be accepted and integrated ASAP, but this is a project developed in my spare time, so it is adapted to time availability. We'll be looking to have at least normal mapping exported as a basic feature - maya2osg already supports that but it's not working 100% yet, and we'll It has been broken on one of the last updates. I am checking it... Actually, I will need it soon at work so I must fix it whether I like it or not. want to add it to OSGExp. We'll also probably want to add a callback mechanism in some places, so that the exported file can be customized to the final engine's pipeline. But I can discuss this later. I hope I can work with the authors of the respective plugins and get them working for our purposes. Thanks in advance, As I already said in the other list, contributions are always welcome. It's nice to see there is people interested in the project. Regards, -- Javier Taibo ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Javier, OMG! X-D How many minutes did you wait??? :) About 5 ;-) No seriously, about 5 hours, but it's fine, I didn't really expect a reply that quick - it was meant as a joke, and I had other questions to ask for the Max export plugin too so I started a thread about both plugins. About where to discuss, wherever you prefer, the OSG list, the maya2osg list. Personally I don't like forums very much. About the unanswered questions in the forum, it's a matter of time availability. I released the code in case someone finds it useful, but cannot guarantee user support. I was just asking about forums because it made it look like the project was dead, but of course I totally understand that working on such a thing can be off and on depending on other projects and workload (see osgboostpython.googlecode.com for my own example of this :-) ). About where to discuss, I think you might have better visibility if we discuss here, that way others will know the project is active. But if you generally don't read all messages and prefer to keep the two separate I can understand. It's really up to you. Patches will be accepted and integrated ASAP, but this is a project developed in my spare time, so it is adapted to time availability. I totally understand, I just hate keeping patches locally and hate even more developing new patches over old ones and not being able to separate the work, so that's why I asked :-) As I already said in the other list, contributions are always welcome. It's nice to see there is people interested in the project. Great! I'll look into adding CMake build files tomorrow, since I just did the same thing for the Max exporter today (it went quite fast). Would you mind if the first version was Windows/VC++ only? I don't have Maya for Linux so couldn't test, and putting in a build system for Linux that should work but is untested is not a good strategy I think. Thanks for your support, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi J-S, On Thu, May 5, 2011 at 10:25 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: No seriously, about 5 hours, but it's fine, I didn't really expect a reply that quick - it was meant as a joke, and I had other questions to ask for the Max export plugin too so I started a thread about both plugins. I suppose you have a very short timeframe in justincaseidie.com :D About where to discuss, I think you might have better visibility if we discuss here, that way others will know the project is active. But if you generally don't read all messages and prefer to keep the two separate I can understand. It's really up to you. OK. If nobody consider it intrusive to the OSG list, I'll be glad to discuss here. Great! I'll look into adding CMake build files tomorrow, since I just did the same thing for the Max exporter today (it went quite fast). Would you mind if the first version was Windows/VC++ only? I don't have Maya for Linux so couldn't test, and putting in a build system for Linux that should work but is untested is not a good strategy I think. The CMake script is already in the svn/trunk. I am trying in Win7 32-bit + VS2010 Express + Maya 2011 + OSG 2.9.11. It correctly creates the VS project and it is working in Release configuration. The installation is also ready, assuming you have write permission to the plug-in directory. The only thing I have unsolved is the Debug configuration, I don't know what is the orthodox way to make it link with debug versions of OSG. I tried to detect the CMAKE_BUILD_TYPE and if it is Debug link with OSG_LIBRARY_DEBUG instead of OSG_LIBRARY, but it didn't work. I think it should probably work in Linux, but in Visual Studio the configurations are managed inside the VS project/solution and so the CMAKE_BUILD_TYPE is not known when the CMake script is evaluated. Maybe you can help me with that, and test it in your system and let me know if it works. I'm pretty sure that you have much more knowledge than me about CMake. I am developing a weird love-hate relationship with this software. Regards, -- Javier Taibo ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Javier, I suppose you have a very short timeframe in justincaseidie.com :D I didn't know about this, it's actually hilarious... It will actually only be sent if you fail to log back in to the system within the timeframe that you set, we're just sort of assuming that only death would stop you doing this. Gold :-) The only thing I have unsolved is the Debug configuration, I don't know what is the orthodox way to make it link with debug versions of OSG. This can actually be handled automatically with the right usage of FindOSG. But I agree that it's not always obvious how to do that. When you start writing tons of ifs for each configuration, it's a clear sign that you're not using CMake to its full potential. I'll have a look at it tomorrow morning. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi all, As mentioned in a recent thread I'm looking at streamlining our content creation pipeline these days. One thing I think would help is if we could get models in a state where they're usable by our engine immediately when they come out of the content creation tool. This would require a plugin which we could write for each content creation tool. But since there seem to be working and pretty actively developed plugins for 3dsmax and Maya which are the main tools we use, I would rather participate in their development if I can and add what we need. OSGExp (3dsmax plugin) --- In the case of OSGExp I saw that there have been very recent checkins to the source. However, there are many topics on its forum (on sourceforge) which are without answer since March and even January of this year. I think Farshid Lashkari (who seems to be actively working on it) is a member of this list, so my question is, where do we discuss OSGExp, here or on the sourceforge forums? As a side note, the precompiled binaries of OSGExp seem to work fine for the things I tried, but compiling myself and trying to use it in Max (2011 64bit in my case) results in an Export Module failure message when I try to export through File-Export, even though the plugin is loaded correctly by Max (I can see its toolbar and go into the options window). Trying to export through the toolbar buttons just does nothing. What can I do to troubleshoot this? Is there some console somewhere where I'd see some output telling me what went wrong? maya2osg (Maya plugin) --- As for maya2osg, it also seems active (last checkin Apr. 24th) and I was able to compile it myself and use my compiled version without any problems. But again there are unanswered messages on the sourceforge forum. I've subscribed to its mailing list and posted a few questions to which I haven't yet gotten an answer but it hasn't been that long yet. However from the archives it doesn't seem the mailing list is much more active than the forum. Again, the main developer is also a member of this list, ParticlePeter. So the same question applies, where do we discuss this, here or on the project's sourceforge forums / its own mailing list? In both cases, I'd like to ask how active are the projects, really. If I do some work on them, will it likely be accepted and integrated quickly, or will it sit as a patch for a few months? We'll be looking to have at least normal mapping exported as a basic feature - maya2osg already supports that but it's not working 100% yet, and we'll want to add it to OSGExp. We'll also probably want to add a callback mechanism in some places, so that the exported file can be customized to the final engine's pipeline. But I can discuss this later. I hope I can work with the authors of the respective plugins and get them working for our purposes. Thanks in advance, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Jean-Sébastien, Have you tried the latest pre-built 64-bit osgmaxep installer? I've done some limited testing with it on Max 2011 and 2012 and it seems to export fine. I don't check the sourceforge forums that often. I personally think osgmaxexp questions would be better asked on this mailing list, since more users would be able to see the questions and respond. I'm not sure if Robert would have any objections to this. Maybe we should create a new osg-exporters mailing list for all model exporting related questions? While I am usually busy with other projects, I always try to find time to integrate patches sent to me. Regarding normal mapping, do you intend to have the model exported with the shader embedded in the model? Our company has taken a slightly different approach. Our artist tags each texture unit and when the model is loaded we process these tags and dynamically generate a shader that combines the tagged units. This has allowed us to export models with normal, detail, reflection, specular, light, parallax, and blend maps. And since the shader is dynamically generated, it allows us to insert application specific shader code without needing to re-export each model. Cheers, Farshid On Wed, May 4, 2011 at 1:27 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi all, As mentioned in a recent thread I'm looking at streamlining our content creation pipeline these days. One thing I think would help is if we could get models in a state where they're usable by our engine immediately when they come out of the content creation tool. This would require a plugin which we could write for each content creation tool. But since there seem to be working and pretty actively developed plugins for 3dsmax and Maya which are the main tools we use, I would rather participate in their development if I can and add what we need. OSGExp (3dsmax plugin) --- In the case of OSGExp I saw that there have been very recent checkins to the source. However, there are many topics on its forum (on sourceforge) which are without answer since March and even January of this year. I think Farshid Lashkari (who seems to be actively working on it) is a member of this list, so my question is, where do we discuss OSGExp, here or on the sourceforge forums? As a side note, the precompiled binaries of OSGExp seem to work fine for the things I tried, but compiling myself and trying to use it in Max (2011 64bit in my case) results in an Export Module failure message when I try to export through File-Export, even though the plugin is loaded correctly by Max (I can see its toolbar and go into the options window). Trying to export through the toolbar buttons just does nothing. What can I do to troubleshoot this? Is there some console somewhere where I'd see some output telling me what went wrong? maya2osg (Maya plugin) --- As for maya2osg, it also seems active (last checkin Apr. 24th) and I was able to compile it myself and use my compiled version without any problems. But again there are unanswered messages on the sourceforge forum. I've subscribed to its mailing list and posted a few questions to which I haven't yet gotten an answer but it hasn't been that long yet. However from the archives it doesn't seem the mailing list is much more active than the forum. Again, the main developer is also a member of this list, ParticlePeter. So the same question applies, where do we discuss this, here or on the project's sourceforge forums / its own mailing list? In both cases, I'd like to ask how active are the projects, really. If I do some work on them, will it likely be accepted and integrated quickly, or will it sit as a patch for a few months? We'll be looking to have at least normal mapping exported as a basic feature - maya2osg already supports that but it's not working 100% yet, and we'll want to add it to OSGExp. We'll also probably want to add a callback mechanism in some places, so that the exported file can be customized to the final engine's pipeline. But I can discuss this later. I hope I can work with the authors of the respective plugins and get them working for our purposes. Thanks in advance, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Farshid, Thanks for answering. Have you tried the latest pre-built 64-bit osgmaxep installer? I've done some limited testing with it on Max 2011 and 2012 and it seems to export fine. Yes, as I said it works fine. The problems arise when I compile the plugin myself and try to use my compiled version in Max... It doesn't seem to work the same as the pre-built one. My question is how do I troubleshoot this? Is there some console window I can open in Max that would give me some more output? For the obvious stuff: - Max 2011 64 bit, so I compiled OSG in 64 bit, and the plugin compiles in 64 bit and links to 64 bit OSG and Max SDK. - In plugin.ini I made Max load my own compiled version of the plugin instead of the pre-built one. - The plugin is loaded (I see it in the plugin info window, with a green icon to say it's loaded). - I have the 64 bit OSG bin on my PATH when I start Max. One thing I just thought is that the pre-built plugin might install OSG binaries somewhere which might be picked up before the ones that match my own version of the plugin. I'll check that when I get to work tomorrow morning. I don't check the sourceforge forums that often. I personally think osgmaxexp questions would be better asked on this mailing list, since more users would be able to see the questions and respond. I'm not sure if Robert would have any objections to this. Maybe we should create a new osg-exporters mailing list for all model exporting related questions? Unless Robert objects, I'm fine discussing it here too if it suits you. While I am usually busy with other projects, I always try to find time to integrate patches sent to me. Good to know. Regarding normal mapping, do you intend to have the model exported with the shader embedded in the model? Our company has taken a slightly different approach. Our artist tags each texture unit and when the model is loaded we process these tags and dynamically generate a shader that combines the tagged units. This has allowed us to export models with normal, detail, reflection, specular, light, parallax, and blend maps. And since the shader is dynamically generated, it allows us to insert application specific shader code without needing to re-export each model. I would also prefer some way to flag as well, since that is more flexible to adapt to application-specific shaders. You say your artist tags texture units, how does he do that exactly? It sounds like what we want too, and the list of effects you support sounds like more than what we need currently. I would like a workflow that takes advantage of the fact that the materials can all be setup in Max. IMHO, the artist should do all his work in Max, and then the plugin can do whatever is needed to adapt the scene to what the engine needs. I agree that embedding the shaders in the file will not work since shaders are often engine- and rendering-pipeline-specific. So in that case, one way might be that whenever the plugin encounters a material that has a normal map, it could add comments to the stateset (which already contains the diffuse texture) to say which normal map texture to use, on which texture unit, etc. The engine can then look for those comments, load the texture and apply the specific shaders needed at load time. And same thing for other effects. Does that sound more or less like what you're doing? Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
On Wed, May 4, 2011 at 4:55 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Yes, as I said it works fine. The problems arise when I compile the plugin myself and try to use my compiled version in Max... It doesn't seem to work the same as the pre-built one. My question is how do I troubleshoot this? Is there some console window I can open in Max that would give me some more output? Sorry, I must have misread your original email. What is the exact error message you are seeing? The installer will place the pre-built osg binaries in the max application folder. It also adds the appropriate osgexp install path to plugin.ini. So make sure to replace all the installed DLLs with your own. If the plugin is loading fine but fails during export, then it might be loading the incorrect ReaderWriter plugin. I'm not sure if Max has any sort of output console for debugging purposes. I would also prefer some way to flag as well, since that is more flexible to adapt to application-specific shaders. You say your artist tags texture units, how does he do that exactly? It sounds like what we want too, and the list of effects you support sounds like more than what we need currently. I would like a workflow that takes advantage of the fact that the materials can all be setup in Max. IMHO, the artist should do all his work in Max, and then the plugin can do whatever is needed to adapt the scene to what the engine needs. I agree that embedding the shaders in the file will not work since shaders are often engine- and rendering-pipeline-specific. So in that case, one way might be that whenever the plugin encounters a material that has a normal map, it could add comments to the stateset (which already contains the diffuse texture) to say which normal map texture to use, on which texture unit, etc. The engine can then look for those comments, load the texture and apply the specific shaders needed at load time. And same thing for other effects. Does that sound more or less like what you're doing? Yes, this is more or less what we currently do. Our artist applies and tags all the various texture maps in Max. I believe we've created models that have used up to 9 texture units. The exported model can then be directly loaded into our application, which dynamically processes the embedded tags and generates the shader. We've been using this method for the past 4 years and it has worked it really well for us. Whenever we make improvements/optimizations to our shaders, all existing models will benefit without needing to re-export. Plus, our shader generator will cache and reuse shaders when loading different models containing the same material setup. This reduces the number of shader objects that are created on the GPU. There are various ways for the artist to tag the materials. You can add a special prefix/suffix to the texture map names. You can use the material name to encode certain attributes. You can use the object properties field for storing meta data, which gets exported to the node description field. I'm actually looking into adding support for exporting custom material attributes. I'm always looking to improve our art workflow, so feel free to point out any limitations/problems you encounter. Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Farshid, Sorry, I must have misread your original email. What is the exact error message you are seeing? The installer will place the pre-built osg binaries in the max application folder. It also adds the appropriate osgexp install path to plugin.ini. So make sure to replace all the installed DLLs with your own. OK, I'm pretty sure this is the problem, then. I added the path to my own OSG binaries to my PATH, but if another version of the same DLLs are in the app's directory they'll be picked up first. I'll look at this in the morning. I'm not sure if Max has any sort of output console for debugging purposes. That's unfortunate... The error message was rather terse, a message box with Export Module failure written in it, and an OK button. That's all. Yes, this is more or less what we currently do. Our artist applies and tags all the various texture maps in Max. I believe we've created models that have used up to 9 texture units. The exported model can then be directly loaded into our application, which dynamically processes the embedded tags and generates the shader. We've been using this method for the past 4 years and it has worked it really well for us. OK, my question was more where are those tags put in the Max scene, but it seems you go into that a bit later... Whenever we make improvements/optimizations to our shaders, all existing models will benefit without needing to re-export. Plus, our shader generator will cache and reuse shaders when loading different models containing the same material setup. This reduces the number of shader objects that are created on the GPU. Yep, that's what we do too, and I want to keep it this way with the new art path I'm putting in place, so it seems we're on the same page on this. There are various ways for the artist to tag the materials. You can add a special prefix/suffix to the texture map names. You can use the material name to encode certain attributes. You can use the object properties field for storing meta data, which gets exported to the node description field. I'm actually looking into adding support for exporting custom material attributes. OK. The different ways you mention above, are they all currently supported by OSGExp? Meaning, the material name is exported? The object properties field is exported as descriptions you say? (I haven't gone through the code to OSGExp yet) If the Max material has normal mapping, I think it would be easy for the plugin to add these tags automatically without the artist needing to do anything. So perhaps some automation can be added to supplement the tags system you're already using. I think if the artist can do his work as an artist only and get the right results in the engine once exported, that would be better. Meaning, if the artist knows how to make a nice render with normal maps, he will setup the scene the same way, and it will work in the engine too. The less special attributes and text-based tags (which can contain typos of course) he has to work with, the better, IMHO. That's not saying that your solution is bad, just that again I think it's a bit too programmer/engineer focused, which I'm trying to avoid. Thanks for your support, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Jean-Sébastien, OK. The different ways you mention above, are they all currently supported by OSGExp? Meaning, the material name is exported? The object properties field is exported as descriptions you say? (I haven't gone through the code to OSGExp yet) Yes, all the methods I described are supported by the existing exporter. I agree that it's not ideal, but we came up with these methods before I was even a developer on the osgmaxexp project. So we had to work with what we had at the time. Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
