new ASE Exporter

Mordenkainen · **Posted:** Fri Jul 27, 2007 7:19 pm

ratty redemption wrote:

mordenkainen, if you split the model in say 4 sections, does it take a quarter of the time to export one section? this is something I've been wondering about with some of my tests. there seems to be a threshold (could be ram related?) although I'm not sure yet what the verts/poly count threshold is yet, and whether it is a restriction of our systems or blender and goofos's .script

The same model at 30K takes around 5 mins. At 130K it takes 2 hours. Didn't experiment splitting it though.

Goofos: Thanks, dinner first but I'll try it and then report back.

Mordenkainen · **Posted:** Fri Jul 27, 2007 8:54 pm

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

ratty redemption · **Posted:** Fri Jul 27, 2007 8:57 pm

cool, I'll test this later tonight, and thanks mordenkainen for ul the file. that is easier then copy/paste the script from the forum here.

Goofos · **Posted:** Sat Jul 28, 2007 2:04 pm

Mordenkainen wrote:

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

(BTW quickly added support for multiple uv layers :> )

Please test the updated v0.6.9 script if uv and vcolor is exported right.

Mordenkainen · **Posted:** Sat Jul 28, 2007 10:32 pm

Goofos wrote:

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

130K poly version now takes 13 minutes. Export worked nicely. Great job man.

EDIT: 0.6.9 version uploaded here.

Goofos · **Posted:** Sun Jul 29, 2007 10:16 am

13 min? Hrmz, i have no idea where else i could search for lame code in the script.

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

If you track the progressbar, when does the script completely hang for a good while?

Mordenkainen · **Posted:** Mon Jul 30, 2007 8:24 pm

Goofos wrote:

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

Yeah. Do you want me to upload my model somewhere so you can see if there's anything wrong with it?

Quote:

If you track the progressbar, when does the script completely hang for a good while?

Most of the time is spent during "Writing Faces".

ratty redemption · **Posted:** Tue Jul 31, 2007 1:26 pm

goofos, sorry I didn't get to back to you earlier on this but I have just exported a high poly mesh a few times with uv's and vertex color, heres the console report.

Code:

Verts: 263169 Tris: 524288 Faces: 262144
Successfully exported temp.ase in 146.48 seconds 

which I think is truly amazing how much you've optimized your code

Mordenkainen · **Posted:** Wed Aug 01, 2007 4:08 pm

Mordenkainen wrote:

I precompiled the Python API during its installation it but Blender's own python scripts (including this exporter) aren't precompiled. Anyway I can precompile these too?

Yep, answering myself.

After some persistant searching I've found a way to precompile Blender's Python scripts too. I haven't experienced any noticeable perf increase but if you want to try it paste the following to Blender's Script editor and execute. Replace the path file with the one you installed Blender to, obviously:

Code:

import compileall

compileall.compile_dir('C:\Programs\Blender\.blender\scripts', force=True)

hyp3rfocus · **Joined:** Sun Jul 29, 2007 10:13 pm **Posts:** 7

edit- post deleted.

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

I have identified the cause of the mesh's coordinates being written relative to the world origin rather than the mesh object's own origin:

Code:

      me = Mesh.New()      # Create a new mesh

      if guiTable['MOD'] == 1:   # Use modified mesh
         me.getFromObject(obj.name, 0) # Get the object's mesh data, cage 0 = apply mod
      else:
         me.getFromObject(obj.name, 1)

      me.transform(obj.matrix)   #ASE stores transformed mesh data
      tempObj = Blender.Object.New('Mesh', 'ASE_export_temp_obj')
      tempObj.setMatrix(obj.matrix)
      tempObj.link(me)

What I assume this is doing (not being a Blender Python expert myself) is creating a new mesh object, copying the mesh data from the selected mesh into this new object, and then setting the new object to have the same transformation as the previous object (basically a deep copy of the mesh being exported).

The problem is the line me.transform(obj.matrix) which (I assume) applies the transformation of the object to the mesh data itself -- however, this transformation would include the location as well as the rotation and scale parameters, essentially applying the object's translation value to the contained mesh data, which is not what is needed when exporting a single object.

I assume that the purpose of this line is to avoid the user having to use Ctrl-A to apply size/rotation before exporting? Personally I would prefer to have to do this manually rather than having the translation applied to the mesh as well.

kat · **Posted:** Mon Aug 27, 2007 12:06 pm

I just re-read the problem you were having, am I right in assuming that you're basically centring the objects origin and then trying to export the mesh when it's not centred on the 000 grid origin? (so the objects centre is relative to where the object is on the grid?)

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

Yes -- the object's own centre point is correct, but is not aligned with the world center (0, 0, 0). With the script as written, the exported object's centre point is aligned with the world origin (0, 0, 0) and ignores the object's own centre point. With the problematic line commented out, it works as expected.

kat · **Posted:** Tue Aug 28, 2007 12:26 pm

I wonder if this could be added as an export option? Being able to export objects inplace (but with correctly recentred POO's) would be handy when building levels; it's pain in the arse to keep having to pull everything to the grid centre making sure you don't screw up the position of each section, an option to export in place would mean not having to do any of that *looks at Goofos with a Spock like raised eyebrow in question*

Goofos · **Posted:** Wed Aug 29, 2007 12:44 am

OrbWeaver wrote:

me.transform(obj.matrix) which (I assume) applies the transformation of the object to the mesh data itself -- however, this transformation would include the location as well as the rotation and scale parameters, essentially applying the object's translation value to the contained mesh data, which is not what is needed when exporting a single object.

Yes, it applies loc/rot/scale to the mesh data. In earlier script versions this was an optional option. Later i discovered that the mesh data is transformed in ASE files but the object still has the loc/rot/scale informations.

If you comment that line out, it basically use the local mesh data without loc/rot/scale but it still write the transformation infos to the ase file and would have a negative transformation when importing the ase file in apps which care about loc/rot/scale. I think usually you would need to change some more lines in the script so it don't export the original transform infos. But i'm currently unsure which lines (at least some lines in def mesh_matrix).

kat wrote:

I wonder if this could be added as an export option? Being able to export objects inplace (but with correctly recentred POO's) would be handy when building levels; it's pain in the arse to keep having to pull everything to the grid centre making sure you don't screw up the position of each section, an option to export in place would mean not having to do any of that *looks at Goofos with a Spock like raised eyebrow in question*

I think i don't got it. :> You mean export each object moved to world origin, or export each object with its origin moved to the world origin?

kat · **Posted:** Wed Aug 29, 2007 1:30 am

Goofos wrote:

...I think i don't got it. :> You mean export each object moved to world origin, or export each object with its origin moved to the world origin?

Soory Goofos.. what I mean was this... say you design a level (as I've been doing) and in order to export it and make it efficient with the engine it has to be cut up into segments. Normally each of these segments needs both the mesh and the segments centre to bo placed over the 000 grid point, that means each piece has to be moved which runs the risk of messing up the alignment with other segments.

What would be ideal is if you could correctly position the segments centre where it was originally and have the mesh export from there - unless I'm missing something in the new code the mesh gets exported with the polygons positioned where they were but the objects centre in then placed at 000, is that right? What you'd want on a big mesh cut into many segments is to leave them where they are and just repostion the origin locally and export like that.

Does that make sense?

sparhawk · **Joined:** Wed Sep 08, 2004 7:48 am **Posts:** 556

Not sure if I understand it correctly, but an option that could specify wether you want the object to be exported as residing a 0,0,0 or stay where it is would be very usefull.

Normally, I would like my objects to be at the centerpoint. When I model, then I often enough break them up into individual models and align them properly. In this case the models should stay relativ to where they are, because otherwise they would end up all at the centerpoint instead of making a bigger model.

In some cases I model stuff together in one file, which are still individual usable models though. Of course I can use different layers, but there is a limit to that, so I often enough move them out of the way. In such a case it would be usefull to export all the models as centerpoint models. This could be simply a toggle on the export dialog, which adjusts the matrix accordingly.

Mordenkainen · **Posted:** Fri Jul 27, 2007 7:19 pm

ratty redemption wrote:

mordenkainen, if you split the model in say 4 sections, does it take a quarter of the time to export one section? this is something I've been wondering about with some of my tests. there seems to be a threshold (could be ram related?) although I'm not sure yet what the verts/poly count threshold is yet, and whether it is a restriction of our systems or blender and goofos's .script

The same model at 30K takes around 5 mins. At 130K it takes 2 hours. Didn't experiment splitting it though.

Goofos: Thanks, dinner first but I'll try it and then report back.

Mordenkainen · **Posted:** Fri Jul 27, 2007 8:54 pm

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

ratty redemption · **Posted:** Fri Jul 27, 2007 8:57 pm

cool, I'll test this later tonight, and thanks mordenkainen for ul the file. that is easier then copy/paste the script from the forum here.

Goofos · **Posted:** Sat Jul 28, 2007 2:04 pm

Mordenkainen wrote:

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

(BTW quickly added support for multiple uv layers :> )

Please test the updated v0.6.9 script if uv and vcolor is exported right.

Mordenkainen · **Posted:** Sat Jul 28, 2007 10:32 pm

Goofos wrote:

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

130K poly version now takes 13 minutes. Export worked nicely. Great job man.

EDIT: 0.6.9 version uploaded here.

Goofos · **Posted:** Sun Jul 29, 2007 10:16 am

13 min? Hrmz, i have no idea where else i could search for lame code in the script.

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

If you track the progressbar, when does the script completely hang for a good while?

Mordenkainen · **Posted:** Mon Jul 30, 2007 8:24 pm

Goofos wrote:

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

Yeah. Do you want me to upload my model somewhere so you can see if there's anything wrong with it?

Quote:

If you track the progressbar, when does the script completely hang for a good while?

Most of the time is spent during "Writing Faces".

ratty redemption · **Posted:** Tue Jul 31, 2007 1:26 pm

goofos, sorry I didn't get to back to you earlier on this but I have just exported a high poly mesh a few times with uv's and vertex color, heres the console report.

Code:

Verts: 263169 Tris: 524288 Faces: 262144
Successfully exported temp.ase in 146.48 seconds 

which I think is truly amazing how much you've optimized your code

Mordenkainen · **Posted:** Wed Aug 01, 2007 4:08 pm

Mordenkainen wrote:

I precompiled the Python API during its installation it but Blender's own python scripts (including this exporter) aren't precompiled. Anyway I can precompile these too?

Yep, answering myself.

After some persistant searching I've found a way to precompile Blender's Python scripts too. I haven't experienced any noticeable perf increase but if you want to try it paste the following to Blender's Script editor and execute. Replace the path file with the one you installed Blender to, obviously:

Code:

import compileall

compileall.compile_dir('C:\Programs\Blender\.blender\scripts', force=True)

hyp3rfocus · **Joined:** Sun Jul 29, 2007 10:13 pm **Posts:** 7

edit- post deleted.

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

I have identified the cause of the mesh's coordinates being written relative to the world origin rather than the mesh object's own origin:

Code:

      me = Mesh.New()      # Create a new mesh

      if guiTable['MOD'] == 1:   # Use modified mesh
         me.getFromObject(obj.name, 0) # Get the object's mesh data, cage 0 = apply mod
      else:
         me.getFromObject(obj.name, 1)

      me.transform(obj.matrix)   #ASE stores transformed mesh data
      tempObj = Blender.Object.New('Mesh', 'ASE_export_temp_obj')
      tempObj.setMatrix(obj.matrix)
      tempObj.link(me)

What I assume this is doing (not being a Blender Python expert myself) is creating a new mesh object, copying the mesh data from the selected mesh into this new object, and then setting the new object to have the same transformation as the previous object (basically a deep copy of the mesh being exported).

The problem is the line me.transform(obj.matrix) which (I assume) applies the transformation of the object to the mesh data itself -- however, this transformation would include the location as well as the rotation and scale parameters, essentially applying the object's translation value to the contained mesh data, which is not what is needed when exporting a single object.

I assume that the purpose of this line is to avoid the user having to use Ctrl-A to apply size/rotation before exporting? Personally I would prefer to have to do this manually rather than having the translation applied to the mesh as well.

kat · **Posted:** Mon Aug 27, 2007 12:06 pm

I just re-read the problem you were having, am I right in assuming that you're basically centring the objects origin and then trying to export the mesh when it's not centred on the 000 grid origin? (so the objects centre is relative to where the object is on the grid?)

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

Yes -- the object's own centre point is correct, but is not aligned with the world center (0, 0, 0). With the script as written, the exported object's centre point is aligned with the world origin (0, 0, 0) and ignores the object's own centre point. With the problematic line commented out, it works as expected.

kat · **Posted:** Tue Aug 28, 2007 12:26 pm

I wonder if this could be added as an export option? Being able to export objects inplace (but with correctly recentred POO's) would be handy when building levels; it's pain in the arse to keep having to pull everything to the grid centre making sure you don't screw up the position of each section, an option to export in place would mean not having to do any of that *looks at Goofos with a Spock like raised eyebrow in question*

Goofos · **Posted:** Wed Aug 29, 2007 12:44 am

OrbWeaver wrote:

me.transform(obj.matrix) which (I assume) applies the transformation of the object to the mesh data itself -- however, this transformation would include the location as well as the rotation and scale parameters, essentially applying the object's translation value to the contained mesh data, which is not what is needed when exporting a single object.

Yes, it applies loc/rot/scale to the mesh data. In earlier script versions this was an optional option. Later i discovered that the mesh data is transformed in ASE files but the object still has the loc/rot/scale informations.

If you comment that line out, it basically use the local mesh data without loc/rot/scale but it still write the transformation infos to the ase file and would have a negative transformation when importing the ase file in apps which care about loc/rot/scale. I think usually you would need to change some more lines in the script so it don't export the original transform infos. But i'm currently unsure which lines (at least some lines in def mesh_matrix).

kat wrote:

I wonder if this could be added as an export option? Being able to export objects inplace (but with correctly recentred POO's) would be handy when building levels; it's pain in the arse to keep having to pull everything to the grid centre making sure you don't screw up the position of each section, an option to export in place would mean not having to do any of that *looks at Goofos with a Spock like raised eyebrow in question*

I think i don't got it. :> You mean export each object moved to world origin, or export each object with its origin moved to the world origin?

kat · **Posted:** Wed Aug 29, 2007 1:30 am

Goofos wrote:

...I think i don't got it. :> You mean export each object moved to world origin, or export each object with its origin moved to the world origin?

Soory Goofos.. what I mean was this... say you design a level (as I've been doing) and in order to export it and make it efficient with the engine it has to be cut up into segments. Normally each of these segments needs both the mesh and the segments centre to bo placed over the 000 grid point, that means each piece has to be moved which runs the risk of messing up the alignment with other segments.

What would be ideal is if you could correctly position the segments centre where it was originally and have the mesh export from there - unless I'm missing something in the new code the mesh gets exported with the polygons positioned where they were but the objects centre in then placed at 000, is that right? What you'd want on a big mesh cut into many segments is to leave them where they are and just repostion the origin locally and export like that.

Does that make sense?

sparhawk · **Joined:** Wed Sep 08, 2004 7:48 am **Posts:** 554

Not sure if I understand it correctly, but an option that could specify wether you want the object to be exported as residing a 0,0,0 or stay where it is would be very usefull.

Normally, I would like my objects to be at the centerpoint. When I model, then I often enough break them up into individual models and align them properly. In this case the models should stay relativ to where they are, because otherwise they would end up all at the centerpoint instead of making a bigger model.

In some cases I model stuff together in one file, which are still individual usable models though. Of course I can use different layers, but there is a limit to that, so I often enough move them out of the way. In such a case it would be usefull to export all the models as centerpoint models. This could be simply a toggle on the export dialog, which adjusts the matrix accordingly.

Mordenkainen · **Posted:** Fri Jul 27, 2007 7:19 pm

ratty redemption wrote:

mordenkainen, if you split the model in say 4 sections, does it take a quarter of the time to export one section? this is something I've been wondering about with some of my tests. there seems to be a threshold (could be ram related?) although I'm not sure yet what the verts/poly count threshold is yet, and whether it is a restriction of our systems or blender and goofos's .script

The same model at 30K takes around 5 mins. At 130K it takes 2 hours. Didn't experiment splitting it though.

Goofos: Thanks, dinner first but I'll try it and then report back.

Mordenkainen · **Posted:** Fri Jul 27, 2007 8:54 pm

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

ratty redemption · **Posted:** Fri Jul 27, 2007 8:57 pm

cool, I'll test this later tonight, and thanks mordenkainen for ul the file. that is easier then copy/paste the script from the forum here.

Goofos · **Posted:** Sat Jul 28, 2007 2:04 pm

Mordenkainen wrote:

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

(BTW quickly added support for multiple uv layers :> )

Please test the updated v0.6.9 script if uv and vcolor is exported right.

Mordenkainen · **Posted:** Sat Jul 28, 2007 10:32 pm

Goofos wrote:

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

130K poly version now takes 13 minutes. Export worked nicely. Great job man.

EDIT: 0.6.9 version uploaded here.

Goofos · **Posted:** Sun Jul 29, 2007 10:16 am

13 min? Hrmz, i have no idea where else i could search for lame code in the script.

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

If you track the progressbar, when does the script completely hang for a good while?

Mordenkainen · **Posted:** Mon Jul 30, 2007 8:24 pm

Goofos wrote:

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

Yeah. Do you want me to upload my model somewhere so you can see if there's anything wrong with it?

Quote:

If you track the progressbar, when does the script completely hang for a good while?

Most of the time is spent during "Writing Faces".

ratty redemption · **Posted:** Tue Jul 31, 2007 1:26 pm

goofos, sorry I didn't get to back to you earlier on this but I have just exported a high poly mesh a few times with uv's and vertex color, heres the console report.

Code:

Verts: 263169 Tris: 524288 Faces: 262144
Successfully exported temp.ase in 146.48 seconds 

which I think is truly amazing how much you've optimized your code

Mordenkainen · **Posted:** Wed Aug 01, 2007 4:08 pm

Mordenkainen wrote:

I precompiled the Python API during its installation it but Blender's own python scripts (including this exporter) aren't precompiled. Anyway I can precompile these too?

Yep, answering myself.

After some persistant searching I've found a way to precompile Blender's Python scripts too. I haven't experienced any noticeable perf increase but if you want to try it paste the following to Blender's Script editor and execute. Replace the path file with the one you installed Blender to, obviously:

Code:

import compileall

compileall.compile_dir('C:\Programs\Blender\.blender\scripts', force=True)

hyp3rfocus · **Joined:** Sun Jul 29, 2007 10:13 pm **Posts:** 7

edit- post deleted.

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

I have identified the cause of the mesh's coordinates being written relative to the world origin rather than the mesh object's own origin:

Code:

      me = Mesh.New()      # Create a new mesh

      if guiTable['MOD'] == 1:   # Use modified mesh
         me.getFromObject(obj.name, 0) # Get the object's mesh data, cage 0 = apply mod
      else:
         me.getFromObject(obj.name, 1)

      me.transform(obj.matrix)   #ASE stores transformed mesh data
      tempObj = Blender.Object.New('Mesh', 'ASE_export_temp_obj')
      tempObj.setMatrix(obj.matrix)
      tempObj.link(me)

What I assume this is doing (not being a Blender Python expert myself) is creating a new mesh object, copying the mesh data from the selected mesh into this new object, and then setting the new object to have the same transformation as the previous object (basically a deep copy of the mesh being exported).

The problem is the line me.transform(obj.matrix) which (I assume) applies the transformation of the object to the mesh data itself -- however, this transformation would include the location as well as the rotation and scale parameters, essentially applying the object's translation value to the contained mesh data, which is not what is needed when exporting a single object.

I assume that the purpose of this line is to avoid the user having to use Ctrl-A to apply size/rotation before exporting? Personally I would prefer to have to do this manually rather than having the translation applied to the mesh as well.

kat · **Posted:** Mon Aug 27, 2007 12:06 pm

I just re-read the problem you were having, am I right in assuming that you're basically centring the objects origin and then trying to export the mesh when it's not centred on the 000 grid origin? (so the objects centre is relative to where the object is on the grid?)

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

Yes -- the object's own centre point is correct, but is not aligned with the world center (0, 0, 0). With the script as written, the exported object's centre point is aligned with the world origin (0, 0, 0) and ignores the object's own centre point. With the problematic line commented out, it works as expected.

kat · **Posted:** Tue Aug 28, 2007 12:26 pm

I wonder if this could be added as an export option? Being able to export objects inplace (but with correctly recentred POO's) would be handy when building levels; it's pain in the arse to keep having to pull everything to the grid centre making sure you don't screw up the position of each section, an option to export in place would mean not having to do any of that *looks at Goofos with a Spock like raised eyebrow in question*

Goofos · **Posted:** Wed Aug 29, 2007 12:44 am

OrbWeaver wrote:

me.transform(obj.matrix) which (I assume) applies the transformation of the object to the mesh data itself -- however, this transformation would include the location as well as the rotation and scale parameters, essentially applying the object's translation value to the contained mesh data, which is not what is needed when exporting a single object.

Yes, it applies loc/rot/scale to the mesh data. In earlier script versions this was an optional option. Later i discovered that the mesh data is transformed in ASE files but the object still has the loc/rot/scale informations.

If you comment that line out, it basically use the local mesh data without loc/rot/scale but it still write the transformation infos to the ase file and would have a negative transformation when importing the ase file in apps which care about loc/rot/scale. I think usually you would need to change some more lines in the script so it don't export the original transform infos. But i'm currently unsure which lines (at least some lines in def mesh_matrix).

kat wrote:

I wonder if this could be added as an export option? Being able to export objects inplace (but with correctly recentred POO's) would be handy when building levels; it's pain in the arse to keep having to pull everything to the grid centre making sure you don't screw up the position of each section, an option to export in place would mean not having to do any of that *looks at Goofos with a Spock like raised eyebrow in question*

I think i don't got it. :> You mean export each object moved to world origin, or export each object with its origin moved to the world origin?

kat · **Posted:** Wed Aug 29, 2007 1:30 am

Goofos wrote:

...I think i don't got it. :> You mean export each object moved to world origin, or export each object with its origin moved to the world origin?

Soory Goofos.. what I mean was this... say you design a level (as I've been doing) and in order to export it and make it efficient with the engine it has to be cut up into segments. Normally each of these segments needs both the mesh and the segments centre to bo placed over the 000 grid point, that means each piece has to be moved which runs the risk of messing up the alignment with other segments.

What would be ideal is if you could correctly position the segments centre where it was originally and have the mesh export from there - unless I'm missing something in the new code the mesh gets exported with the polygons positioned where they were but the objects centre in then placed at 000, is that right? What you'd want on a big mesh cut into many segments is to leave them where they are and just repostion the origin locally and export like that.

Does that make sense?

sparhawk · **Joined:** Wed Sep 08, 2004 7:48 am **Posts:** 554

Not sure if I understand it correctly, but an option that could specify wether you want the object to be exported as residing a 0,0,0 or stay where it is would be very usefull.

Normally, I would like my objects to be at the centerpoint. When I model, then I often enough break them up into individual models and align them properly. In this case the models should stay relativ to where they are, because otherwise they would end up all at the centerpoint instead of making a bigger model.

In some cases I model stuff together in one file, which are still individual usable models though. Of course I can use different layers, but there is a limit to that, so I often enough move them out of the way. In such a case it would be usefull to export all the models as centerpoint models. This could be simply a toggle on the export dialog, which adjusts the matrix accordingly.

Mordenkainen · **Posted:** Fri Jul 27, 2007 7:19 pm

ratty redemption wrote:

mordenkainen, if you split the model in say 4 sections, does it take a quarter of the time to export one section? this is something I've been wondering about with some of my tests. there seems to be a threshold (could be ram related?) although I'm not sure yet what the verts/poly count threshold is yet, and whether it is a restriction of our systems or blender and goofos's .script

The same model at 30K takes around 5 mins. At 130K it takes 2 hours. Didn't experiment splitting it though.

Goofos: Thanks, dinner first but I'll try it and then report back.

Mordenkainen · **Posted:** Fri Jul 27, 2007 8:54 pm

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

ratty redemption · **Posted:** Fri Jul 27, 2007 8:57 pm

cool, I'll test this later tonight, and thanks mordenkainen for ul the file. that is easier then copy/paste the script from the forum here.

Goofos · **Posted:** Sat Jul 28, 2007 2:04 pm

Mordenkainen wrote:

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

(BTW quickly added support for multiple uv layers :> )

Please test the updated v0.6.9 script if uv and vcolor is exported right.

Mordenkainen · **Posted:** Sat Jul 28, 2007 10:32 pm

Goofos wrote:

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

130K poly version now takes 13 minutes. Export worked nicely. Great job man.

EDIT: 0.6.9 version uploaded here.

Goofos · **Posted:** Sun Jul 29, 2007 10:16 am

13 min? Hrmz, i have no idea where else i could search for lame code in the script.

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

If you track the progressbar, when does the script completely hang for a good while?

Mordenkainen · **Posted:** Mon Jul 30, 2007 8:24 pm

Goofos wrote:

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

Yeah. Do you want me to upload my model somewhere so you can see if there's anything wrong with it?

Quote:

If you track the progressbar, when does the script completely hang for a good while?

Most of the time is spent during "Writing Faces".

ratty redemption · **Posted:** Tue Jul 31, 2007 1:26 pm

goofos, sorry I didn't get to back to you earlier on this but I have just exported a high poly mesh a few times with uv's and vertex color, heres the console report.

Code:

Verts: 263169 Tris: 524288 Faces: 262144
Successfully exported temp.ase in 146.48 seconds 

which I think is truly amazing how much you've optimized your code

Mordenkainen · **Posted:** Wed Aug 01, 2007 4:08 pm

Mordenkainen wrote:

I precompiled the Python API during its installation it but Blender's own python scripts (including this exporter) aren't precompiled. Anyway I can precompile these too?

Yep, answering myself.

After some persistant searching I've found a way to precompile Blender's Python scripts too. I haven't experienced any noticeable perf increase but if you want to try it paste the following to Blender's Script editor and execute. Replace the path file with the one you installed Blender to, obviously:

Code:

import compileall

compileall.compile_dir('C:\Programs\Blender\.blender\scripts', force=True)

hyp3rfocus · **Joined:** Sun Jul 29, 2007 10:13 pm **Posts:** 7

edit- post deleted.

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

I have identified the cause of the mesh's coordinates being written relative to the world origin rather than the mesh object's own origin:

Code:

      me = Mesh.New()      # Create a new mesh

      if guiTable['MOD'] == 1:   # Use modified mesh
         me.getFromObject(obj.name, 0) # Get the object's mesh data, cage 0 = apply mod
      else:
         me.getFromObject(obj.name, 1)

      me.transform(obj.matrix)   #ASE stores transformed mesh data
      tempObj = Blender.Object.New('Mesh', 'ASE_export_temp_obj')
      tempObj.setMatrix(obj.matrix)
      tempObj.link(me)

What I assume this is doing (not being a Blender Python expert myself) is creating a new mesh object, copying the mesh data from the selected mesh into this new object, and then setting the new object to have the same transformation as the previous object (basically a deep copy of the mesh being exported).

The problem is the line me.transform(obj.matrix) which (I assume) applies the transformation of the object to the mesh data itself -- however, this transformation would include the location as well as the rotation and scale parameters, essentially applying the object's translation value to the contained mesh data, which is not what is needed when exporting a single object.

I assume that the purpose of this line is to avoid the user having to use Ctrl-A to apply size/rotation before exporting? Personally I would prefer to have to do this manually rather than having the translation applied to the mesh as well.

kat · **Posted:** Mon Aug 27, 2007 12:06 pm

I just re-read the problem you were having, am I right in assuming that you're basically centring the objects origin and then trying to export the mesh when it's not centred on the 000 grid origin? (so the objects centre is relative to where the object is on the grid?)

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

Yes -- the object's own centre point is correct, but is not aligned with the world center (0, 0, 0). With the script as written, the exported object's centre point is aligned with the world origin (0, 0, 0) and ignores the object's own centre point. With the problematic line commented out, it works as expected.

kat · **Posted:** Tue Aug 28, 2007 12:26 pm

I wonder if this could be added as an export option? Being able to export objects inplace (but with correctly recentred POO's) would be handy when building levels; it's pain in the arse to keep having to pull everything to the grid centre making sure you don't screw up the position of each section, an option to export in place would mean not having to do any of that *looks at Goofos with a Spock like raised eyebrow in question*

Goofos · **Posted:** Wed Aug 29, 2007 12:44 am

OrbWeaver wrote:

me.transform(obj.matrix) which (I assume) applies the transformation of the object to the mesh data itself -- however, this transformation would include the location as well as the rotation and scale parameters, essentially applying the object's translation value to the contained mesh data, which is not what is needed when exporting a single object.

Yes, it applies loc/rot/scale to the mesh data. In earlier script versions this was an optional option. Later i discovered that the mesh data is transformed in ASE files but the object still has the loc/rot/scale informations.

If you comment that line out, it basically use the local mesh data without loc/rot/scale but it still write the transformation infos to the ase file and would have a negative transformation when importing the ase file in apps which care about loc/rot/scale. I think usually you would need to change some more lines in the script so it don't export the original transform infos. But i'm currently unsure which lines (at least some lines in def mesh_matrix).

kat wrote:

I wonder if this could be added as an export option? Being able to export objects inplace (but with correctly recentred POO's) would be handy when building levels; it's pain in the arse to keep having to pull everything to the grid centre making sure you don't screw up the position of each section, an option to export in place would mean not having to do any of that *looks at Goofos with a Spock like raised eyebrow in question*

I think i don't got it. :> You mean export each object moved to world origin, or export each object with its origin moved to the world origin?

kat · **Posted:** Wed Aug 29, 2007 1:30 am

Goofos wrote:

...I think i don't got it. :> You mean export each object moved to world origin, or export each object with its origin moved to the world origin?

Soory Goofos.. what I mean was this... say you design a level (as I've been doing) and in order to export it and make it efficient with the engine it has to be cut up into segments. Normally each of these segments needs both the mesh and the segments centre to bo placed over the 000 grid point, that means each piece has to be moved which runs the risk of messing up the alignment with other segments.

What would be ideal is if you could correctly position the segments centre where it was originally and have the mesh export from there - unless I'm missing something in the new code the mesh gets exported with the polygons positioned where they were but the objects centre in then placed at 000, is that right? What you'd want on a big mesh cut into many segments is to leave them where they are and just repostion the origin locally and export like that.

Does that make sense?

sparhawk · **Joined:** Wed Sep 08, 2004 7:48 am **Posts:** 554

Not sure if I understand it correctly, but an option that could specify wether you want the object to be exported as residing a 0,0,0 or stay where it is would be very usefull.

Normally, I would like my objects to be at the centerpoint. When I model, then I often enough break them up into individual models and align them properly. In this case the models should stay relativ to where they are, because otherwise they would end up all at the centerpoint instead of making a bigger model.

In some cases I model stuff together in one file, which are still individual usable models though. Of course I can use different layers, but there is a limit to that, so I often enough move them out of the way. In such a case it would be usefull to export all the models as centerpoint models. This could be simply a toggle on the export dialog, which adjusts the matrix accordingly.

Mordenkainen · **Posted:** Fri Jul 27, 2007 7:19 pm

ratty redemption wrote:

mordenkainen, if you split the model in say 4 sections, does it take a quarter of the time to export one section? this is something I've been wondering about with some of my tests. there seems to be a threshold (could be ram related?) although I'm not sure yet what the verts/poly count threshold is yet, and whether it is a restriction of our systems or blender and goofos's .script

The same model at 30K takes around 5 mins. At 130K it takes 2 hours. Didn't experiment splitting it though.

Goofos: Thanks, dinner first but I'll try it and then report back.

Mordenkainen · **Posted:** Fri Jul 27, 2007 8:54 pm

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

ratty redemption · **Posted:** Fri Jul 27, 2007 8:57 pm

cool, I'll test this later tonight, and thanks mordenkainen for ul the file. that is easier then copy/paste the script from the forum here.

Goofos · **Posted:** Sat Jul 28, 2007 2:04 pm

Mordenkainen wrote:

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

(BTW quickly added support for multiple uv layers :> )

Please test the updated v0.6.9 script if uv and vcolor is exported right.

Mordenkainen · **Posted:** Sat Jul 28, 2007 10:32 pm

Goofos wrote:

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

130K poly version now takes 13 minutes. Export worked nicely. Great job man.

EDIT: 0.6.9 version uploaded here.

Goofos · **Posted:** Sun Jul 29, 2007 10:16 am

13 min? Hrmz, i have no idea where else i could search for lame code in the script.

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

If you track the progressbar, when does the script completely hang for a good while?

Mordenkainen · **Posted:** Mon Jul 30, 2007 8:24 pm

Goofos wrote:

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

Yeah. Do you want me to upload my model somewhere so you can see if there's anything wrong with it?

Quote:

If you track the progressbar, when does the script completely hang for a good while?

Most of the time is spent during "Writing Faces".

ratty redemption · **Posted:** Tue Jul 31, 2007 1:26 pm

goofos, sorry I didn't get to back to you earlier on this but I have just exported a high poly mesh a few times with uv's and vertex color, heres the console report.

Code:

Verts: 263169 Tris: 524288 Faces: 262144
Successfully exported temp.ase in 146.48 seconds 

which I think is truly amazing how much you've optimized your code

Mordenkainen · **Posted:** Wed Aug 01, 2007 4:08 pm

Mordenkainen wrote:

I precompiled the Python API during its installation it but Blender's own python scripts (including this exporter) aren't precompiled. Anyway I can precompile these too?

Yep, answering myself.

After some persistant searching I've found a way to precompile Blender's Python scripts too. I haven't experienced any noticeable perf increase but if you want to try it paste the following to Blender's Script editor and execute. Replace the path file with the one you installed Blender to, obviously:

Code:

import compileall

compileall.compile_dir('C:\Programs\Blender\.blender\scripts', force=True)

hyp3rfocus · **Joined:** Sun Jul 29, 2007 10:13 pm **Posts:** 7

edit- post deleted.

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

I have identified the cause of the mesh's coordinates being written relative to the world origin rather than the mesh object's own origin:

Code:

      me = Mesh.New()      # Create a new mesh

      if guiTable['MOD'] == 1:   # Use modified mesh
         me.getFromObject(obj.name, 0) # Get the object's mesh data, cage 0 = apply mod
      else:
         me.getFromObject(obj.name, 1)

      me.transform(obj.matrix)   #ASE stores transformed mesh data
      tempObj = Blender.Object.New('Mesh', 'ASE_export_temp_obj')
      tempObj.setMatrix(obj.matrix)
      tempObj.link(me)

What I assume this is doing (not being a Blender Python expert myself) is creating a new mesh object, copying the mesh data from the selected mesh into this new object, and then setting the new object to have the same transformation as the previous object (basically a deep copy of the mesh being exported).

The problem is the line me.transform(obj.matrix) which (I assume) applies the transformation of the object to the mesh data itself -- however, this transformation would include the location as well as the rotation and scale parameters, essentially applying the object's translation value to the contained mesh data, which is not what is needed when exporting a single object.

I assume that the purpose of this line is to avoid the user having to use Ctrl-A to apply size/rotation before exporting? Personally I would prefer to have to do this manually rather than having the translation applied to the mesh as well.

kat · **Posted:** Mon Aug 27, 2007 12:06 pm

I just re-read the problem you were having, am I right in assuming that you're basically centring the objects origin and then trying to export the mesh when it's not centred on the 000 grid origin? (so the objects centre is relative to where the object is on the grid?)

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

Yes -- the object's own centre point is correct, but is not aligned with the world center (0, 0, 0). With the script as written, the exported object's centre point is aligned with the world origin (0, 0, 0) and ignores the object's own centre point. With the problematic line commented out, it works as expected.

kat · **Posted:** Tue Aug 28, 2007 12:26 pm

I wonder if this could be added as an export option? Being able to export objects inplace (but with correctly recentred POO's) would be handy when building levels; it's pain in the arse to keep having to pull everything to the grid centre making sure you don't screw up the position of each section, an option to export in place would mean not having to do any of that *looks at Goofos with a Spock like raised eyebrow in question*

Goofos · **Posted:** Wed Aug 29, 2007 12:44 am

OrbWeaver wrote:

me.transform(obj.matrix) which (I assume) applies the transformation of the object to the mesh data itself -- however, this transformation would include the location as well as the rotation and scale parameters, essentially applying the object's translation value to the contained mesh data, which is not what is needed when exporting a single object.

Yes, it applies loc/rot/scale to the mesh data. In earlier script versions this was an optional option. Later i discovered that the mesh data is transformed in ASE files but the object still has the loc/rot/scale informations.

If you comment that line out, it basically use the local mesh data without loc/rot/scale but it still write the transformation infos to the ase file and would have a negative transformation when importing the ase file in apps which care about loc/rot/scale. I think usually you would need to change some more lines in the script so it don't export the original transform infos. But i'm currently unsure which lines (at least some lines in def mesh_matrix).

kat wrote:

I wonder if this could be added as an export option? Being able to export objects inplace (but with correctly recentred POO's) would be handy when building levels; it's pain in the arse to keep having to pull everything to the grid centre making sure you don't screw up the position of each section, an option to export in place would mean not having to do any of that *looks at Goofos with a Spock like raised eyebrow in question*

I think i don't got it. :> You mean export each object moved to world origin, or export each object with its origin moved to the world origin?

kat · **Posted:** Wed Aug 29, 2007 1:30 am

Goofos wrote:

...I think i don't got it. :> You mean export each object moved to world origin, or export each object with its origin moved to the world origin?

Soory Goofos.. what I mean was this... say you design a level (as I've been doing) and in order to export it and make it efficient with the engine it has to be cut up into segments. Normally each of these segments needs both the mesh and the segments centre to bo placed over the 000 grid point, that means each piece has to be moved which runs the risk of messing up the alignment with other segments.

What would be ideal is if you could correctly position the segments centre where it was originally and have the mesh export from there - unless I'm missing something in the new code the mesh gets exported with the polygons positioned where they were but the objects centre in then placed at 000, is that right? What you'd want on a big mesh cut into many segments is to leave them where they are and just repostion the origin locally and export like that.

Does that make sense?

sparhawk · **Joined:** Wed Sep 08, 2004 7:48 am **Posts:** 554

Not sure if I understand it correctly, but an option that could specify wether you want the object to be exported as residing a 0,0,0 or stay where it is would be very usefull.

Normally, I would like my objects to be at the centerpoint. When I model, then I often enough break them up into individual models and align them properly. In this case the models should stay relativ to where they are, because otherwise they would end up all at the centerpoint instead of making a bigger model.

In some cases I model stuff together in one file, which are still individual usable models though. Of course I can use different layers, but there is a limit to that, so I often enough move them out of the way. In such a case it would be usefull to export all the models as centerpoint models. This could be simply a toggle on the export dialog, which adjusts the matrix accordingly.

Mordenkainen · **Posted:** Fri Jul 27, 2007 7:19 pm

ratty redemption wrote:

mordenkainen, if you split the model in say 4 sections, does it take a quarter of the time to export one section? this is something I've been wondering about with some of my tests. there seems to be a threshold (could be ram related?) although I'm not sure yet what the verts/poly count threshold is yet, and whether it is a restriction of our systems or blender and goofos's .script

The same model at 30K takes around 5 mins. At 130K it takes 2 hours. Didn't experiment splitting it though.

Goofos: Thanks, dinner first but I'll try it and then report back.

Mordenkainen · **Posted:** Fri Jul 27, 2007 8:54 pm

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

ratty redemption · **Posted:** Fri Jul 27, 2007 8:57 pm

cool, I'll test this later tonight, and thanks mordenkainen for ul the file. that is easier then copy/paste the script from the forum here.

Goofos · **Posted:** Sat Jul 28, 2007 2:04 pm

Mordenkainen wrote:

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

(BTW quickly added support for multiple uv layers :> )

Please test the updated v0.6.9 script if uv and vcolor is exported right.

Mordenkainen · **Posted:** Sat Jul 28, 2007 10:32 pm

Goofos wrote:

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

130K poly version now takes 13 minutes. Export worked nicely. Great job man.

EDIT: 0.6.9 version uploaded here.

Goofos · **Posted:** Sun Jul 29, 2007 10:16 am

13 min? Hrmz, i have no idea where else i could search for lame code in the script.

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

If you track the progressbar, when does the script completely hang for a good while?

Mordenkainen · **Posted:** Mon Jul 30, 2007 8:24 pm

Goofos wrote:

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

Yeah. Do you want me to upload my model somewhere so you can see if there's anything wrong with it?

Quote:

If you track the progressbar, when does the script completely hang for a good while?

Most of the time is spent during "Writing Faces".

ratty redemption · **Posted:** Tue Jul 31, 2007 1:26 pm

goofos, sorry I didn't get to back to you earlier on this but I have just exported a high poly mesh a few times with uv's and vertex color, heres the console report.

Code:

Verts: 263169 Tris: 524288 Faces: 262144
Successfully exported temp.ase in 146.48 seconds 

which I think is truly amazing how much you've optimized your code

Mordenkainen · **Posted:** Wed Aug 01, 2007 4:08 pm

Mordenkainen wrote:

I precompiled the Python API during its installation it but Blender's own python scripts (including this exporter) aren't precompiled. Anyway I can precompile these too?

Yep, answering myself.

After some persistant searching I've found a way to precompile Blender's Python scripts too. I haven't experienced any noticeable perf increase but if you want to try it paste the following to Blender's Script editor and execute. Replace the path file with the one you installed Blender to, obviously:

Code:

import compileall

compileall.compile_dir('C:\Programs\Blender\.blender\scripts', force=True)

hyp3rfocus · **Joined:** Sun Jul 29, 2007 10:13 pm **Posts:** 7

edit- post deleted.

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

I have identified the cause of the mesh's coordinates being written relative to the world origin rather than the mesh object's own origin:

Code:

      me = Mesh.New()      # Create a new mesh

      if guiTable['MOD'] == 1:   # Use modified mesh
         me.getFromObject(obj.name, 0) # Get the object's mesh data, cage 0 = apply mod
      else:
         me.getFromObject(obj.name, 1)

      me.transform(obj.matrix)   #ASE stores transformed mesh data
      tempObj = Blender.Object.New('Mesh', 'ASE_export_temp_obj')
      tempObj.setMatrix(obj.matrix)
      tempObj.link(me)

What I assume this is doing (not being a Blender Python expert myself) is creating a new mesh object, copying the mesh data from the selected mesh into this new object, and then setting the new object to have the same transformation as the previous object (basically a deep copy of the mesh being exported).

The problem is the line me.transform(obj.matrix) which (I assume) applies the transformation of the object to the mesh data itself -- however, this transformation would include the location as well as the rotation and scale parameters, essentially applying the object's translation value to the contained mesh data, which is not what is needed when exporting a single object.

I assume that the purpose of this line is to avoid the user having to use Ctrl-A to apply size/rotation before exporting? Personally I would prefer to have to do this manually rather than having the translation applied to the mesh as well.

kat · **Posted:** Mon Aug 27, 2007 12:06 pm

I just re-read the problem you were having, am I right in assuming that you're basically centring the objects origin and then trying to export the mesh when it's not centred on the 000 grid origin? (so the objects centre is relative to where the object is on the grid?)

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

Yes -- the object's own centre point is correct, but is not aligned with the world center (0, 0, 0). With the script as written, the exported object's centre point is aligned with the world origin (0, 0, 0) and ignores the object's own centre point. With the problematic line commented out, it works as expected.

kat · **Posted:** Tue Aug 28, 2007 12:26 pm

I wonder if this could be added as an export option? Being able to export objects inplace (but with correctly recentred POO's) would be handy when building levels; it's pain in the arse to keep having to pull everything to the grid centre making sure you don't screw up the position of each section, an option to export in place would mean not having to do any of that *looks at Goofos with a Spock like raised eyebrow in question*

Goofos · **Posted:** Wed Aug 29, 2007 12:44 am

OrbWeaver wrote:

me.transform(obj.matrix) which (I assume) applies the transformation of the object to the mesh data itself -- however, this transformation would include the location as well as the rotation and scale parameters, essentially applying the object's translation value to the contained mesh data, which is not what is needed when exporting a single object.

Yes, it applies loc/rot/scale to the mesh data. In earlier script versions this was an optional option. Later i discovered that the mesh data is transformed in ASE files but the object still has the loc/rot/scale informations.

If you comment that line out, it basically use the local mesh data without loc/rot/scale but it still write the transformation infos to the ase file and would have a negative transformation when importing the ase file in apps which care about loc/rot/scale. I think usually you would need to change some more lines in the script so it don't export the original transform infos. But i'm currently unsure which lines (at least some lines in def mesh_matrix).

kat wrote:

I wonder if this could be added as an export option? Being able to export objects inplace (but with correctly recentred POO's) would be handy when building levels; it's pain in the arse to keep having to pull everything to the grid centre making sure you don't screw up the position of each section, an option to export in place would mean not having to do any of that *looks at Goofos with a Spock like raised eyebrow in question*

I think i don't got it. :> You mean export each object moved to world origin, or export each object with its origin moved to the world origin?

kat · **Posted:** Wed Aug 29, 2007 1:30 am

Goofos wrote:

...I think i don't got it. :> You mean export each object moved to world origin, or export each object with its origin moved to the world origin?

Soory Goofos.. what I mean was this... say you design a level (as I've been doing) and in order to export it and make it efficient with the engine it has to be cut up into segments. Normally each of these segments needs both the mesh and the segments centre to bo placed over the 000 grid point, that means each piece has to be moved which runs the risk of messing up the alignment with other segments.

What would be ideal is if you could correctly position the segments centre where it was originally and have the mesh export from there - unless I'm missing something in the new code the mesh gets exported with the polygons positioned where they were but the objects centre in then placed at 000, is that right? What you'd want on a big mesh cut into many segments is to leave them where they are and just repostion the origin locally and export like that.

Does that make sense?

sparhawk · **Joined:** Wed Sep 08, 2004 7:48 am **Posts:** 554

Not sure if I understand it correctly, but an option that could specify wether you want the object to be exported as residing a 0,0,0 or stay where it is would be very usefull.

Normally, I would like my objects to be at the centerpoint. When I model, then I often enough break them up into individual models and align them properly. In this case the models should stay relativ to where they are, because otherwise they would end up all at the centerpoint instead of making a bigger model.

In some cases I model stuff together in one file, which are still individual usable models though. Of course I can use different layers, but there is a limit to that, so I often enough move them out of the way. In such a case it would be usefull to export all the models as centerpoint models. This could be simply a toggle on the export dialog, which adjusts the matrix accordingly.

Mordenkainen · **Posted:** Fri Jul 27, 2007 7:19 pm

ratty redemption wrote:

mordenkainen, if you split the model in say 4 sections, does it take a quarter of the time to export one section? this is something I've been wondering about with some of my tests. there seems to be a threshold (could be ram related?) although I'm not sure yet what the verts/poly count threshold is yet, and whether it is a restriction of our systems or blender and goofos's .script

The same model at 30K takes around 5 mins. At 130K it takes 2 hours. Didn't experiment splitting it though.

Goofos: Thanks, dinner first but I'll try it and then report back.

Mordenkainen · **Posted:** Fri Jul 27, 2007 8:54 pm

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

ratty redemption · **Posted:** Fri Jul 27, 2007 8:57 pm

cool, I'll test this later tonight, and thanks mordenkainen for ul the file. that is easier then copy/paste the script from the forum here.

Goofos · **Posted:** Sat Jul 28, 2007 2:04 pm

Mordenkainen wrote:

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

(BTW quickly added support for multiple uv layers :> )

Please test the updated v0.6.9 script if uv and vcolor is exported right.

Mordenkainen · **Posted:** Sat Jul 28, 2007 10:32 pm

Goofos wrote:

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

130K poly version now takes 13 minutes. Export worked nicely. Great job man.

EDIT: 0.6.9 version uploaded here.

Goofos · **Posted:** Sun Jul 29, 2007 10:16 am

13 min? Hrmz, i have no idea where else i could search for lame code in the script.

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

If you track the progressbar, when does the script completely hang for a good while?

Mordenkainen · **Posted:** Mon Jul 30, 2007 8:24 pm

Goofos wrote:

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

Yeah. Do you want me to upload my model somewhere so you can see if there's anything wrong with it?

Quote:

If you track the progressbar, when does the script completely hang for a good while?

Most of the time is spent during "Writing Faces".

ratty redemption · **Posted:** Tue Jul 31, 2007 1:26 pm

goofos, sorry I didn't get to back to you earlier on this but I have just exported a high poly mesh a few times with uv's and vertex color, heres the console report.

Code:

Verts: 263169 Tris: 524288 Faces: 262144
Successfully exported temp.ase in 146.48 seconds 

which I think is truly amazing how much you've optimized your code

Mordenkainen · **Posted:** Wed Aug 01, 2007 4:08 pm

Mordenkainen wrote:

I precompiled the Python API during its installation it but Blender's own python scripts (including this exporter) aren't precompiled. Anyway I can precompile these too?

Yep, answering myself.

After some persistant searching I've found a way to precompile Blender's Python scripts too. I haven't experienced any noticeable perf increase but if you want to try it paste the following to Blender's Script editor and execute. Replace the path file with the one you installed Blender to, obviously:

Code:

import compileall

compileall.compile_dir('C:\Programs\Blender\.blender\scripts', force=True)

hyp3rfocus · **Joined:** Sun Jul 29, 2007 10:13 pm **Posts:** 7

edit- post deleted.

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

I have identified the cause of the mesh's coordinates being written relative to the world origin rather than the mesh object's own origin:

Code:

      me = Mesh.New()      # Create a new mesh

      if guiTable['MOD'] == 1:   # Use modified mesh
         me.getFromObject(obj.name, 0) # Get the object's mesh data, cage 0 = apply mod
      else:
         me.getFromObject(obj.name, 1)

      me.transform(obj.matrix)   #ASE stores transformed mesh data
      tempObj = Blender.Object.New('Mesh', 'ASE_export_temp_obj')
      tempObj.setMatrix(obj.matrix)
      tempObj.link(me)

What I assume this is doing (not being a Blender Python expert myself) is creating a new mesh object, copying the mesh data from the selected mesh into this new object, and then setting the new object to have the same transformation as the previous object (basically a deep copy of the mesh being exported).

The problem is the line me.transform(obj.matrix) which (I assume) applies the transformation of the object to the mesh data itself -- however, this transformation would include the location as well as the rotation and scale parameters, essentially applying the object's translation value to the contained mesh data, which is not what is needed when exporting a single object.

I assume that the purpose of this line is to avoid the user having to use Ctrl-A to apply size/rotation before exporting? Personally I would prefer to have to do this manually rather than having the translation applied to the mesh as well.

kat · **Posted:** Mon Aug 27, 2007 12:06 pm

I just re-read the problem you were having, am I right in assuming that you're basically centring the objects origin and then trying to export the mesh when it's not centred on the 000 grid origin? (so the objects centre is relative to where the object is on the grid?)

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

Yes -- the object's own centre point is correct, but is not aligned with the world center (0, 0, 0). With the script as written, the exported object's centre point is aligned with the world origin (0, 0, 0) and ignores the object's own centre point. With the problematic line commented out, it works as expected.

kat · **Posted:** Tue Aug 28, 2007 12:26 pm

I wonder if this could be added as an export option? Being able to export objects inplace (but with correctly recentred POO's) would be handy when building levels; it's pain in the arse to keep having to pull everything to the grid centre making sure you don't screw up the position of each section, an option to export in place would mean not having to do any of that *looks at Goofos with a Spock like raised eyebrow in question*

Goofos · **Posted:** Wed Aug 29, 2007 12:44 am

OrbWeaver wrote:

me.transform(obj.matrix) which (I assume) applies the transformation of the object to the mesh data itself -- however, this transformation would include the location as well as the rotation and scale parameters, essentially applying the object's translation value to the contained mesh data, which is not what is needed when exporting a single object.

Yes, it applies loc/rot/scale to the mesh data. In earlier script versions this was an optional option. Later i discovered that the mesh data is transformed in ASE files but the object still has the loc/rot/scale informations.

If you comment that line out, it basically use the local mesh data without loc/rot/scale but it still write the transformation infos to the ase file and would have a negative transformation when importing the ase file in apps which care about loc/rot/scale. I think usually you would need to change some more lines in the script so it don't export the original transform infos. But i'm currently unsure which lines (at least some lines in def mesh_matrix).

kat wrote:

I wonder if this could be added as an export option? Being able to export objects inplace (but with correctly recentred POO's) would be handy when building levels; it's pain in the arse to keep having to pull everything to the grid centre making sure you don't screw up the position of each section, an option to export in place would mean not having to do any of that *looks at Goofos with a Spock like raised eyebrow in question*

I think i don't got it. :> You mean export each object moved to world origin, or export each object with its origin moved to the world origin?

kat · **Posted:** Wed Aug 29, 2007 1:30 am

Goofos wrote:

...I think i don't got it. :> You mean export each object moved to world origin, or export each object with its origin moved to the world origin?

Soory Goofos.. what I mean was this... say you design a level (as I've been doing) and in order to export it and make it efficient with the engine it has to be cut up into segments. Normally each of these segments needs both the mesh and the segments centre to bo placed over the 000 grid point, that means each piece has to be moved which runs the risk of messing up the alignment with other segments.

What would be ideal is if you could correctly position the segments centre where it was originally and have the mesh export from there - unless I'm missing something in the new code the mesh gets exported with the polygons positioned where they were but the objects centre in then placed at 000, is that right? What you'd want on a big mesh cut into many segments is to leave them where they are and just repostion the origin locally and export like that.

Does that make sense?

sparhawk · **Joined:** Wed Sep 08, 2004 7:48 am **Posts:** 558

Not sure if I understand it correctly, but an option that could specify wether you want the object to be exported as residing a 0,0,0 or stay where it is would be very usefull.

Normally, I would like my objects to be at the centerpoint. When I model, then I often enough break them up into individual models and align them properly. In this case the models should stay relativ to where they are, because otherwise they would end up all at the centerpoint instead of making a bigger model.

In some cases I model stuff together in one file, which are still individual usable models though. Of course I can use different layers, but there is a limit to that, so I often enough move them out of the way. In such a case it would be usefull to export all the models as centerpoint models. This could be simply a toggle on the export dialog, which adjusts the matrix accordingly.

Mordenkainen · **Posted:** Fri Jul 27, 2007 7:19 pm

ratty redemption wrote:

mordenkainen, if you split the model in say 4 sections, does it take a quarter of the time to export one section? this is something I've been wondering about with some of my tests. there seems to be a threshold (could be ram related?) although I'm not sure yet what the verts/poly count threshold is yet, and whether it is a restriction of our systems or blender and goofos's .script

The same model at 30K takes around 5 mins. At 130K it takes 2 hours. Didn't experiment splitting it though.

Goofos: Thanks, dinner first but I'll try it and then report back.

Mordenkainen · **Posted:** Fri Jul 27, 2007 8:54 pm

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

ratty redemption · **Posted:** Fri Jul 27, 2007 8:57 pm

cool, I'll test this later tonight, and thanks mordenkainen for ul the file. that is easier then copy/paste the script from the forum here.

Goofos · **Posted:** Sat Jul 28, 2007 2:04 pm

Mordenkainen wrote:

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

(BTW quickly added support for multiple uv layers :> )

Please test the updated v0.6.9 script if uv and vcolor is exported right.

Mordenkainen · **Posted:** Sat Jul 28, 2007 10:32 pm

Goofos wrote:

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

130K poly version now takes 13 minutes. Export worked nicely. Great job man.

EDIT: 0.6.9 version uploaded here.

Goofos · **Posted:** Sun Jul 29, 2007 10:16 am

13 min? Hrmz, i have no idea where else i could search for lame code in the script.

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

If you track the progressbar, when does the script completely hang for a good while?

Mordenkainen · **Posted:** Mon Jul 30, 2007 8:24 pm

Goofos wrote:

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

Yeah. Do you want me to upload my model somewhere so you can see if there's anything wrong with it?

Quote:

If you track the progressbar, when does the script completely hang for a good while?

Most of the time is spent during "Writing Faces".

ratty redemption · **Posted:** Tue Jul 31, 2007 1:26 pm

goofos, sorry I didn't get to back to you earlier on this but I have just exported a high poly mesh a few times with uv's and vertex color, heres the console report.

Code:

Verts: 263169 Tris: 524288 Faces: 262144
Successfully exported temp.ase in 146.48 seconds 

which I think is truly amazing how much you've optimized your code

Mordenkainen · **Posted:** Wed Aug 01, 2007 4:08 pm

Mordenkainen wrote:

I precompiled the Python API during its installation it but Blender's own python scripts (including this exporter) aren't precompiled. Anyway I can precompile these too?

Yep, answering myself.

After some persistant searching I've found a way to precompile Blender's Python scripts too. I haven't experienced any noticeable perf increase but if you want to try it paste the following to Blender's Script editor and execute. Replace the path file with the one you installed Blender to, obviously:

Code:

import compileall

compileall.compile_dir('C:\Programs\Blender\.blender\scripts', force=True)

hyp3rfocus · **Joined:** Sun Jul 29, 2007 10:13 pm **Posts:** 7

edit- post deleted.

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

I have identified the cause of the mesh's coordinates being written relative to the world origin rather than the mesh object's own origin:

Code:

      me = Mesh.New()      # Create a new mesh

      if guiTable['MOD'] == 1:   # Use modified mesh
         me.getFromObject(obj.name, 0) # Get the object's mesh data, cage 0 = apply mod
      else:
         me.getFromObject(obj.name, 1)

      me.transform(obj.matrix)   #ASE stores transformed mesh data
      tempObj = Blender.Object.New('Mesh', 'ASE_export_temp_obj')
      tempObj.setMatrix(obj.matrix)
      tempObj.link(me)

What I assume this is doing (not being a Blender Python expert myself) is creating a new mesh object, copying the mesh data from the selected mesh into this new object, and then setting the new object to have the same transformation as the previous object (basically a deep copy of the mesh being exported).

The problem is the line me.transform(obj.matrix) which (I assume) applies the transformation of the object to the mesh data itself -- however, this transformation would include the location as well as the rotation and scale parameters, essentially applying the object's translation value to the contained mesh data, which is not what is needed when exporting a single object.

I assume that the purpose of this line is to avoid the user having to use Ctrl-A to apply size/rotation before exporting? Personally I would prefer to have to do this manually rather than having the translation applied to the mesh as well.

kat · **Posted:** Mon Aug 27, 2007 12:06 pm

I just re-read the problem you were having, am I right in assuming that you're basically centring the objects origin and then trying to export the mesh when it's not centred on the 000 grid origin? (so the objects centre is relative to where the object is on the grid?)

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

Yes -- the object's own centre point is correct, but is not aligned with the world center (0, 0, 0). With the script as written, the exported object's centre point is aligned with the world origin (0, 0, 0) and ignores the object's own centre point. With the problematic line commented out, it works as expected.

kat · **Posted:** Tue Aug 28, 2007 12:26 pm

I wonder if this could be added as an export option? Being able to export objects inplace (but with correctly recentred POO's) would be handy when building levels; it's pain in the arse to keep having to pull everything to the grid centre making sure you don't screw up the position of each section, an option to export in place would mean not having to do any of that *looks at Goofos with a Spock like raised eyebrow in question*

Goofos · **Posted:** Wed Aug 29, 2007 12:44 am

OrbWeaver wrote:

me.transform(obj.matrix) which (I assume) applies the transformation of the object to the mesh data itself -- however, this transformation would include the location as well as the rotation and scale parameters, essentially applying the object's translation value to the contained mesh data, which is not what is needed when exporting a single object.

Yes, it applies loc/rot/scale to the mesh data. In earlier script versions this was an optional option. Later i discovered that the mesh data is transformed in ASE files but the object still has the loc/rot/scale informations.

If you comment that line out, it basically use the local mesh data without loc/rot/scale but it still write the transformation infos to the ase file and would have a negative transformation when importing the ase file in apps which care about loc/rot/scale. I think usually you would need to change some more lines in the script so it don't export the original transform infos. But i'm currently unsure which lines (at least some lines in def mesh_matrix).

kat wrote:

I wonder if this could be added as an export option? Being able to export objects inplace (but with correctly recentred POO's) would be handy when building levels; it's pain in the arse to keep having to pull everything to the grid centre making sure you don't screw up the position of each section, an option to export in place would mean not having to do any of that *looks at Goofos with a Spock like raised eyebrow in question*

I think i don't got it. :> You mean export each object moved to world origin, or export each object with its origin moved to the world origin?

kat · **Posted:** Wed Aug 29, 2007 1:30 am

Goofos wrote:

...I think i don't got it. :> You mean export each object moved to world origin, or export each object with its origin moved to the world origin?

Soory Goofos.. what I mean was this... say you design a level (as I've been doing) and in order to export it and make it efficient with the engine it has to be cut up into segments. Normally each of these segments needs both the mesh and the segments centre to bo placed over the 000 grid point, that means each piece has to be moved which runs the risk of messing up the alignment with other segments.

What would be ideal is if you could correctly position the segments centre where it was originally and have the mesh export from there - unless I'm missing something in the new code the mesh gets exported with the polygons positioned where they were but the objects centre in then placed at 000, is that right? What you'd want on a big mesh cut into many segments is to leave them where they are and just repostion the origin locally and export like that.

Does that make sense?

sparhawk · **Joined:** Wed Sep 08, 2004 7:48 am **Posts:** 554

Not sure if I understand it correctly, but an option that could specify wether you want the object to be exported as residing a 0,0,0 or stay where it is would be very usefull.

Normally, I would like my objects to be at the centerpoint. When I model, then I often enough break them up into individual models and align them properly. In this case the models should stay relativ to where they are, because otherwise they would end up all at the centerpoint instead of making a bigger model.

In some cases I model stuff together in one file, which are still individual usable models though. Of course I can use different layers, but there is a limit to that, so I often enough move them out of the way. In such a case it would be usefull to export all the models as centerpoint models. This could be simply a toggle on the export dialog, which adjusts the matrix accordingly.

Mordenkainen · **Posted:** Fri Jul 27, 2007 7:19 pm

ratty redemption wrote:

mordenkainen, if you split the model in say 4 sections, does it take a quarter of the time to export one section? this is something I've been wondering about with some of my tests. there seems to be a threshold (could be ram related?) although I'm not sure yet what the verts/poly count threshold is yet, and whether it is a restriction of our systems or blender and goofos's .script

The same model at 30K takes around 5 mins. At 130K it takes 2 hours. Didn't experiment splitting it though.

Goofos: Thanks, dinner first but I'll try it and then report back.

Mordenkainen · **Posted:** Fri Jul 27, 2007 8:54 pm

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

ratty redemption · **Posted:** Fri Jul 27, 2007 8:57 pm

cool, I'll test this later tonight, and thanks mordenkainen for ul the file. that is easier then copy/paste the script from the forum here.

Goofos · **Posted:** Sat Jul 28, 2007 2:04 pm

Mordenkainen wrote:

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

(BTW quickly added support for multiple uv layers :> )

Please test the updated v0.6.9 script if uv and vcolor is exported right.

Mordenkainen · **Posted:** Sat Jul 28, 2007 10:32 pm

Goofos wrote:

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

130K poly version now takes 13 minutes. Export worked nicely. Great job man.

EDIT: 0.6.9 version uploaded here.

Goofos · **Posted:** Sun Jul 29, 2007 10:16 am

13 min? Hrmz, i have no idea where else i could search for lame code in the script.

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

If you track the progressbar, when does the script completely hang for a good while?

Mordenkainen · **Posted:** Mon Jul 30, 2007 8:24 pm

Goofos wrote:

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

Yeah. Do you want me to upload my model somewhere so you can see if there's anything wrong with it?

Quote:

If you track the progressbar, when does the script completely hang for a good while?

Most of the time is spent during "Writing Faces".

ratty redemption · **Posted:** Tue Jul 31, 2007 1:26 pm

goofos, sorry I didn't get to back to you earlier on this but I have just exported a high poly mesh a few times with uv's and vertex color, heres the console report.

Code:

Verts: 263169 Tris: 524288 Faces: 262144
Successfully exported temp.ase in 146.48 seconds 

which I think is truly amazing how much you've optimized your code

Mordenkainen · **Posted:** Wed Aug 01, 2007 4:08 pm

Mordenkainen wrote:

I precompiled the Python API during its installation it but Blender's own python scripts (including this exporter) aren't precompiled. Anyway I can precompile these too?

Yep, answering myself.

After some persistant searching I've found a way to precompile Blender's Python scripts too. I haven't experienced any noticeable perf increase but if you want to try it paste the following to Blender's Script editor and execute. Replace the path file with the one you installed Blender to, obviously:

Code:

import compileall

compileall.compile_dir('C:\Programs\Blender\.blender\scripts', force=True)

hyp3rfocus · **Joined:** Sun Jul 29, 2007 10:13 pm **Posts:** 7

edit- post deleted.

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

I have identified the cause of the mesh's coordinates being written relative to the world origin rather than the mesh object's own origin:

Code:

      me = Mesh.New()      # Create a new mesh

      if guiTable['MOD'] == 1:   # Use modified mesh
         me.getFromObject(obj.name, 0) # Get the object's mesh data, cage 0 = apply mod
      else:
         me.getFromObject(obj.name, 1)

      me.transform(obj.matrix)   #ASE stores transformed mesh data
      tempObj = Blender.Object.New('Mesh', 'ASE_export_temp_obj')
      tempObj.setMatrix(obj.matrix)
      tempObj.link(me)

What I assume this is doing (not being a Blender Python expert myself) is creating a new mesh object, copying the mesh data from the selected mesh into this new object, and then setting the new object to have the same transformation as the previous object (basically a deep copy of the mesh being exported).

The problem is the line me.transform(obj.matrix) which (I assume) applies the transformation of the object to the mesh data itself -- however, this transformation would include the location as well as the rotation and scale parameters, essentially applying the object's translation value to the contained mesh data, which is not what is needed when exporting a single object.

I assume that the purpose of this line is to avoid the user having to use Ctrl-A to apply size/rotation before exporting? Personally I would prefer to have to do this manually rather than having the translation applied to the mesh as well.

kat · **Posted:** Mon Aug 27, 2007 12:06 pm

I just re-read the problem you were having, am I right in assuming that you're basically centring the objects origin and then trying to export the mesh when it's not centred on the 000 grid origin? (so the objects centre is relative to where the object is on the grid?)

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

Yes -- the object's own centre point is correct, but is not aligned with the world center (0, 0, 0). With the script as written, the exported object's centre point is aligned with the world origin (0, 0, 0) and ignores the object's own centre point. With the problematic line commented out, it works as expected.

kat · **Posted:** Tue Aug 28, 2007 12:26 pm

I wonder if this could be added as an export option? Being able to export objects inplace (but with correctly recentred POO's) would be handy when building levels; it's pain in the arse to keep having to pull everything to the grid centre making sure you don't screw up the position of each section, an option to export in place would mean not having to do any of that *looks at Goofos with a Spock like raised eyebrow in question*

Goofos · **Posted:** Wed Aug 29, 2007 12:44 am

OrbWeaver wrote:

me.transform(obj.matrix) which (I assume) applies the transformation of the object to the mesh data itself -- however, this transformation would include the location as well as the rotation and scale parameters, essentially applying the object's translation value to the contained mesh data, which is not what is needed when exporting a single object.

Yes, it applies loc/rot/scale to the mesh data. In earlier script versions this was an optional option. Later i discovered that the mesh data is transformed in ASE files but the object still has the loc/rot/scale informations.

If you comment that line out, it basically use the local mesh data without loc/rot/scale but it still write the transformation infos to the ase file and would have a negative transformation when importing the ase file in apps which care about loc/rot/scale. I think usually you would need to change some more lines in the script so it don't export the original transform infos. But i'm currently unsure which lines (at least some lines in def mesh_matrix).

kat wrote:

I wonder if this could be added as an export option? Being able to export objects inplace (but with correctly recentred POO's) would be handy when building levels; it's pain in the arse to keep having to pull everything to the grid centre making sure you don't screw up the position of each section, an option to export in place would mean not having to do any of that *looks at Goofos with a Spock like raised eyebrow in question*

I think i don't got it. :> You mean export each object moved to world origin, or export each object with its origin moved to the world origin?

kat · **Posted:** Wed Aug 29, 2007 1:30 am

Goofos wrote:

...I think i don't got it. :> You mean export each object moved to world origin, or export each object with its origin moved to the world origin?

Soory Goofos.. what I mean was this... say you design a level (as I've been doing) and in order to export it and make it efficient with the engine it has to be cut up into segments. Normally each of these segments needs both the mesh and the segments centre to bo placed over the 000 grid point, that means each piece has to be moved which runs the risk of messing up the alignment with other segments.

What would be ideal is if you could correctly position the segments centre where it was originally and have the mesh export from there - unless I'm missing something in the new code the mesh gets exported with the polygons positioned where they were but the objects centre in then placed at 000, is that right? What you'd want on a big mesh cut into many segments is to leave them where they are and just repostion the origin locally and export like that.

Does that make sense?

sparhawk · **Joined:** Wed Sep 08, 2004 7:48 am **Posts:** 554

Not sure if I understand it correctly, but an option that could specify wether you want the object to be exported as residing a 0,0,0 or stay where it is would be very usefull.

Normally, I would like my objects to be at the centerpoint. When I model, then I often enough break them up into individual models and align them properly. In this case the models should stay relativ to where they are, because otherwise they would end up all at the centerpoint instead of making a bigger model.

In some cases I model stuff together in one file, which are still individual usable models though. Of course I can use different layers, but there is a limit to that, so I often enough move them out of the way. In such a case it would be usefull to export all the models as centerpoint models. This could be simply a toggle on the export dialog, which adjusts the matrix accordingly.

Mordenkainen · **Posted:** Fri Jul 27, 2007 7:19 pm

ratty redemption wrote:

mordenkainen, if you split the model in say 4 sections, does it take a quarter of the time to export one section? this is something I've been wondering about with some of my tests. there seems to be a threshold (could be ram related?) although I'm not sure yet what the verts/poly count threshold is yet, and whether it is a restriction of our systems or blender and goofos's .script

The same model at 30K takes around 5 mins. At 130K it takes 2 hours. Didn't experiment splitting it though.

Goofos: Thanks, dinner first but I'll try it and then report back.

Mordenkainen · **Posted:** Fri Jul 27, 2007 8:54 pm

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

ratty redemption · **Posted:** Fri Jul 27, 2007 8:57 pm

cool, I'll test this later tonight, and thanks mordenkainen for ul the file. that is easier then copy/paste the script from the forum here.

Goofos · **Posted:** Sat Jul 28, 2007 2:04 pm

Mordenkainen wrote:

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

(BTW quickly added support for multiple uv layers :> )

Please test the updated v0.6.9 script if uv and vcolor is exported right.

Mordenkainen · **Posted:** Sat Jul 28, 2007 10:32 pm

Goofos wrote:

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

130K poly version now takes 13 minutes. Export worked nicely. Great job man.

EDIT: 0.6.9 version uploaded here.

Goofos · **Posted:** Sun Jul 29, 2007 10:16 am

13 min? Hrmz, i have no idea where else i could search for lame code in the script.

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

If you track the progressbar, when does the script completely hang for a good while?

Mordenkainen · **Posted:** Mon Jul 30, 2007 8:24 pm

Goofos wrote:

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

Yeah. Do you want me to upload my model somewhere so you can see if there's anything wrong with it?

Quote:

If you track the progressbar, when does the script completely hang for a good while?

Most of the time is spent during "Writing Faces".

ratty redemption · **Posted:** Tue Jul 31, 2007 1:26 pm

goofos, sorry I didn't get to back to you earlier on this but I have just exported a high poly mesh a few times with uv's and vertex color, heres the console report.

Code:

Verts: 263169 Tris: 524288 Faces: 262144
Successfully exported temp.ase in 146.48 seconds 

which I think is truly amazing how much you've optimized your code

Mordenkainen · **Posted:** Wed Aug 01, 2007 4:08 pm

Mordenkainen wrote:

I precompiled the Python API during its installation it but Blender's own python scripts (including this exporter) aren't precompiled. Anyway I can precompile these too?

Yep, answering myself.

After some persistant searching I've found a way to precompile Blender's Python scripts too. I haven't experienced any noticeable perf increase but if you want to try it paste the following to Blender's Script editor and execute. Replace the path file with the one you installed Blender to, obviously:

Code:

import compileall

compileall.compile_dir('C:\Programs\Blender\.blender\scripts', force=True)

hyp3rfocus · **Joined:** Sun Jul 29, 2007 10:13 pm **Posts:** 7

edit- post deleted.

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

I have identified the cause of the mesh's coordinates being written relative to the world origin rather than the mesh object's own origin:

Code:

      me = Mesh.New()      # Create a new mesh

      if guiTable['MOD'] == 1:   # Use modified mesh
         me.getFromObject(obj.name, 0) # Get the object's mesh data, cage 0 = apply mod
      else:
         me.getFromObject(obj.name, 1)

      me.transform(obj.matrix)   #ASE stores transformed mesh data
      tempObj = Blender.Object.New('Mesh', 'ASE_export_temp_obj')
      tempObj.setMatrix(obj.matrix)
      tempObj.link(me)

What I assume this is doing (not being a Blender Python expert myself) is creating a new mesh object, copying the mesh data from the selected mesh into this new object, and then setting the new object to have the same transformation as the previous object (basically a deep copy of the mesh being exported).

The problem is the line me.transform(obj.matrix) which (I assume) applies the transformation of the object to the mesh data itself -- however, this transformation would include the location as well as the rotation and scale parameters, essentially applying the object's translation value to the contained mesh data, which is not what is needed when exporting a single object.

I assume that the purpose of this line is to avoid the user having to use Ctrl-A to apply size/rotation before exporting? Personally I would prefer to have to do this manually rather than having the translation applied to the mesh as well.

kat · **Posted:** Mon Aug 27, 2007 12:06 pm

I just re-read the problem you were having, am I right in assuming that you're basically centring the objects origin and then trying to export the mesh when it's not centred on the 000 grid origin? (so the objects centre is relative to where the object is on the grid?)

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

Yes -- the object's own centre point is correct, but is not aligned with the world center (0, 0, 0). With the script as written, the exported object's centre point is aligned with the world origin (0, 0, 0) and ignores the object's own centre point. With the problematic line commented out, it works as expected.

kat · **Posted:** Tue Aug 28, 2007 12:26 pm

I wonder if this could be added as an export option? Being able to export objects inplace (but with correctly recentred POO's) would be handy when building levels; it's pain in the arse to keep having to pull everything to the grid centre making sure you don't screw up the position of each section, an option to export in place would mean not having to do any of that *looks at Goofos with a Spock like raised eyebrow in question*

Goofos · **Posted:** Wed Aug 29, 2007 12:44 am

OrbWeaver wrote:

me.transform(obj.matrix) which (I assume) applies the transformation of the object to the mesh data itself -- however, this transformation would include the location as well as the rotation and scale parameters, essentially applying the object's translation value to the contained mesh data, which is not what is needed when exporting a single object.

Yes, it applies loc/rot/scale to the mesh data. In earlier script versions this was an optional option. Later i discovered that the mesh data is transformed in ASE files but the object still has the loc/rot/scale informations.

If you comment that line out, it basically use the local mesh data without loc/rot/scale but it still write the transformation infos to the ase file and would have a negative transformation when importing the ase file in apps which care about loc/rot/scale. I think usually you would need to change some more lines in the script so it don't export the original transform infos. But i'm currently unsure which lines (at least some lines in def mesh_matrix).

kat wrote:

I wonder if this could be added as an export option? Being able to export objects inplace (but with correctly recentred POO's) would be handy when building levels; it's pain in the arse to keep having to pull everything to the grid centre making sure you don't screw up the position of each section, an option to export in place would mean not having to do any of that *looks at Goofos with a Spock like raised eyebrow in question*

I think i don't got it. :> You mean export each object moved to world origin, or export each object with its origin moved to the world origin?

kat · **Posted:** Wed Aug 29, 2007 1:30 am

Goofos wrote:

...I think i don't got it. :> You mean export each object moved to world origin, or export each object with its origin moved to the world origin?

Soory Goofos.. what I mean was this... say you design a level (as I've been doing) and in order to export it and make it efficient with the engine it has to be cut up into segments. Normally each of these segments needs both the mesh and the segments centre to bo placed over the 000 grid point, that means each piece has to be moved which runs the risk of messing up the alignment with other segments.

What would be ideal is if you could correctly position the segments centre where it was originally and have the mesh export from there - unless I'm missing something in the new code the mesh gets exported with the polygons positioned where they were but the objects centre in then placed at 000, is that right? What you'd want on a big mesh cut into many segments is to leave them where they are and just repostion the origin locally and export like that.

Does that make sense?

sparhawk · **Joined:** Wed Sep 08, 2004 7:48 am **Posts:** 554

Not sure if I understand it correctly, but an option that could specify wether you want the object to be exported as residing a 0,0,0 or stay where it is would be very usefull.

Normally, I would like my objects to be at the centerpoint. When I model, then I often enough break them up into individual models and align them properly. In this case the models should stay relativ to where they are, because otherwise they would end up all at the centerpoint instead of making a bigger model.

In some cases I model stuff together in one file, which are still individual usable models though. Of course I can use different layers, but there is a limit to that, so I often enough move them out of the way. In such a case it would be usefull to export all the models as centerpoint models. This could be simply a toggle on the export dialog, which adjusts the matrix accordingly.

Mordenkainen · **Posted:** Fri Jul 27, 2007 7:19 pm

ratty redemption wrote:

mordenkainen, if you split the model in say 4 sections, does it take a quarter of the time to export one section? this is something I've been wondering about with some of my tests. there seems to be a threshold (could be ram related?) although I'm not sure yet what the verts/poly count threshold is yet, and whether it is a restriction of our systems or blender and goofos's .script

The same model at 30K takes around 5 mins. At 130K it takes 2 hours. Didn't experiment splitting it though.

Goofos: Thanks, dinner first but I'll try it and then report back.

Mordenkainen · **Posted:** Fri Jul 27, 2007 8:54 pm

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

ratty redemption · **Posted:** Fri Jul 27, 2007 8:57 pm

cool, I'll test this later tonight, and thanks mordenkainen for ul the file. that is easier then copy/paste the script from the forum here.

Goofos · **Posted:** Sat Jul 28, 2007 2:04 pm

Mordenkainen wrote:

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

(BTW quickly added support for multiple uv layers :> )

Please test the updated v0.6.9 script if uv and vcolor is exported right.

Mordenkainen · **Posted:** Sat Jul 28, 2007 10:32 pm

Goofos wrote:

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

130K poly version now takes 13 minutes. Export worked nicely. Great job man.

EDIT: 0.6.9 version uploaded here.

Goofos · **Posted:** Sun Jul 29, 2007 10:16 am

13 min? Hrmz, i have no idea where else i could search for lame code in the script.

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

If you track the progressbar, when does the script completely hang for a good while?

Mordenkainen · **Posted:** Mon Jul 30, 2007 8:24 pm

Goofos wrote:

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

Yeah. Do you want me to upload my model somewhere so you can see if there's anything wrong with it?

Quote:

If you track the progressbar, when does the script completely hang for a good while?

Most of the time is spent during "Writing Faces".

ratty redemption · **Posted:** Tue Jul 31, 2007 1:26 pm

goofos, sorry I didn't get to back to you earlier on this but I have just exported a high poly mesh a few times with uv's and vertex color, heres the console report.

Code:

Verts: 263169 Tris: 524288 Faces: 262144
Successfully exported temp.ase in 146.48 seconds 

which I think is truly amazing how much you've optimized your code

Mordenkainen · **Posted:** Wed Aug 01, 2007 4:08 pm

Mordenkainen wrote:

I precompiled the Python API during its installation it but Blender's own python scripts (including this exporter) aren't precompiled. Anyway I can precompile these too?

Yep, answering myself.

After some persistant searching I've found a way to precompile Blender's Python scripts too. I haven't experienced any noticeable perf increase but if you want to try it paste the following to Blender's Script editor and execute. Replace the path file with the one you installed Blender to, obviously:

Code:

import compileall

compileall.compile_dir('C:\Programs\Blender\.blender\scripts', force=True)

hyp3rfocus · **Joined:** Sun Jul 29, 2007 10:13 pm **Posts:** 7

edit- post deleted.

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

I have identified the cause of the mesh's coordinates being written relative to the world origin rather than the mesh object's own origin:

Code:

      me = Mesh.New()      # Create a new mesh

      if guiTable['MOD'] == 1:   # Use modified mesh
         me.getFromObject(obj.name, 0) # Get the object's mesh data, cage 0 = apply mod
      else:
         me.getFromObject(obj.name, 1)

      me.transform(obj.matrix)   #ASE stores transformed mesh data
      tempObj = Blender.Object.New('Mesh', 'ASE_export_temp_obj')
      tempObj.setMatrix(obj.matrix)
      tempObj.link(me)

What I assume this is doing (not being a Blender Python expert myself) is creating a new mesh object, copying the mesh data from the selected mesh into this new object, and then setting the new object to have the same transformation as the previous object (basically a deep copy of the mesh being exported).

The problem is the line me.transform(obj.matrix) which (I assume) applies the transformation of the object to the mesh data itself -- however, this transformation would include the location as well as the rotation and scale parameters, essentially applying the object's translation value to the contained mesh data, which is not what is needed when exporting a single object.

I assume that the purpose of this line is to avoid the user having to use Ctrl-A to apply size/rotation before exporting? Personally I would prefer to have to do this manually rather than having the translation applied to the mesh as well.

kat · **Posted:** Mon Aug 27, 2007 12:06 pm

I just re-read the problem you were having, am I right in assuming that you're basically centring the objects origin and then trying to export the mesh when it's not centred on the 000 grid origin? (so the objects centre is relative to where the object is on the grid?)

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

Yes -- the object's own centre point is correct, but is not aligned with the world center (0, 0, 0). With the script as written, the exported object's centre point is aligned with the world origin (0, 0, 0) and ignores the object's own centre point. With the problematic line commented out, it works as expected.

kat · **Posted:** Tue Aug 28, 2007 12:26 pm

I wonder if this could be added as an export option? Being able to export objects inplace (but with correctly recentred POO's) would be handy when building levels; it's pain in the arse to keep having to pull everything to the grid centre making sure you don't screw up the position of each section, an option to export in place would mean not having to do any of that *looks at Goofos with a Spock like raised eyebrow in question*

Goofos · **Posted:** Wed Aug 29, 2007 12:44 am

OrbWeaver wrote:

me.transform(obj.matrix) which (I assume) applies the transformation of the object to the mesh data itself -- however, this transformation would include the location as well as the rotation and scale parameters, essentially applying the object's translation value to the contained mesh data, which is not what is needed when exporting a single object.

Yes, it applies loc/rot/scale to the mesh data. In earlier script versions this was an optional option. Later i discovered that the mesh data is transformed in ASE files but the object still has the loc/rot/scale informations.

If you comment that line out, it basically use the local mesh data without loc/rot/scale but it still write the transformation infos to the ase file and would have a negative transformation when importing the ase file in apps which care about loc/rot/scale. I think usually you would need to change some more lines in the script so it don't export the original transform infos. But i'm currently unsure which lines (at least some lines in def mesh_matrix).

kat wrote:

I wonder if this could be added as an export option? Being able to export objects inplace (but with correctly recentred POO's) would be handy when building levels; it's pain in the arse to keep having to pull everything to the grid centre making sure you don't screw up the position of each section, an option to export in place would mean not having to do any of that *looks at Goofos with a Spock like raised eyebrow in question*

I think i don't got it. :> You mean export each object moved to world origin, or export each object with its origin moved to the world origin?

kat · **Posted:** Wed Aug 29, 2007 1:30 am

Goofos wrote:

...I think i don't got it. :> You mean export each object moved to world origin, or export each object with its origin moved to the world origin?

Soory Goofos.. what I mean was this... say you design a level (as I've been doing) and in order to export it and make it efficient with the engine it has to be cut up into segments. Normally each of these segments needs both the mesh and the segments centre to bo placed over the 000 grid point, that means each piece has to be moved which runs the risk of messing up the alignment with other segments.

What would be ideal is if you could correctly position the segments centre where it was originally and have the mesh export from there - unless I'm missing something in the new code the mesh gets exported with the polygons positioned where they were but the objects centre in then placed at 000, is that right? What you'd want on a big mesh cut into many segments is to leave them where they are and just repostion the origin locally and export like that.

Does that make sense?

sparhawk · **Joined:** Wed Sep 08, 2004 7:48 am **Posts:** 558

Not sure if I understand it correctly, but an option that could specify wether you want the object to be exported as residing a 0,0,0 or stay where it is would be very usefull.

Normally, I would like my objects to be at the centerpoint. When I model, then I often enough break them up into individual models and align them properly. In this case the models should stay relativ to where they are, because otherwise they would end up all at the centerpoint instead of making a bigger model.

In some cases I model stuff together in one file, which are still individual usable models though. Of course I can use different layers, but there is a limit to that, so I often enough move them out of the way. In such a case it would be usefull to export all the models as centerpoint models. This could be simply a toggle on the export dialog, which adjusts the matrix accordingly.

Mordenkainen · **Posted:** Fri Jul 27, 2007 7:19 pm

ratty redemption wrote:

mordenkainen, if you split the model in say 4 sections, does it take a quarter of the time to export one section? this is something I've been wondering about with some of my tests. there seems to be a threshold (could be ram related?) although I'm not sure yet what the verts/poly count threshold is yet, and whether it is a restriction of our systems or blender and goofos's .script

The same model at 30K takes around 5 mins. At 130K it takes 2 hours. Didn't experiment splitting it though.

Goofos: Thanks, dinner first but I'll try it and then report back.

Mordenkainen · **Posted:** Fri Jul 27, 2007 8:54 pm

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

ratty redemption · **Posted:** Fri Jul 27, 2007 8:57 pm

cool, I'll test this later tonight, and thanks mordenkainen for ul the file. that is easier then copy/paste the script from the forum here.

Goofos · **Posted:** Sat Jul 28, 2007 2:04 pm

Mordenkainen wrote:

Excellent work Goofos. 30K poly version now takes 50 seconds and the 130K one only takes 19 minutes! I also did a quick test and it appears the export worked correctly so a big thank you!

Btw, if anyone wants to download the script file instead of copy/paste get it here.

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

(BTW quickly added support for multiple uv layers :> )

Please test the updated v0.6.9 script if uv and vcolor is exported right.

Mordenkainen · **Posted:** Sat Jul 28, 2007 10:32 pm

Goofos wrote:

19 min still is a bit to slow therefore i looked too into the uv (and vcolor) part of the script and rewrote/optimised this. I think now exporting a highpoly mesh should not need more than a minute.

130K poly version now takes 13 minutes. Export worked nicely. Great job man.

EDIT: 0.6.9 version uploaded here.

Goofos · **Posted:** Sun Jul 29, 2007 10:16 am

13 min? Hrmz, i have no idea where else i could search for lame code in the script.

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

If you track the progressbar, when does the script completely hang for a good while?

Mordenkainen · **Posted:** Mon Jul 30, 2007 8:24 pm

Goofos wrote:

I exported a mesh with 266766 verts, 531456 tris (265728 faces), two UV layers and some vcolors in 114 seconds with an old Athlon XP 3200 and 512 MB Ram. Usually i would think your PC should be faster.

Yeah. Do you want me to upload my model somewhere so you can see if there's anything wrong with it?

Quote:

If you track the progressbar, when does the script completely hang for a good while?

Most of the time is spent during "Writing Faces".

ratty redemption · **Posted:** Tue Jul 31, 2007 1:26 pm

goofos, sorry I didn't get to back to you earlier on this but I have just exported a high poly mesh a few times with uv's and vertex color, heres the console report.

Code:

Verts: 263169 Tris: 524288 Faces: 262144
Successfully exported temp.ase in 146.48 seconds 

which I think is truly amazing how much you've optimized your code

Mordenkainen · **Posted:** Wed Aug 01, 2007 4:08 pm

Mordenkainen wrote:

I precompiled the Python API during its installation it but Blender's own python scripts (including this exporter) aren't precompiled. Anyway I can precompile these too?

Yep, answering myself.

After some persistant searching I've found a way to precompile Blender's Python scripts too. I haven't experienced any noticeable perf increase but if you want to try it paste the following to Blender's Script editor and execute. Replace the path file with the one you installed Blender to, obviously:

Code:

import compileall

compileall.compile_dir('C:\Programs\Blender\.blender\scripts', force=True)

hyp3rfocus · **Joined:** Sun Jul 29, 2007 10:13 pm **Posts:** 7

edit- post deleted.

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

I have identified the cause of the mesh's coordinates being written relative to the world origin rather than the mesh object's own origin:

Code:

      me = Mesh.New()      # Create a new mesh

      if guiTable['MOD'] == 1:   # Use modified mesh
         me.getFromObject(obj.name, 0) # Get the object's mesh data, cage 0 = apply mod
      else:
         me.getFromObject(obj.name, 1)

      me.transform(obj.matrix)   #ASE stores transformed mesh data
      tempObj = Blender.Object.New('Mesh', 'ASE_export_temp_obj')
      tempObj.setMatrix(obj.matrix)
      tempObj.link(me)

What I assume this is doing (not being a Blender Python expert myself) is creating a new mesh object, copying the mesh data from the selected mesh into this new object, and then setting the new object to have the same transformation as the previous object (basically a deep copy of the mesh being exported).

The problem is the line me.transform(obj.matrix) which (I assume) applies the transformation of the object to the mesh data itself -- however, this transformation would include the location as well as the rotation and scale parameters, essentially applying the object's translation value to the contained mesh data, which is not what is needed when exporting a single object.

I assume that the purpose of this line is to avoid the user having to use Ctrl-A to apply size/rotation before exporting? Personally I would prefer to have to do this manually rather than having the translation applied to the mesh as well.

kat · **Posted:** Mon Aug 27, 2007 12:06 pm

I just re-read the problem you were having, am I right in assuming that you're basically centring the objects origin and then trying to export the mesh when it's not centred on the 000 grid origin? (so the objects centre is relative to where the object is on the grid?)

OrbWeaver · **Joined:** Tue May 24, 2005 7:41 pm **Posts:** 343

Yes -- the object's own centre point is correct, but is not aligned with the world center (0, 0, 0). With the script as written, the exported object's centre point is aligned with the world origin (0, 0, 0) and ignores the object's own centre point. With the problematic line commented out, it works as expected.

Doom3world

new ASE Exporter

Doom3world

new ASE Exporter

Doom3world

new ASE Exporter

Doom3world

new ASE Exporter

Doom3world

new ASE Exporter

Doom3world

new ASE Exporter

Doom3world

new ASE Exporter

Doom3world

new ASE Exporter

Doom3world

new ASE Exporter

Doom3world

new ASE Exporter

Doom3world

new ASE Exporter

Doom3world

new ASE Exporter

Doom3world

new ASE Exporter

Doom3world

new ASE Exporter