Static model import/export for Blender: development

[674307b9b9001nemyax]

makes a texture/material double sided?

I'd use Blender's Solidify modifier with zero thickness and the Fill Rim option disabled. Prompting the old converter to do a double-sided model is just another trick. In the raw .bin, you actually get duplicate polygons with opposing normals, so let Blender take care of it.

[674307b9b9356Olfred]

I usually just do the double sided polygons by hand. Makes it even easier to sort out any issues with polygon sorting.

[674307b9b9511Daraan]

Any possibility that you could add an option to keep the origin at the current origin.
So the offset is calculated from there instead of the other alternative word origin.

This would really help with combinable objects like treetrunk+branches, until now I would have to move the bbox center to word origin and the branches accordingly.
This is a bit messy if you (like i do^^) have about 10-20 objects in one blend file.

[674307b9b979fnemyax]

an option to keep the origin at the current origin

If you clear the Model origin is at world origin option, doesn't that do the trick?

[674307b9b98bdOlfred]

Alternatively you could just move the model to world origin, that will move the whole thing to the center.

And you don't need the bbox. It's when you want to have a custom bounding box for the ingame view (the brackets).
If you don't have one, the exporter will create an apropiate one.

[674307b9b9b63Daraan]

If you clear the Model origin is at world origin option, doesn't that do the trick?

I mostly leave it unchecked to have the origin at the center of the geometry but sometimes I would like to have an offset -> so that the origin is at the in blender defined object origin.
In NV's or endir's exporter there is an option like this, either use the geometry center or the defined one.

@Olfred: As said moving to world origin is want to avoid, it's a mess.
Was just using bbox as a abbreviation for the Box not the included feature here

[674307b9b9cbeOlfred]

Why is moving it to the world origin a mess?

Can you upload the model you have problems with so we can take a look at it and come up with a possible solution?

And I just remembered, if you don't us the world origin the exporter uses the model center.
Or to be more specific. The Dark Engine uses the model center as origin. If you want to have a custom origin you have to add some "fake vertices" in the exported model to have another origin. This is what happens when you check the box to have the world origin as center.
Just to say it in advance, adding vertices manually doesn't work as the exporter ignores anything which isn't a proper polygon.

[674307b9b9df7Daraan]

it's not one model it's a few.
Which have separate parts because the poly amount would be to high.

To combine them again in the editor, the easiest way is to place the parts at the same location and due to the same origin they would fit perfectly.
If it would be just one model I wouldn't bother moving them to world origin. But doing that for about 20(+), that's the mess I'm talking about.
Other option would be using vhots but it's more work and less easier to use for authors.

I'll finish another project first but I'm already thinking ahead since the other doesn't need much more work.

[674307b9b9eednemyax]

Daraan
Can you post some pictures of what you're trying to do? Blender probably has an easy way to arrange your objects.

[674307b9ba0c1Daraan]

For example like this. Branches and trunk on the left share the same origin in blender - the center of the trunk.

Exporting the branches without world origin will set the origin to the center ~yellow dot --> hard to align in the editor
With world origin set there will be the huge red arrow as offset --> not useful at all.
Moving the trunk and branches to origin for a few models = mess, also i can't group them for example in Y-direction for similar/lod objects.

What I would love to use would be an offset based on the green arrow instead of the red.

[674307b9ba1beOlfred]

Why do you want to have two trees in one model anyway?

[674307b9ba2c7nemyax]

Daraan
Why isn't the tree model group aligned properly in the centre on a dedicated layer? That would be one way to avoid the mess.

[674307b9ba649nemyax]

i can't group them

You can make a single empty their common parent. That's as good as grouping them.
And if you're trying to lay out the game scene (even though Blender is not the right tool for that), you can animate that empty away from its rest position, so that you have your export-ready geometry in frame 1 and your layout preview in frame 40, for example.

[674307b9baafeDaraan]

Why do you want to have two trees in one model anyway?

Leaves one obj
trunk one obj
together to many polys.

Daraan
Why isn't the tree model group aligned properly in the centre on a dedicated layer? That would be one way to avoid the mess.

I just opened a random file to show what. And moved everything expect 2 to the center. I just want everything to be nicely arranged and not in a single place.


I have have not really an idea about phyton and blender scripting but after a lots of trial and error I got it to work.
if I use  matrix_world.inverted as originShift I get the local origin as offset.
Thought it would be matrix_local * word_inverse, don't know but it works - just not sure if it will be correct for vhots and others.

--
Another thing I realized is that when I checked a bsp file there were a lot of unused materials included - other materials/textures I used on other meshes but not on the exported.

[674307b9bac9cvoodoo47]

how about doing the woody parts as one object and the leaves as another, and then combine them when building the level (detailattach, physattach)? would allow different alpha settings as well, for example.

[674307b9baf0aDaraan]

how about doing the woody parts as one object and the leaves as another, and then combine them when building the level (detailattach, physattach)? would allow different alpha settings as well, for example.

That's what I thought about as well. Actually I planned it that way at first until I thought it would be easier to use same origins instead of links.

[674307b9bb241nemyax]

It's an import and export tool, not a layout aid. And I would advise against tampering with the matrix multiplication, especially by trial and error. The way it's implemented now, it handles object merging, parenting and reparenting at multiple levels in two modes.

not sure if it will be correct for vhots and others

No, that'll break it.

[674307b9bb55avoodoo47]

That's what I thought about as well. Actually I planned it that way at first until I thought it would be easier to use same origins instead of links.

it would probably be for the best - we actually had a discussion about something similar some time ago, it was about a certain palm tree (stubby wooden trunk, plus a green leafy crown) in one T2 FM (Sturmdrang FM, obj 18 in miss24), and it was basically either have sharp edges on the leaves (ugly), or add transparency to fix the leaves but have them sort incorrectly vs the trunk, or make the palm tree from two separate objects (trunk and the leaves) that would be combined in the editor when building the mission which would allow smooth edged leaves that would sort properly vs the trunk.

while not an expert in the area, I believe the last option is the correct choice (the trunk could have a vhot that would allow easy attaching of the leafy crown, for example). would also allow for more precise phys collisions.

[674307b9bba79Olfred]

Leaves one obj
trunk one obj
together to many polys.

I understood that. My question is why you want to have different kind of objects in one file. Like in your example one tree with seperatedly exported trunk and leaves, and then another one with seperated trunk and leaves?

Another thing I realized is that when I checked a bsp file there were a lot of unused materials included - other materials/textures I used on other meshes but not on the exported.

As far as I know it just grabs all materials available in the file and includes them regardless of the selected model.
Usually you only have one complete model in your file you want to have exported, so that doesn't pose any problem.

[674307b9bbd13nemyax]

As far as I know it just grabs all materials available in the file and includes them regardless of the selected model.

I'll fix that. Thanks for spotting it, guys.

[674307b9bbe28Olfred]

I thought he meant the other exporter he used. With your exporter I never tested it. My models are always clean
Well almost...

[674307b9bc52eDaraan]

My question is why you want to have different kind of objects in one file.

That's just not the way I do it. I have like project-files. I would be overflowing with files else. Just finished the first part of my building collection with ~15 objects. Cycle through them, export, done. (I hope I don't spot anymore errors  )

or make the palm tree from two separate objects (trunk and the leaves) that would be combined in the editor when building the mission which would allow smooth edged leaves that would sort properly vs the trunk.
would also allow for more precise phys collisions.

Will do it like you guys want it just tried to find the most easiest way.

It's an import and export tool, not a layout aid. And I would advise against tampering with the matrix multiplication, especially by trial and error. The way it's implemented now, it handles object merging, parenting and reparenting at multiple levels in two modes.

So now I used the correct math at. Needed some time to understand, which command gives which value back.

The   turquoise is obv. only correct for single mesh objects. (expect opq would be the bounds center position but didn't see a command that gives these back)
Correct would be a transformation matrix(x,y,z) * BoundsCenter.
Like Bounds center it would be just another Transformation and the math will be fine everywhere. It will be the same values like moving it manually to (0,0,0) and then +(x,y,z)

Just wanted to finish the thought, since I just had a another situation where a very little offset was needed. Fixing it by hand would even be faster than vhots.

[674307b9bc7f2nemyax]

Update 0.3.20160511

• Optional BSP tree-based polygon sorting during export; the purpose is to ensure correct transparency. This first implementation is experimental and not very reliable, but it works for simple cases. Expect some improvements in the future, but generally, don’t use BSP sorting if you can help it.
  Image: http://pix.academ.info/images/img/2016/05/12/c63df9b5551262164822e2e1ae6651da.png
• During import, available PNG textures are loaded automatically as long as they are in standard locations.
• Unused materials are not exported.
• There’s a clear error message in the event of an exceedingly high polygon count.
  Image: http://pix.academ.info/images/img/2016/05/12/c54574032b35a0a2c9d43cfea7f7d7e1.png
• The script no longer crashes if it encounters a polygon that’s vertex-coloured instead of textured.

Download: https://sourceforge.net/projects/blenderbitsbobs/files/

[674307b9bcb19Olfred]

That are some really great improvements 

• During import, available PNG textures are loaded automatically as long as they are in standard locations.

What is considered a standard location?