Latest Blender Export Script [Wed Aug 25, 2010 - v1.4]
-
- Gnoblar
- Posts: 14
- Joined: Fri Apr 24, 2009 11:05 pm
Relative directory inconsistency
This has no effect if one isn't using relative directories.
The default base directory for relative material and mesh files are different. This can be quite confusing. The defaults depend on what has been done previously, but one way to reproduce is to start up Blender fresh, load up your *.blend file (which file is not in your current directory), then do an Ogre Mesh export, specifying no directory for Materials or Meshes. The files get written to two different directories. It looks like one goes to the current directory that Blender was invoked from (which can be effected by wrapper shell scripts and Windows shortcut properties); the other seems relative to the (last?) loaded *.blend file. Without studying the code, I could be wrong about what the defaults are being derived from, but I am not wrong that the two resultant directories are usually different directories when I export.
The default base directory for relative material and mesh files are different. This can be quite confusing. The defaults depend on what has been done previously, but one way to reproduce is to start up Blender fresh, load up your *.blend file (which file is not in your current directory), then do an Ogre Mesh export, specifying no directory for Materials or Meshes. The files get written to two different directories. It looks like one goes to the current directory that Blender was invoked from (which can be effected by wrapper shell scripts and Windows shortcut properties); the other seems relative to the (last?) loaded *.blend file. Without studying the code, I could be wrong about what the defaults are being derived from, but I am not wrong that the two resultant directories are usually different directories when I export.
- lf3thn4d
- Orc
- Posts: 478
- Joined: Mon Apr 10, 2006 9:12 pm
- x 12
Re: Latest Blender Export Script [Tue Mar 24, 2009 - v1.2]
Thanks, i've fixed it. But I won't be doing a release for such a small minor bug yet. SVN version now made mesh export to blender file path just as material is.
-
- Gnoblar
- Posts: 14
- Joined: Fri Apr 24, 2009 11:05 pm
Re: Latest Blender Export Script [Tue Mar 24, 2009 - v1.2]
Thanks very much!lf3thn4d wrote:Thanks, i've fixed it. But I won't be doing a release for such a small minor bug yet. SVN version now made mesh export to blender file path just as material is.
Since that went so well... I think that the axis fixup toggle should default to on. I know that you aren't responsible for accommodating the dotScene exporter, but it would be nice for users if the two products used the same default; and as the primary use of both products is for exporting from a Blender Z-up world to an Ogre Z-forward world, it seems to me this should be the default behavior.
- lf3thn4d
- Orc
- Posts: 478
- Joined: Mon Apr 10, 2006 9:12 pm
- x 12
Re: Latest Blender Export Script [Tue Mar 24, 2009 - v1.2]
Ok. Sounds good. Since that's what the majority are using. It was originally off due to me following the old behavior of the exporter. Done and committed.
-
- Gnoblar
- Posts: 14
- Joined: Fri Apr 24, 2009 11:05 pm
conditional materials
I give up on the conditional material toggle patch for now.
The implementation was straight-forward until I got into getMaterial() and the SubmeshManager. SubmeshManager keys the submeshes on Materials. Poor design IMO, to assign faces based on materials, when Blender already has good methods in place to map faces to meshes and sub-mesh groupings. It's antipathetic to the long-appreciated 3D concept of material sharing and adds an artificial (and from my perspective problematic) dependency between the otherwise nicely encapsulated domains of submeshes and materials.
I was going to change the SubmeshManager to key the submeshList map/hash on something else, but the getMaterial method (whose scope is well beyond getting materials) is interposed into the process in such a way that everything in the export process depends on materials.
UPDATE: I think that an acceptable compromise may be to not change what is written at all, but to just just prevent the display of the error messages if the toggle is set to not require materials. What happens is, an empty BasicWhite material gets written, but it's easy enough to recognize empty material records on the other (export-reading) side. Does this approach sound ok to you? Pretty safe since it only involves the display of messages.
The implementation was straight-forward until I got into getMaterial() and the SubmeshManager. SubmeshManager keys the submeshes on Materials. Poor design IMO, to assign faces based on materials, when Blender already has good methods in place to map faces to meshes and sub-mesh groupings. It's antipathetic to the long-appreciated 3D concept of material sharing and adds an artificial (and from my perspective problematic) dependency between the otherwise nicely encapsulated domains of submeshes and materials.
I was going to change the SubmeshManager to key the submeshList map/hash on something else, but the getMaterial method (whose scope is well beyond getting materials) is interposed into the process in such a way that everything in the export process depends on materials.
UPDATE: I think that an acceptable compromise may be to not change what is written at all, but to just just prevent the display of the error messages if the toggle is set to not require materials. What happens is, an empty BasicWhite material gets written, but it's easy enough to recognize empty material records on the other (export-reading) side. Does this approach sound ok to you? Pretty safe since it only involves the display of messages.
- lf3thn4d
- Orc
- Posts: 478
- Joined: Mon Apr 10, 2006 9:12 pm
- x 12
Re: Latest Blender Export Script [Tue Mar 24, 2009 - v1.2]
Hmm.. i think that should be acceptable. I do agree that the current way of matching material and submesh sucks. Not surprised though since it was designed around the idea of grouping vertices/triangles by material (trying to optimize for Ogre's mesh system). The current design also prevents submesh name assignment which kinda sucks if one actually need them in their app.
I suggest we leave this for version 2 of the exporter when Blender release their new UI/Python system. From there, we shall redesign the whole thing and make sure it has more room for improvement.
I suggest we leave this for version 2 of the exporter when Blender release their new UI/Python system. From there, we shall redesign the whole thing and make sure it has more room for improvement.
-
- Gnoblar
- Posts: 14
- Joined: Fri Apr 24, 2009 11:05 pm
Re: Latest Blender Export Script [Tue Mar 24, 2009 - v1.2]
Did you change your mind half way through your reply, or do you mean that the interim tactic is acceptable, leaving a fix to accommodate the other limitations for v2? If the interim work-around is ok, I should make up a patch for that, right?lf3thn4d wrote:Hmm.. i think that should be acceptable....I suggest we leave this for version 2 of the exporter when Blender release their new UI/Python system. From there, we shall redesign the whole thing and make sure it has more room for improvement.
- lf3thn4d
- Orc
- Posts: 478
- Joined: Mon Apr 10, 2006 9:12 pm
- x 12
Re: Latest Blender Export Script [Tue Mar 24, 2009 - v1.2]
I meant that the interim tactic of just preventing the error is acceptable. Or if possible, just make it only warn once for each submesh instead of the current annoying each triangle warning. Obviously, like you said, the current design of material <-> submesh matching isn't very nice. Thus I suggested that if we were to refactor this, lets do it after the next major blender release with their new python interface. Since by then, no doubt everything will need to be ported over or completely rewritten from scratch.
So, yes, patch is welcome.
Sorry for the confusion.
So, yes, patch is welcome.
Sorry for the confusion.
-
- Gnoblar
- Posts: 14
- Joined: Fri Apr 24, 2009 11:05 pm
Re: Latest Blender Export Script [Tue Mar 24, 2009 - v1.2]
Those are red error messages, not yellow warnings.lf3thn4d wrote:I meant that the interim tactic of just preventing the error is acceptable. Or if possible, just make it only warn once for each submesh instead of the current annoying each triangle warning....
My primary goal for the interim fix, per earlier conversation, is to add a "Require Mateirals" toggle button, defaulting to True. The only behavior change would be, if user toggled it off, none of those error messages would be issued. While I'm in there, I should be able to maintain a [s]global[/s] variable of the necessary scope to prevent the flood of error messages for default (Require Materials) users, as you suggest.
- lf3thn4d
- Orc
- Posts: 478
- Joined: Mon Apr 10, 2006 9:12 pm
- x 12
Re: Latest Blender Export Script [Tue Mar 24, 2009 - v1.2]
Yes, sorry about that. It was an annoying error message, not warnings. Though the meshes still gets generated after which kinda doesn't really make sense there anyways. It should be a single warning instead of spammed error messages. The "Require Mateirals" option sounds good. Just make sure to have a good call tip to explain what it does.
-
- Gnoblar
- Posts: 14
- Joined: Fri Apr 24, 2009 11:05 pm
Re: Latest Blender Export Script [Tue Mar 24, 2009 - v1.2]
Yes, except, with the "Require Materials" setting in place, I think a single (or probably one per mesh) error message is more appropriate. If I explicitly require materials, I would expect more than a warning message, which could be missed, esp. if the export happens to generate unrelated warnings too.lf3thn4d wrote:Yes, sorry about that. It was an annoying error message, not warnings. Though the meshes still gets generated after which kinda doesn't really make sense there anyways. It should be a single warning instead of spammed error messages. The "Require Mateirals" option sounds good. Just make sure to have a good call tip to explain what it does.
-
- Gnoblar
- Posts: 14
- Joined: Fri Apr 24, 2009 11:05 pm
Re: Latest Blender Export Script [Tue Mar 24, 2009 - v1.2]
I believe you, but I don't quite understand how this design works. Seems that if I have the same color skin on my arms and legs, with this design all four members would be assigned to the same submesh and animate in sync, whereas they need to animate out-of-phase and be rooted to different joints.lf3thn4d wrote:Hmm.. i think that should be acceptable. I do agree that the current way of matching material and submesh sucks. Not surprised though since it was designed around the idea of grouping vertices/triangles by material (trying to optimize for Ogre's mesh system)...
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: Latest Blender Export Script [Tue Mar 24, 2009 - v1.2]
SubEntities and SubMeshes in Ogre are not what you think they are?Meshes which make up the definition of a discrete 3D object are made up of potentially multiple parts. This is because different parts of the mesh may use different materials or use different vertex formats, such that a rendering state change is required between them.
Mesh and Entity are discrete objects. They can have one or several submeshes/subentities, depending on materials/render state changes.
If you want to have discrete entities within a skeleton, you need to create separate objects and make them share a skeleton.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- Gnoblar
- Posts: 14
- Joined: Fri Apr 24, 2009 11:05 pm
Re: Latest Blender Export Script [Tue Mar 24, 2009 - v1.2]
Ah. Thanks. I definitely need to understand that for upcoming work I have to do.jacmoe wrote:Meshes which make up the definition of a discrete 3D object are made up of potentially multiple parts...
-
- Gnoblar
- Posts: 14
- Joined: Fri Apr 24, 2009 11:05 pm
Re: Latest Blender Export Script [Tue Mar 24, 2009 - v1.2]
Unfortunately, this is different from the default for where the scene.xml file gets written to. I will have to look at the scene exporter code, because I can't figure out where it's getting its default from. It is not taken from the last loaded .blend file, current directory, last place exported to, nor even what was last keyed into the "Path: field.lf3thn4d wrote:Thanks, i've fixed it. But I won't be doing a release for such a small minor bug yet. SVN version now made mesh export to blender file path just as material is.
-
- Gnoblar
- Posts: 14
- Joined: Fri Apr 24, 2009 11:05 pm
Re: Latest Blender Export Script [Tue Mar 24, 2009 - v1.2]
Done. Patch ID 2786339. Based on our discussion here, I've assigned it to you (Hern).blaine wrote:Yes, except, with the "Require Materials" setting in place, I think a single (or probably one per mesh) error message is more appropriate. If I explicitly require materials, I would expect more than a warning message, which could be missed, esp. if the export happens to generate unrelated warnings too.lf3thn4d wrote:Yes, sorry about that. It was an annoying error message, not warnings. Though the meshes still gets generated after which kinda doesn't really make sense there anyways. It should be a single warning instead of spammed error messages. The "Require Mateirals" option sounds good. Just make sure to have a good call tip to explain what it does.
Last edited by blaine on Mon May 04, 2009 1:24 am, edited 1 time in total.
-
- Gnoblar
- Posts: 14
- Joined: Fri Apr 24, 2009 11:05 pm
Re: Latest Blender Export Script [Tue Mar 24, 2009 - v1.2]
It is still off by default in svn HEAD. Please fix.lf3thn4d wrote:Ok. Sounds good. Since that's what the majority are using. It was originally off due to me following the old behavior of the exporter. Done and committed.
- lf3thn4d
- Orc
- Posts: 478
- Joined: Mon Apr 10, 2006 9:12 pm
- x 12
Re: Latest Blender Export Script [Tue Mar 24, 2009 - v1.2]
Ok. Got the patch. Will look at it soon.
The fixes are commited into the v1-6 branch since it doesn't break compatibility and that is the stable branch. It will be merged back to HEAD soon. So please use the v1-6 branch for latest exporter as stated in the wiki: http://www.ogre3d.org/wiki/index.php/Blender_Exporter
The fixes are commited into the v1-6 branch since it doesn't break compatibility and that is the stable branch. It will be merged back to HEAD soon. So please use the v1-6 branch for latest exporter as stated in the wiki: http://www.ogre3d.org/wiki/index.php/Blender_Exporter
- xadhoom
- Minaton
- Posts: 973
- Joined: Fri Dec 28, 2007 4:35 pm
- Location: Germany
- x 1
Re: Latest Blender Export Script [Tue Mar 24, 2009 - v1.2]
Its now in trunk
xad
xad
- lf3thn4d
- Orc
- Posts: 478
- Joined: Mon Apr 10, 2006 9:12 pm
- x 12
Re: Latest Blender Export Script [Tue Mar 24, 2009 - v1.2]
I've commited the patch. While at it, I fixed the missing code for loading the new setting. Thanks for the patch blaine.
-
- Gnoblar
- Posts: 13
- Joined: Fri Apr 24, 2009 12:49 pm
Re: Latest Blender Export Script [Tue Mar 24, 2009 - v1.2]
Why the Blender Export Script doesn't export only the bones I'm using in my Blender animation?
Imagine you have a face (skeletal animation: eyesBones, mouthBones...), If you only want to export eyes animations (it only involves eyesBones ), you only have in your Blender Action Menu those bones, why exporting whole the skeleton?
It would be interesting get separately animation of the same skeleton to blend them at the same time:
But now what you get it's a mixed new animation. And If you try to destroy or adjust bone weigth you are affecting to all the animations...
So, I doubt if that functionality is difficult to implement or it cannot be (Ogre definitions) ¿?
Imagine you have a face (skeletal animation: eyesBones, mouthBones...), If you only want to export eyes animations (it only involves eyesBones ), you only have in your Blender Action Menu those bones, why exporting whole the skeleton?
It would be interesting get separately animation of the same skeleton to blend them at the same time:
Code: Select all
mEntity->getAnimationState("Eyes")->addTime(evt.timeSinceLastFrame);
mEntity->getAnimationState("Mouth")->addTime(evt.timeSinceLastFrame);
So, I doubt if that functionality is difficult to implement or it cannot be (Ogre definitions) ¿?
-
- Orc
- Posts: 424
- Joined: Wed Aug 01, 2007 8:13 pm
- Location: Venice, CA, USA
- x 7
Re: Latest Blender Export Script [Tue Mar 24, 2009 - v1.2]
Hi,
I just modified the MeshExporter::_write (which calls OgreXMLConverter::convert) function so that it specifies a separate log file for each mesh being converted. This was useful to me as I'm using the MeshExporter in my scene exporter and wanted to see the log for each mesh, not just the last mesh converted. I could see it being useful to the standard Ogre exporter when multiple meshes are in the export list. Would you like the changes? They are quite simple. Thanks for the great exporter.
I just modified the MeshExporter::_write (which calls OgreXMLConverter::convert) function so that it specifies a separate log file for each mesh being converted. This was useful to me as I'm using the MeshExporter in my scene exporter and wanted to see the log for each mesh, not just the last mesh converted. I could see it being useful to the standard Ogre exporter when multiple meshes are in the export list. Would you like the changes? They are quite simple. Thanks for the great exporter.
- lf3thn4d
- Orc
- Posts: 478
- Joined: Mon Apr 10, 2006 9:12 pm
- x 12
Re: Latest Blender Export Script [Tue Mar 24, 2009 - v1.2]
@Chumpocomon: That's a very interesting question. Personally, I've no clue yet. Maybe we can have yet another toggle option to specify only export keyed bones. I'm sure Ogre side provides for such feature. One thing you have to understand is that skeleton animation export is done by baking the samples frame by frame. This is designed such that one can use IK in their animation without worries. But I do understand that this part of the export isn't very complete. Personally, I wished for smarter techniques like frame compressions to cut down unnecessary key frames.
@cyrfer: I think that's a very good change. Send me patch
@cyrfer: I think that's a very good change. Send me patch
- sparkprime
- Ogre Magi
- Posts: 1137
- Joined: Mon May 07, 2007 3:43 am
- Location: Ossining, New York
- x 13
- Contact:
Re: Latest Blender Export Script [Tue Mar 24, 2009 - v1.2]
With blender 2.48a I get the following trace:
After the first export. This then seems to corrupt the .blend file since no conversions work after this.
Any ideas?
Code: Select all
Compiled with Python version 2.6.2.
Checking for installed Python... got it!
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/spark/.blender/scripts/ogremeshesexporter.py", line 238, in <module>
PackageSettings.getSingleton().load()
File "/home/spark/.blender/scripts/ogrepkg/base.py", line 251, in load
self.dict = pickle.loads(string.join(settingsText.asLines()[4:],'\n'))
File "/usr/lib/python2.6/pickle.py", line 1374, in loads
return Unpickler(file).load()
File "/usr/lib/python2.6/pickle.py", line 858, in load
dispatch[key](self)
File "/usr/lib/python2.6/pickle.py", line 971, in load_string
self.append(rep.decode("string-escape"))
File "/usr/lib/python2.6/encodings/__init__.py", line 100, in search_function
level=0)
TypeError: blimport() takes no keyword arguments
Any ideas?
- lf3thn4d
- Orc
- Posts: 478
- Joined: Mon Apr 10, 2006 9:12 pm
- x 12
Re: Latest Blender Export Script [Tue Mar 24, 2009 - v1.2]
This problem is mentioned 2 page before this: http://www.ogre3d.org/forums/viewtopic. ... 64#p336764
Seems like the new python 2.6 didn't like the exporter script. I'm not quite sure why though. I searched through the 2.6 API but didn't seem to find anything wrong with the pickle usage. I'm using a 2.5.2 build so I can't help there.
Seems like the new python 2.6 didn't like the exporter script. I'm not quite sure why though. I searched through the 2.6 API but didn't seem to find anything wrong with the pickle usage. I'm using a 2.5.2 build so I can't help there.