I'd support Introversion just on the basis of your awesome games, but it's your continued commitment to Linux that's really cemented your position as my favorite development studio. Keep up the good work.

Hi everyone! Sorry I vanished from the face of the earth like that. There were some personal issues, then other projects caught my interest. There's been a lot of constructive feedback on the exporter, and I'm willing to poke at it a bit more, if people are still interested (and if I can figure out ...

Thanks for the info, Brice. Real life's been a real pain lately, hopefully I'll have time to work on the scripts some more soon. Only a couple more weeks of school, but hopefully I'll have free time again before that.

Testrie wrote:Yes, I was well aware of the fact that I didn't need blender to use the script...

You do need Blender, you just don't need to actually understand the script. If you want to learn, there are several good sites. http://mediawiki.blender.org is good starting point.

I should be able to apply scale factors pretty easily, but that's another multiplication in what, as you say, is already a slow script. I'll definately add the WaitCursor() calls, though. I may be able to add other optimisations - perhaps keeping more stuff in the string before the write() calls. I ...

To any mod or admin: Please sticky this. Thanks in advance. Current Exporter Version: 1.0.1 Current Importer Version: None I recommend saving these scripts as shape_export.py and shape_import.py . Place them in your Blender scripts location (The exact location varies, sorry). They should show up as ...

I'd like to keep the initial importer talk here, so the other thread doesn't get too big too fast. Once the importer is stable, we can move it there as well.

I found the bug... It had nothing to do with the 'front' and 'up' vectors at all... I had a rather stupid bug on line 205: pos = new_shp.addPosition(f.verts[i].co.x,f.verts[i].co.z,f.verts[i].co.y) See the bug? It should be: pos = new_shp.addPosition(-1.0*f.verts[i].co.x,f.verts[i].co.z,...

We're working from different angles... Z Y Y | Y | X | Z | / | / | / |/ |/ |/ 0---X 0---Z X---0 (Blender) (Darwinia) (Darwinia) (Me) (You) Either way, it looks like there's an issue with an object that is both translated and rotated. If what I've seen the expo...

My brain hurts. But I have gotten it working with the standard header. Translation and rotation work brilliantly. Empties are still the only way to make markers, I'll work on mesh-based markers soon. The y-axis is front, and the z-axis is up. I'm still deciding on exactly how I want to fix the color...

Up and front are still hardcoded, yes. I'm waiting until I can sit in front of a box with both Blender and Darwinia to work on that bit. And you do have something out of sync - the translations of the object also need to be swizzled. I'll fix the last entry to match your new swizzling in all locatio...

OK, another test. No change to the up/front vectors, but the swizzling has changed. Same code as before...

I thought you meant linked as in 'not made real'. I'd like to support that, but it would be a lot of work... In other news, I've got another test build. This should create a mesh that appears exactly as it did before, but with different Front/Up vectors and no swizzling of the vertices. Also, please...

I'm not certain if I can use linked duplicates. I'll have to examine the API a bit more. On an entirely different subject, I think I know how the front, up, and pos vectors map to a transformation matrix... Something like this: [[Fx,*x,Ux,Px] [Fy,*y,Uy,Py] [Fz,*z,Uz,Pz] [00,00,00,01]] The numbers la...

That will work nicely, so long as there is a standard mesh name for the marker mesh - something like 'Marker'. The workflow would end up something like: ⋅ Create your circle, or whatever other shape you want ⋅ Create your object. Give it whatever object name you feel, and a mesh ...