maya2osg-users — Maya2OSG mailing list

Re: [Maya2osg-users] Texture processing

[Jean-Sébastien G. <jea...@cm...>]

Hi Javier,

>    I have just committed a fix for this issue. I do a pair of quick
> tests with OpenGL materials and GLSL shaders and it seems to be
> working OK.
>
>    Can you verify it is OK in your tests?

1) Diffuse (color) texture seems to be copied / converted correctly now, 
whether or not I enable GLSL shaders.

2) Normal maps are still not being copied / converted if I don't enable 
GLSL shaders (even with enable bump/normal maps - I guess the intent is 
that enabling normal maps but without enabling GLSL shaders does 
nothing, but in my case I just don't want to embed shaders)

3) If I have all 3 options (Export materials, GLSL shaders and 
bump/normal maps) checked, the plugin makes Maya crash in assign() being 
called from Mesh.cpp line 477.


Thanks,

J-S
-- 
______________________________________________________
Jean-Sebastien Guay    jea...@cm...
                                http://www.cm-labs.com/
                     http://whitestar02.dyndns-web.com/

Re: [Maya2osg-users] Texture processing

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

  Hi J-S,

  I have just committed a fix for this issue. I do a pair of quick
tests with OpenGL materials and GLSL shaders and it seems to be
working OK.

  Can you verify it is OK in your tests?


  Regards,


On Thu, Jun 16, 2011 at 5:27 PM, Jean-Sébastien Guay
<jea...@cm...> wrote:
> Hi Javier,
>
>> I'll compile a debug version and see what's going on.
>
> Of course, I found out about 2 seconds after building in debug, but I
> wouldn't even have had to...
>
> I don't want to generate GLSL shaders. I think your texture processing
> code should happen even if only "Export Shaders" is checked, not "Build
> GLSL Shaders".
>
> All use of textures should follow the same rules, whether GLSL shaders
> are being generated or not. So I think these calls will need to be moved
> somewhere else... Perhaps in Texture::exporta(), which is called by both
> FileTexture::getCodeBlock() and Shader::exporta() (indirectly).
>
> Thanks in advance,
>
> J-S
> --
> ______________________________________________________
> Jean-Sebastien Guay    jea...@cm...
>                                http://www.cm-labs.com/
>                     http://whitestar02.dyndns-web.com/
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Maya2osg-users mailing list
> May...@li...
> https://lists.sourceforge.net/lists/listinfo/maya2osg-users
>



-- 
Javier Taibo

Re: [Maya2osg-users] Texture processing

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

On Thu, Jun 16, 2011 at 5:27 PM, Jean-Sébastien Guay
<jea...@cm...> wrote:
> Hi Javier,
>
>> I'll compile a debug version and see what's going on.
>
> Of course, I found out about 2 seconds after building in debug, but I
> wouldn't even have had to...
>
> I don't want to generate GLSL shaders. I think your texture processing
> code should happen even if only "Export Shaders" is checked, not "Build
> GLSL Shaders".
>
> All use of textures should follow the same rules, whether GLSL shaders
> are being generated or not. So I think these calls will need to be moved
> somewhere else... Perhaps in Texture::exporta(), which is called by both
> FileTexture::getCodeBlock() and Shader::exporta() (indirectly).

  You're right, I didn't test this case as I was always exporting GLSL
shaders. I'll take a look at this issue as soon as I have time.

  Thanks for the feedback!

-- 
Javier Taibo

Re: [Maya2osg-users] Texture processing

[Jean-Sébastien G. <jea...@cm...>]

Hi Javier,

>    I've just tested it right now with the code in the tunk (SVN
> revision 213) and it is working OK without NVTT. I exported a model
> with a color texture and a bump map that were converted to .png and
> copied to the export directory with the OSG file.
>
>    I really don't know what is happening here... have you seen any
> significant message in the console output?

I am at the same SVN revision, and is up-to-date in Maya2012\bin\plug-ins.

Here is the output in the Output Window:

Initialized VP2.0 renderer {
   Version : 2.7.0.18. Feature Level 3.1.
   Device : NVIDIA GeForce GTX 260
   Driver : nvoglv64.dll:8.17.12.7061.
   API : OpenGL V.2
   Max texture size : 8192 * 8192.
   Max tex coords : 8
   Shader versions supported (Vertex: 4, Geometry: 4, Pixel 4).
   CPU Memory Limit: 11665 MB.
}
Loading Maya2OSG plug-in. Maya2OSG 0.4.2c (OpenSceneGraph Library 2.9.17)
---------------------------------------------------
---      Maya2OSG - OSG Maya Exporter           ---
---------------------------------------------------
--  OUTPUT FILE : 
C:/Users/jeang/Documents/maya/projects/default/scenes/box_normalmap_maya2osg.osg
---------------------------------------------------
0 element(s) selected
Geode "pCubeShape2" with Geometries !
Geode "pCubeShape1" with Geometries !
---------------------------------------------------
---      Exportation successfully completed     ---
---------------------------------------------------

And the script editor just says

File Exported : 
"C:/Users/jeang/Documents/maya/projects/default/scenes/box_normalmap_maya2osg.osg"

I'll compile a debug version and see what's going on.

Thanks,

J-S
-- 
______________________________________________________
Jean-Sebastien Guay    jea...@cm...
                                http://www.cm-labs.com/
                     http://whitestar02.dyndns-web.com/

Re: [Maya2osg-users] Texture processing

[Jean-Sébastien G. <jea...@cm...>]

Hi Javier,

> I'll compile a debug version and see what's going on.

Of course, I found out about 2 seconds after building in debug, but I 
wouldn't even have had to...

I don't want to generate GLSL shaders. I think your texture processing 
code should happen even if only "Export Shaders" is checked, not "Build 
GLSL Shaders".

All use of textures should follow the same rules, whether GLSL shaders 
are being generated or not. So I think these calls will need to be moved 
somewhere else... Perhaps in Texture::exporta(), which is called by both 
FileTexture::getCodeBlock() and Shader::exporta() (indirectly).

Thanks in advance,

J-S
-- 
______________________________________________________
Jean-Sebastien Guay    jea...@cm...
                                http://www.cm-labs.com/
                     http://whitestar02.dyndns-web.com/

Re: [Maya2osg-users] Texture processing

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

  Hi J-S,

On Thu, Jun 16, 2011 at 3:53 PM, Jean-Sébastien Guay
<jea...@cm...> wrote:
>
>>    That's great. If you don't have NVTT installed yet, could you please
>> test it before and after installing NVTT? This way we verify that both
>> sections of the code are fine.
>
> Without nvtt there doesn't seem to be a change by default.
>
> I see the default is copyTextures=true and texturePath=. , but I don't
> see any textures in the directory of the exported file, and the file
> still contains absolute paths to the textures, is this normal? I thought
> with copyTextures=true, it was supposed to copy the textures to
> texturePath (where "." I assume means the same directory as the exported
> file?), and set the path to textures to be relative in the exported .osg
> file, but that doesn't seem to happen.
>
> I'll wait for confirmation on this before testing with nvtt.

  I've just tested it right now with the code in the tunk (SVN
revision 213) and it is working OK without NVTT. I exported a model
with a color texture and a bump map that were converted to .png and
copied to the export directory with the OSG file.

  I really don't know what is happening here... have you seen any
significant message in the console output?

-- 
Javier Taibo

Re: [Maya2osg-users] Texture processing

[Jean-Sébastien G. <jea...@cm...>]

Hi Javier,

>    No, I mean the parsing is not implemented AT ALL  :)

OK, I understand now :-)

>    That's great. If you don't have NVTT installed yet, could you please
> test it before and after installing NVTT? This way we verify that both
> sections of the code are fine.

Without nvtt there doesn't seem to be a change by default.

I see the default is copyTextures=true and texturePath=. , but I don't 
see any textures in the directory of the exported file, and the file 
still contains absolute paths to the textures, is this normal? I thought 
with copyTextures=true, it was supposed to copy the textures to 
texturePath (where "." I assume means the same directory as the exported 
file?), and set the path to textures to be relative in the exported .osg 
file, but that doesn't seem to happen.

I'll wait for confirmation on this before testing with nvtt.

Thanks,

J-S
-- 
______________________________________________________
Jean-Sebastien Guay    jea...@cm...
                                http://www.cm-labs.com/
                     http://whitestar02.dyndns-web.com/

Re: [Maya2osg-users] Texture processing

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

  Hi J-S,

On Thu, Jun 16, 2011 at 3:59 AM, Jean-Sébastien Guay
<jea...@cm...> wrote:
> Hi Javier,
>
>>    What do you guys think about all this stuff? Suggestions? Comments?
>> Criticisms? Opinions? ...
>
> All this sounds good. When you say "What is still not implemented is the
> parsing of these options", you mean they're not stored in the Maya
> settings? Are they settable in the plugin GUI?

  No, I mean the parsing is not implemented AT ALL  :)  The options
are not stored in Maya settings, they are not settable in the plug-in
GUI, not even in the command-line parameters, they are absolutely
hardwired. They are currently set in the config.cpp initialization.
This part of the work is in the to-do list.

  That's why I was asking Peter about the state of the new config
system. But I suppose he is busy this days.


> For maxTextureSize, is there a way to keep it unset (no maximum)? I
> think we'll probably want to set it, but still, it would be nice if it
> was possible to keep this open.

  Of course! There is no problem, setting 0 as maxTextureSize removes the limit.

>>    J-S, can you test this new code is working for you? I think the
>> problems you commented in your last messages should be fixed.
>
> I'll compile tomorrow when I get to work. I currently have only 32-bit
> NVTT installed, so I'll have to install the 64 bit version to be able to
> compile the plugin for my 64-bit version of Maya, but that should be quick.

  That's great. If you don't have NVTT installed yet, could you please
test it before and after installing NVTT? This way we verify that both
sections of the code are fine.

Regards,


-- 
Javier Taibo

Re: [Maya2osg-users] Texture processing

[Jean-Sébastien G. <jea...@cm...>]

Hi Javier,

>    What do you guys think about all this stuff? Suggestions? Comments?
> Criticisms? Opinions? ...

All this sounds good. When you say "What is still not implemented is the 
parsing of these options", you mean they're not stored in the Maya 
settings? Are they settable in the plugin GUI?

For maxTextureSize, is there a way to keep it unset (no maximum)? I 
think we'll probably want to set it, but still, it would be nice if it 
was possible to keep this open.

>    J-S, can you test this new code is working for you? I think the
> problems you commented in your last messages should be fixed.

I'll compile tomorrow when I get to work. I currently have only 32-bit 
NVTT installed, so I'll have to install the 64 bit version to be able to 
compile the plugin for my 64-bit version of Maya, but that should be quick.

I'll let you know how it goes. Thanks for all your work!

J-S
-- 
______________________________________________________
Jean-Sebastien Guay    jea...@cm...
                                http://www.cm-labs.com/
                     http://whitestar02.dyndns-web.com/

[Maya2osg-users] Texture processing

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

  Hi all,

  I have committed some changes to texture processing. A brief
description of new features (I will document it, I promise :)

  - Optional dependency from NVIDIA Texture Tools for processing the
textures (check the CMake config).
  - New options to texture processing:

  	/// Texture options
	struct TextureOptions {
		bool regenerateTextures;	///< Regenerate textures (even when they
are up-to-date)
		bool scaleToPOT;	///< Scale to (nearest) power of two
		bool compressTextures;	///< Compress the texture to a BC format
		TextureCompressionFormat colorCompressionFormat;	///< Compression
format for color textures
		TextureCompressionFormat normalCompressionFormat;	///< Compression
format for normal maps
		bool generateMipmaps;	///< Generate mipmaps (and store them in the file)
		int maxTextureSize;		///< Maximum texture side size (when converting
with NVTT)
		std::string textureFileFormat;	///< Texture file format (if
compression or mipmap generation, it is forced to .dds)
		bool copyTextures;	///< Copy textures with exported scene instead of
using the path to Maya sourceimages directory
		std::string texturePath;	///< Texture path to store files into (can
be relative to the scene directory)
	};

  With the copyTextures option, textures will be copied from the
original path to the directory where the OSG file is created. We can
specify a subdirectory there if texturePath has a relative path, or we
can set an absolute path there. The exported OSG file will try to use
relative paths when possible (it always used absolute paths before).

  Apart from just copying the textures from the original location to
this destination, we can compress them to several texture compression
formats supported by NVTT, generate mipmaps and store them in the
texture file or resize to the nearest power of two.

  The original texture will be processed when the destination does not
exist or the file timestamp is older than the original one, unless the
regenerateTextures options is set true, in which case textures are
always processed.

  This is basically what it does, I think the options are quite
descriptive. Most of them match the NVTT options.

  Texture processing is only available when compiled with NVTT
support, and in DDS format. When NVTT is not available or an output
format different than DDS is selected, texture files can still be
copied to the desired output file format (as long as it is supported
by OSG). Bump (height) maps are also converted to normal maps without
NVTT as before.

  What is still not implemented is the parsing of these options.
Default values are set in config.cpp (change them there if you want to
test with different options). Peter, you suggested to change the
Config stuff, so I didn't add the parsing because I don't know if
you're already changing the config system. What do you think? May I
create the parsing code or is it better to wait for the new config
system?


  What do you guys think about all this stuff? Suggestions? Comments?
Criticisms? Opinions? ...

  J-S, can you test this new code is working for you? I think the
problems you commented in your last messages should be fixed.


  Regards,

-- 
Javier Taibo

Re: [Maya2osg-users] Version.h header and out-of-source builds

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

  Committed!

On Wed, Jun 15, 2011 at 11:53 PM, Jean-Sébastien Guay
<jea...@cm...> wrote:
> Hi Javier,
>
>>    Don't worry about this file. I am changing the texture processing in
>> Maya2OSG, though I still haven't finished the changes.
>
> Well the problem is that for now, this file doesn't compile at all for
> out-of-source builds. So perhaps you can check in the modified file I
> sent, while we wait for your other changes?
>
> For the other change, that's fine, if this code doesn't even exist
> anymore :-)
>
> J-S
> --
> ______________________________________________________
> Jean-Sebastien Guay    jea...@cm...
>                                http://www.cm-labs.com/
>                     http://whitestar02.dyndns-web.com/
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Maya2osg-users mailing list
> May...@li...
> https://lists.sourceforge.net/lists/listinfo/maya2osg-users
>



-- 
Javier Taibo

Re: [Maya2osg-users] Version.h header and out-of-source builds

[Jean-Sébastien G. <jea...@cm...>]

Hi Javier,

>    Don't worry about this file. I am changing the texture processing in
> Maya2OSG, though I still haven't finished the changes.

Well the problem is that for now, this file doesn't compile at all for 
out-of-source builds. So perhaps you can check in the modified file I 
sent, while we wait for your other changes?

For the other change, that's fine, if this code doesn't even exist 
anymore :-)

J-S
-- 
______________________________________________________
Jean-Sebastien Guay    jea...@cm...
                                http://www.cm-labs.com/
                     http://whitestar02.dyndns-web.com/

Re: [Maya2osg-users] Small mistake in filetexture

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

  As I said in my previous message, I am changing this code, so maybe
the mistake was already corrected (and some new mistakes added :)

  I would ask you to wait until I commit the new texture code and test
it. I really appreciate it.


  Regards,


On Wed, Jun 15, 2011 at 10:10 PM, Jean-Sébastien Guay
<jea...@cm...> wrote:
> Hi guys,
>
> I made a small mistake in filetexture.cpp when I made modifications.
> Basically, in some cases the filename of the normal map would stay empty and
> be used as such.
>
> See the attached file for the fix.
>
> Thanks,
>
> J-S
> --
> ______________________________________________________
> Jean-Sebastien Guay    jea...@cm...
>                               http://www.cm-labs.com/
>                    http://whitestar02.dyndns-web.com/
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Maya2osg-users mailing list
> May...@li...
> https://lists.sourceforge.net/lists/listinfo/maya2osg-users
>
>



-- 
Javier Taibo

Re: [Maya2osg-users] Version.h header and out-of-source builds

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

  Hi J-S,

  Don't worry about this file. I am changing the texture processing in
Maya2OSG, though I still haven't finished the changes.

  The files bump2normal.{h,cpp} won't exist anymore. And the ones that
replace them include "version.h", so I hope there is no problem.
Anyway, when I commit the changes I will write a message to the list
explaining the new features. It would be nice if you guys could test
it and give some feedback.


  Regards,


On Wed, Jun 15, 2011 at 9:57 PM, Jean-Sébastien Guay
<jea...@cm...> wrote:
> Hello guys,
>
> I saw there's now an autogenerated version.h header, which gets included as
> #include "../version.h" in bump2normal.cpp. However, in out-of-source
> builds, this is not valid, as ../ means the root maya2osg directory.
>
> The osgpreview.cpp file already includes version.h as #include "version.h"
> and because of include paths, this works fine for in-source and
> out-of-source builds, so I suggest it be included the same way in
> bump2normal.cpp as well.
>
> Attached modified source file.
>
> J-S
> --
> ______________________________________________________
> Jean-Sebastien Guay    jea...@cm...
>                               http://www.cm-labs.com/
>                    http://whitestar02.dyndns-web.com/
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Maya2osg-users mailing list
> May...@li...
> https://lists.sourceforge.net/lists/listinfo/maya2osg-users
>
>



-- 
Javier Taibo

[Maya2osg-users] Small mistake in filetexture

[Jean-Sébastien G. <jea...@cm...>]

Hi guys,

I made a small mistake in filetexture.cpp when I made modifications. 
Basically, in some cases the filename of the normal map would stay empty 
and be used as such.

See the attached file for the fix.

Thanks,

J-S
-- 
______________________________________________________
Jean-Sebastien Guay    jea...@cm...
                                http://www.cm-labs.com/
                     http://whitestar02.dyndns-web.com/

[Maya2osg-users] Version.h header and out-of-source builds

[Jean-Sébastien G. <jea...@cm...>]

Hello guys,

I saw there's now an autogenerated version.h header, which gets included 
as #include "../version.h" in bump2normal.cpp. However, in out-of-source 
builds, this is not valid, as ../ means the root maya2osg directory.

The osgpreview.cpp file already includes version.h as #include 
"version.h" and because of include paths, this works fine for in-source 
and out-of-source builds, so I suggest it be included the same way in 
bump2normal.cpp as well.

Attached modified source file.

J-S
-- 
______________________________________________________
Jean-Sebastien Guay    jea...@cm...
                                http://www.cm-labs.com/
                     http://whitestar02.dyndns-web.com/

Re: [Maya2osg-users] Config Implementation

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

Hi Javier, fine, I'll try :-)
>    I absolutely agree with everything!
>
> On Tue, May 31, 2011 at 6:16 PM, Peter Wrobel<pp...@cg...>  wrote:
>> Hi,
>>
>> I added new flags, and think that the Config Class should be refactored,
>> as we have to change a lot at lot of places.
>> Adding attributes getter and setter to Config.h,
>> Initializing the attributes in Config.cpp
>> adding lot of hard to read code to osg write for parsing
>> Morover, when Config.h has changed, this means recompile of nearly all
>> sources, as its included nearly everywhere.
>>
>> Here is my suggestion of improvement, and would like to know if this
>> would be O.K. for you ( Javier and all ).
>>
>> instead of e.g.
>>
>> Config::Instance ->  getComputeShadow ;
>> Config::Instance ->  getBool( "ComputeShadow" ) ;
>>
>> this would access a map<  std::string , bool>  and deliver the Value
>>
>> same maps would exist for other types, enums would be a map<
>> std::string , std::string>  and the function getEnum would convert it
>> back to the proper enum.
>>
>> best thing would be even typeless, e.g. Config::Instance ->  get(
>> "ComputeShadow" ), but I would not know how to implement this,
>> overwriting this function would not work, as input is always a string,
>> and only returntype would be different.
>>
>> So back to getType( std::string ).
>> The Maps would be declared in Config.h, defined and populated with
>> default values in Config.cpp.
>> When an export command is invoked, osgwriter searches each map for the
>> argument string ( key ), and sets the second pair value to the next
>> argument of the argumant list.
>>
>> Advantages:
>> We would not need to change Config.h ( seldom at least ) so no need for
>> recompile
>> Defining default arguments would be one line, adding argument as key and
>> default value as 2nd pair value.
>> There would be one single short loop as argument parser, which just
>> searches arguments ( keys ) in each map., and replaces the value.
>>
>> Drawbacks:
>> Accessing Config has to be changed in all the files that query the config.
>>
>> Javier, I would like to try this, if this is O.K. for you, and any
>> critics or comments are welcome.
>>
>> Cheers, PP
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Simplify data backup and recovery for your virtual environment with vRanger.
>> Installation's a snap, and flexible recovery options mean your data is safe,
>> secure and there when you need it. Data protection magic?
>> Nope - It's vRanger. Get your free trial download today.
>> http://p.sf.net/sfu/quest-sfdev2dev
>> _______________________________________________
>> Maya2osg-users mailing list
>> May...@li...
>> https://lists.sourceforge.net/lists/listinfo/maya2osg-users
>>
>
>

Re: [Maya2osg-users] Config Implementation

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

  I absolutely agree with everything!

On Tue, May 31, 2011 at 6:16 PM, Peter Wrobel <pp...@cg...> wrote:
> Hi,
>
> I added new flags, and think that the Config Class should be refactored,
> as we have to change a lot at lot of places.
> Adding attributes getter and setter to Config.h,
> Initializing the attributes in Config.cpp
> adding lot of hard to read code to osg write for parsing
> Morover, when Config.h has changed, this means recompile of nearly all
> sources, as its included nearly everywhere.
>
> Here is my suggestion of improvement, and would like to know if this
> would be O.K. for you ( Javier and all ).
>
> instead of e.g.
>
> Config::Instance -> getComputeShadow ;
> Config::Instance -> getBool( "ComputeShadow" ) ;
>
> this would access a map< std::string , bool > and deliver the Value
>
> same maps would exist for other types, enums would be a map <
> std::string , std::string > and the function getEnum would convert it
> back to the proper enum.
>
> best thing would be even typeless, e.g. Config::Instance -> get(
> "ComputeShadow" ), but I would not know how to implement this,
> overwriting this function would not work, as input is always a string,
> and only returntype would be different.
>
> So back to getType( std::string ).
> The Maps would be declared in Config.h, defined and populated with
> default values in Config.cpp.
> When an export command is invoked, osgwriter searches each map for the
> argument string ( key ), and sets the second pair value to the next
> argument of the argumant list.
>
> Advantages:
> We would not need to change Config.h ( seldom at least ) so no need for
> recompile
> Defining default arguments would be one line, adding argument as key and
> default value as 2nd pair value.
> There would be one single short loop as argument parser, which just
> searches arguments ( keys ) in each map., and replaces the value.
>
> Drawbacks:
> Accessing Config has to be changed in all the files that query the config.
>
> Javier, I would like to try this, if this is O.K. for you, and any
> critics or comments are welcome.
>
> Cheers, PP
>
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> Maya2osg-users mailing list
> May...@li...
> https://lists.sourceforge.net/lists/listinfo/maya2osg-users
>



-- 
Javier Taibo

[Maya2osg-users] Config Implementation

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

Hi,

I added new flags, and think that the Config Class should be refactored, 
as we have to change a lot at lot of places.
Adding attributes getter and setter to Config.h,
Initializing the attributes in Config.cpp
adding lot of hard to read code to osg write for parsing
Morover, when Config.h has changed, this means recompile of nearly all 
sources, as its included nearly everywhere.

Here is my suggestion of improvement, and would like to know if this 
would be O.K. for you ( Javier and all ).

instead of e.g.

Config::Instance -> getComputeShadow ;
Config::Instance -> getBool( "ComputeShadow" ) ;

this would access a map< std::string , bool > and deliver the Value

same maps would exist for other types, enums would be a map < 
std::string , std::string > and the function getEnum would convert it 
back to the proper enum.

best thing would be even typeless, e.g. Config::Instance -> get( 
"ComputeShadow" ), but I would not know how to implement this, 
overwriting this function would not work, as input is always a string, 
and only returntype would be different.

So back to getType( std::string ).
The Maps would be declared in Config.h, defined and populated with 
default values in Config.cpp.
When an export command is invoked, osgwriter searches each map for the 
argument string ( key ), and sets the second pair value to the next 
argument of the argumant list.

Advantages:
We would not need to change Config.h ( seldom at least ) so no need for 
recompile
Defining default arguments would be one line, adding argument as key and 
default value as 2nd pair value.
There would be one single short loop as argument parser, which just 
searches arguments ( keys ) in each map., and replaces the value.

Drawbacks:
Accessing Config has to be changed in all the files that query the config.

Javier, I would like to try this, if this is O.K. for you, and any 
critics or comments are welcome.

Cheers, PP

Re: [Maya2osg-users] osgpreview, UI and flags

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

Hi Javier, all of the bellow has time if you are busy

>    I found some errors when trying to select the files with custom GLSL
> code from the browser:
>
> // Error: Object 'maya2osgUI_vertDeclareFile' not found.
> // Error: Object 'maya2osgUI_vertComputeFile' not found.
> // Error: Object 'maya2osgUI_fragDeclareFile' not found.
> // Error: Object 'maya2osgUI_fragComputeFile' not found.
>

Fixed.

>    I like how is being organized the UI. I think it is much cleaner and
> easy to use. Great work!
>

Thanks, but most of it your ideas.
I added those comments after the Checkboxes, but I don't know if we 
should keep them, they might be disturbing. What do you think ?

>> Hi all,
>>
>> answering to my own post, as most of the stuff is implemented.
>>> I would like to add an optionMenu to the preview command textfield,
>>> which changes the behavior of the command field, with these options:
>>>
>>> Mel:
>>> current behaviour
>>>
>>> Pyth:
>>> corresponding Python script
>> not done, don`t know if required at all, will implement on request.
>>
>>> Exec:
>>> which would take an os command ( like "osgviewer --flags file" ) without
>>> the need of "exec" infront of it
>>>
>>> Flag:
>>> this would call osgpreview with flags entered inside the textfield,
>>> overriding those hardcoded in the export script
>>>
>>> Edit: ( maybe )
>>> this would pop up a bigger window for editing text, in the case one of
>>> the above needs more space
>> Same as "Pyth"
>>
>> Javier, you might want to test the behavior of the new options.  Have
>> one suggestion to the preview command, that one should be able to pass
>> the count of lights as argument. This would enable GL_Lights up to 8 or
>> turn off GL_Lighting, if no light is present in the test scen. Silly me,
>> was searching quite long for an error, because I couldn't see my content
>> in the preview window. But I just had no Lights created. So with passing
>> 0 lights to the preview command would eliminte such an issue.
>    The scene lighting set and some other issues are on my to-do list.
> I'll address it as soon as I have time. I suppose that I will add an
> export option to set whether we are exporting a model or a whole scene
> (see the Global Uniforms section in
> https://sourceforge.net/apps/mediawiki/maya2osg/index.php?title=Shading_Networks#Global_uniforms).

Yes, verry good, that's is on my todo / wishlist as well, exporting 
seperatelly to Geodes or MatrixTransforms.

>    By the way. Talking about adding new shelf buttons... It would be
> really nice if anybody with some artistic skills (that excludes me
> absolutely) offers to create a cool set of icons  :D
>

I know some Artists here, I can ask them, but this will take some time :-)


I added more flags regarding geometry export, in Particular VertexColor 
and VertexAttributes.
Might need some help with the Vertex Attribute export. The Color Sets in 
Maya have names, would be cool if this could be used as program -> 
addBindAttribLocation( "SetName" , location ) ;
but at that time there is no programm, just the VertexAttributes. So I 
can create a Map between the SetNames and the Bind Locations, but where 
and how could we use it ?

Adding new flags is kind of unconfortable, so one suggestion, but would 
need an OK from your site, as this might go quite deep. Check out new 
Thread.

I also tried to align the flagNames in the Script with those in the plugIn.

The Preview Command seems not to work with the default camera "persp", 
or I am doing something wrong. Can you confirm that its working with the 
current UI implementation, and/or your preview procedure in 
maya2osg_preview.mel ?

Btw, would it be possible to get the osgpreview flags work without "" ? 
Like --screen 0 instead of "--screen" 0 ?
Readpreview.cpp but have no clue ...

Cheers, PP

Re: [Maya2osg-users] osgpreview, UI and flags

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

  Hi Peter,

  I found some errors when trying to select the files with custom GLSL
code from the browser:

// Error: Object 'maya2osgUI_vertDeclareFile' not found.
// Error: Object 'maya2osgUI_vertComputeFile' not found.
// Error: Object 'maya2osgUI_fragDeclareFile' not found.
// Error: Object 'maya2osgUI_fragComputeFile' not found.

  I like how is being organized the UI. I think it is much cleaner and
easy to use. Great work!


On Sun, May 29, 2011 at 9:48 PM, Peter Wrobel <pp...@cg...> wrote:
> Hi all,
>
> answering to my own post, as most of the stuff is implemented.
>> I would like to add an optionMenu to the preview command textfield,
>> which changes the behavior of the command field, with these options:
>>
>> Mel:
>> current behaviour
>>
>> Pyth:
>> corresponding Python script
>
> not done, don`t know if required at all, will implement on request.
>
>> Exec:
>> which would take an os command ( like "osgviewer --flags file" ) without
>> the need of "exec" infront of it
>>
>> Flag:
>> this would call osgpreview with flags entered inside the textfield,
>> overriding those hardcoded in the export script
>>
>> Edit: ( maybe )
>> this would pop up a bigger window for editing text, in the case one of
>> the above needs more space
>
> Same as "Pyth"
>
> Javier, you might want to test the behavior of the new options.  Have
> one suggestion to the preview command, that one should be able to pass
> the count of lights as argument. This would enable GL_Lights up to 8 or
> turn off GL_Lighting, if no light is present in the test scen. Silly me,
> was searching quite long for an error, because I couldn't see my content
> in the preview window. But I just had no Lights created. So with passing
> 0 lights to the preview command would eliminte such an issue.

  The scene lighting set and some other issues are on my to-do list.
I'll address it as soon as I have time. I suppose that I will add an
export option to set whether we are exporting a model or a whole scene
(see the Global Uniforms section in
https://sourceforge.net/apps/mediawiki/maya2osg/index.php?title=Shading_Networks#Global_uniforms).

  An additional option would be to include a default lighting set when
previewing. I think that with these two options we solve the lighting
problem.

> For the preview command I'm suggesting one more shelf Button, which does
> the preview based on the settings in the Export Window ( without it
> being opened of course ). The other preview shelf button should still
> have default behavior.
> What do you think ?

  It is OK for me.

  By the way. Talking about adding new shelf buttons... It would be
really nice if anybody with some artistic skills (that excludes me
absolutely) offers to create a cool set of icons  :D

> The preview command an pre/post export mel have annotations that explain
> the usage of Variables, but you need to turn on Maya Options - Interface
> - Help - Popup Help - Tooltips. Think I should activate it when opening
> the UI, and restore window clos. Will do later.

  I can see the tooltips with current version (revision 204).

> The Maya Export All / Selection Options Script has a Bug when cahnging
> the export file type, couldn't fix this, is on todo list.
>
> Polygon Options and Polygon and Export UI Wiki is the next, then,
> finally, skining.

  Great!


-- 
Javier Taibo

Re: [Maya2osg-users] Export notes and custom attributes

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

On Mon, May 30, 2011 at 4:17 AM, Jean-Sébastien Guay
<jea...@cm...> wrote:
> Hi Javier,
>
> Here is my small change so the plugin can export notes and custom
> attributes. It seems to work fine, from the testing I've done.
>
> Next step is to get familiar enough with MEL to be able to make the
> pre-export script I need. That is a lot more work... :-) But at least with
> the attached modification, no changes to the plugin will be required
> (hopefully).

  Great. It seems perfect to me!

  Thanks for the changes. Committed to svn/trunk.


-- 
Javier Taibo

[Maya2osg-users] Export notes and custom attributes

[Jean-Sébastien G. <jea...@cm...>]

Hi Javier,

Here is my small change so the plugin can export notes and custom 
attributes. It seems to work fine, from the testing I've done.

Next step is to get familiar enough with MEL to be able to make the 
pre-export script I need. That is a lot more work... :-) But at least 
with the attached modification, no changes to the plugin will be 
required (hopefully).

Thanks,

J-S
-- 
______________________________________________________
Jean-Sebastien Guay    jea...@cm...
                                http://www.cm-labs.com/
                     http://whitestar02.dyndns-web.com/

Re: [Maya2osg-users] osgpreview, UI and flags

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

Hi all,

answering to my own post, as most of the stuff is implemented.
> I would like to add an optionMenu to the preview command textfield,
> which changes the behavior of the command field, with these options:
>
> Mel:
> current behaviour
>
> Pyth:
> corresponding Python script

not done, don`t know if required at all, will implement on request.

> Exec:
> which would take an os command ( like "osgviewer --flags file" ) without
> the need of "exec" infront of it
>
> Flag:
> this would call osgpreview with flags entered inside the textfield,
> overriding those hardcoded in the export script
>
> Edit: ( maybe )
> this would pop up a bigger window for editing text, in the case one of
> the above needs more space

Same as "Pyth"

Javier, you might want to test the behavior of the new options.  Have 
one suggestion to the preview command, that one should be able to pass 
the count of lights as argument. This would enable GL_Lights up to 8 or 
turn off GL_Lighting, if no light is present in the test scen. Silly me, 
was searching quite long for an error, because I couldn't see my content 
in the preview window. But I just had no Lights created. So with passing 
0 lights to the preview command would eliminte such an issue.

For the preview command I'm suggesting one more shelf Button, which does 
the preview based on the settings in the Export Window ( without it 
being opened of course ). The other preview shelf button should still 
have default behavior.
What do you think ?

The preview command an pre/post export mel have annotations that explain 
the usage of Variables, but you need to turn on Maya Options - Interface 
- Help - Popup Help - Tooltips. Think I should activate it when opening 
the UI, and restore window clos. Will do later.

The Maya Export All / Selection Options Script has a Bug when cahnging 
the export file type, couldn't fix this, is on todo list.

Polygon Options and Polygon and Export UI Wiki is the next, then, 
finally, skining.

Here is my submission coomment, which explains some more.
Export UI Tweaks:
Added Flag to turn on/off overwrite confirm dialog
Added "Browse Path" command to popup menu of filepath
Merged Filename and Filetype into one textField and one optionMenu

created optionMenu for preview mode
  - Off : original preview behavior
  - Mel : evaluates expected an mel command
  - Exec : executes expected system command
  - Flag : overwrites default flags of inbuilt preview command

added Variables $tmp and $cam which are substituted with full temp 
filename and temp camera filename
added annotations explaining behavior when hovering mouse pointer above 
textField ( Maya Option Tooltips must be enabled !!! )

added $full Variable to pre and post export commands and annotation

added "clear" command popup menu to custom GLSL textFields


Cheers, PP

Re: [Maya2osg-users] Discussion of next changes

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

  Hi J-S

On Sun, May 29, 2011 at 5:15 AM, Jean-Sébastien Guay
<jea...@cm...> wrote:
>
> OK, I'll do it the hard way, it doesn't matter that much because it's
> not performance-critical code but I would have throught there was a
> way... It feels like I'm doing a series of dynamic_casts to find out the
> true concrete type of an object...

  It *should* be a way. Maybe it is. But I don't know it.

>>    However, I don't think that exporting all extra attributes is a good
>> idea. There are utilities that generate lots of attributes. I would
>> focus on the attributes defined by the exporter, maybe naming them
>> with a prefix to identify them (tough we can remove the prefix when
>> creating the OSG descriptions).
>
> A prefix is a good idea. I just don't want to have to hard-code
> attribute names in the plugin. But if I export any attribute that starts
> with say "maya2osg_" that would be ok, is that ok for you?

  Perfect!

>>    I don't know if I am understanding you correctly. Is exporting all
>> "Extra attributes" what you are proposing? How do you identify what
>> attributes are "extra attributes", btw?
>
>  From an MFnDependencyNode, I can do:
>
> unsigned int count = dnodefn.attributeCount();
> for (unsigned int i = 0; i < count; ++i)
> {
>     MObject attr = dnodefn.attribute(i);
>     MAttrClass attrClass = dnodefn.attributeClass(attr);
>     if (attrClass == MFnDependencyNode::kLocalDynamicAttr)
>     {
>         // This is a custom attribute (i.e. not part of the normal list
>         // of attributes for this type of node).
>         // Also the notes attribute is one of these.
>     }
> }
>
> So the MFnDependencyNode::MAttrClass enum gives the type of an attribute
> when iterating through all attributes of a node. kLocalDynamicAttr is
> documented as "Dynamically added, applies to this specific node." and I
> verified that when iterating through attributes of a node in a maya
> scene being exported, this was the class returned for custom attributes
> (added by addAttr or the Attributes menu) as well as the notes. Other
> attributes (there were almost 200 on the node I checked) did not have
> this class.

  Interesting. I didn't know that. Quite useful.


  Regards,

-- 
Javier Taibo