As for Mudbox, I am teaching myself all the different aspects of 3d to see what I like best, and I have a lot of ideas surrounding these assets, such as turning them into parts for makehuman, setup a uma system for unity, and just various other ideas.
I would also like an all quad topology to use the base design to showcase the assets, and allow for easy later use in animation projects I, or others might consider.
This is just a small list, but basically I am using these to learn the different approaches to piplines, and looking for pain points, of which there are many.
EDITED: Fixed spelling errors and gramatical mistakes.
Well, no, that was ONE of the issues. There were in fact many.
1) The original files had a custom built "Nel Material" applied to them, that would prevent transport rom 3ds Max, and indeed prevented use of these assets in anything later than 3ds Max 2012 as the plugins could not be compiled for later versions of Max without a major porting effort due to some fundamental Unicode changes in Max.
I have replaced all of the original Nel Materials with the Default Material in Max, which means that the Max files can be used with the latest versions of 3ds Max.
2) The iqe format does not have importers and exporters for many pipelines.
Fbx is supported in most 3d DCCs, including Blender, albeit that support is maturing quickly.
3) Iqe is not supported in Max, meaning that some data from the original files could be lost.
Using a format supported both by Max and Blender means the least possible loss of information between conversion, making these files more suitable to reimport into the Ryzom core once a Blender plugin is created.
4) The animations are in fact fully attached in the fbx files, after all, fbx started out as a way to transport animation from Motionbuilder to many different DCC applications.
Therefore, that requirement is met. It is true that Blender is still working on implementing all the features of FBX, but that support is only ging to get better. (As an example, Blender cannot currently read the ASCII version of FBX, even though you would think that would be easier.)
5) Fbx allows for importing into Mudbox, which was my original use case for these assets. I have linked to my efforts here mainly due to an effort of wanting to share my efforts.
However, some of the geometry in these files is non manifold, preventing their use in Mudbox or Zbrush without editing. These may cause issues in other game engines as well, as they are generally more taxing for the GPU to process.
6) I provided the . objs as a way to test the fbx imports to ensure that blender was importing the model correctly. Also, obj are ASCII files, which should be easier for Github to work with.
7) Fbx is the main format for Unity, and Unreal Engine, which are my main game engines of choice. Both support Substance materials, of which I am working to learn. So this is the most practical solution for my needs.
And, of course I am required to release the changes I have made, so this is my way of doing so.
I figured the images would be the least chinging of the set, and can be shared for those that wish to use them with the original files, witch are also uploaded on my repository.
I have done no organization or cleanup at this time, that is my next step. Also, I looked into creating .blend files, but haven't the experience with blender to wade through the best way to batch that.
I would ignore any of the obj in directories titled anim, as they will most likely be duplicates of other meshes.
Sorry, I sometimes have teeth.
As for Mudbox, I am teaching myself all the different aspects of 3d to see what I like best, and I have a lot of ideas surrounding these assets, such as turning them into parts for makehuman, setup a uma system for unity, and just various other ideas.
I would also like an all quad topology to use the base design to showcase the assets, and allow for easy later use in animation projects I, or others might consider.
This is just a small list, but basically I am using these to learn the different approaches to piplines, and looking for pain points, of which there are many.
EDITED: Fixed spelling errors and gramatical mistakes.
Well, no, that was ONE of the issues. There were in fact many.
1) The original files had a custom built "Nel Material" applied to them, that would prevent transport rom 3ds Max, and indeed prevented use of these assets in anything later than 3ds Max 2012 as the plugins could not be compiled for later versions of Max without a major porting effort due to some fundamental Unicode changes in Max.
I have replaced all of the original Nel Materials with the Default Material in Max, which means that the Max files can be used with the latest versions of 3ds Max.
2) The iqe format does not have importers and exporters for many pipelines.
Fbx is supported in most 3d DCCs, including Blender, albeit that support is maturing quickly.
3) Iqe is not supported in Max, meaning that some data from the original files could be lost.
Using a format supported both by Max and Blender means the least possible loss of information between conversion, making these files more suitable to reimport into the Ryzom core once a Blender plugin is created.
4) The animations are in fact fully attached in the fbx files, after all, fbx started out as a way to transport animation from Motionbuilder to many different DCC applications.
Therefore, that requirement is met. It is true that Blender is still working on implementing all the features of FBX, but that support is only ging to get better. (As an example, Blender cannot currently read the ASCII version of FBX, even though you would think that would be easier.)
5) Fbx allows for importing into Mudbox, which was my original use case for these assets. I have linked to my efforts here mainly due to an effort of wanting to share my efforts.
However, some of the geometry in these files is non manifold, preventing their use in Mudbox or Zbrush without editing. These may cause issues in other game engines as well, as they are generally more taxing for the GPU to process.
6) I provided the . objs as a way to test the fbx imports to ensure that blender was importing the model correctly. Also, obj are ASCII files, which should be easier for Github to work with.
7) Fbx is the main format for Unity, and Unreal Engine, which are my main game engines of choice. Both support Substance materials, of which I am working to learn. So this is the most practical solution for my needs.
And, of course I am required to release the changes I have made, so this is my way of doing so.
I have converted the 3ds max files to fbx. Then I converted those to obj. I have uploaded them onto github here.
https://github.com/NDxTreme/Open3D-Models
I have uploaded the textures here.
https://github.com/NDxTreme/Base-Ryzom
I figured the images would be the least chinging of the set, and can be shared for those that wish to use them with the original files, witch are also uploaded on my repository.
I have done no organization or cleanup at this time, that is my next step. Also, I looked into creating .blend files, but haven't the experience with blender to wade through the best way to batch that.
I would ignore any of the obj in directories titled anim, as they will most likely be duplicates of other meshes.
Hopefully this is useful to someone.