Static model import/export for Blender: development

[6742ccce5eb3dOlfred]

no, I don't want it to be a bbox. I want it to just make the model bigger, but it all being invisible.
On the testing version I could just rename the bbox to something else and use only the vertices (removing the edge), so it becomes part of the model, but since it were just vertices they aren't visible ingame.
This is the trick I always used when I wanted the game to handle the model as bigger as it acutally is.
That's what I did on highsec4, and it worked.

[6742ccce5ed17nemyax]

I see. Get Update 0.1.20140603 =)
You'll need to combine the whisker mesh with the actual mesh though. Standalone no-surface whiskers/verts are still ignored.

[6742ccce5ee86Olfred]

I think to get a better base on talking about this we need some kind of new terminology. So I went ahead and just made up a new name and a littel legend for it.

So when I import a new model I get the bbox. Now I know what the game thinks how big the model is (and how it handels it).
But now when I want to get it into the game again, the new model needs to be the size of the imported bbox. When I rename it, it will become the Dimension Box, which is only there so the model keeps it old size. Basically it becomes part of the model.
The new Bounding Box gets the size of the model, so ingame the bracets are around the model.

[6742ccce5f160Olfred]

I see. Get Update 0.1.20140603 =)
You'll need to combine the whisker mesh with the actual mesh though. Standalone no-surface whiskers/verts are still ignored.

Ah, yes, this is working quite well. But I still would prefer if I could keep the Dimension Box as an seperate object. Makes it easier to work with and the tendency to screw it up are minimized.
But I could live with it this way.

[6742ccce5f299Olfred]

Discovered a bug.
I create a model with a custom bounding box but also add the edge to have a bigger dimension box.
Now when I export it as bin and then import it again, I won't get the edge.

It's probably because you only import complete faces and nothing else.

See attached model as an example

[6742ccce5f525nemyax]

It's probably because you only import complete faces and nothing else.

Exactly. The .bin format doesn't have anything else.
Not really a bug, but a flaw in the design you and I came up with =)
It wouldn't be a problem to always create the dimension edge on import, but the question is how to calculate its bounds.

[6742ccce5f624Olfred]

But somehow it's stored inside there, else the engine wouldn't know that it's bigger, right?

[6742ccce5f709nemyax]

I suppose creating an edge from the mesh's most extreme coordinates to the exact opposite coordinates would do the trick. It has to be derivative.

[6742ccce5f7fdOlfred]

That would be nice.
Yesterday I screwed up and accidently overwrote a blend file and weren't able to restore it with importing the bin file I had.
Already fixed it, but would still be nice to be able to import the models which were previously exported.

[6742ccce5f8eanemyax]

OK, I'll update the script next week. I'd say this change calls for the introduction of a dedicated "dbox" object. Just as you requested =)

[6742ccce5f9c9Olfred]

Haha, nice.
If you also take it into consideration upon exporting, than it would be another awesome update

[6742ccce5fab7nemyax]

Of course it should go both ways. I think the "grab the points, then clean up" rule should still remain, though—in case you don't want to bother with the dimension box.

[6742ccce5fb84Olfred]

Yeah, I would say with that you have everything one could whish for.
(for now )

[6742ccce5fcb1Olfred]

Now this was quicker than expected. Actually found something new already 

When I put in a vhot and parent it to an object which already has a parent, the vhot will simply get put on the base of the highest parent. (see picture)
I don't know if this is a game limitation or not, so could you take a look at it, please?

[6742ccce5fe27nemyax]

When I import the .bin, the hierarchy in it is identical to that in the source .blend. So if there's a problem, it runs pretty deep. I'll keep looking, but I'm suspecting an engine quirk.

[6742ccce5ffa7nemyax]

Olfred
I've been thinking about boxes (no, that's not what she said), and it looks like a dimension box is the wrong tool for the job. Come to think of it, you only use the dimension box to (indirectly) set the origin of the model. All of the box's other characteristics are lost during export. Now, an origin is a point, so why not use an empty to mark the origin?
Using a box for the purpose is a bit like rectal tonsillectomy, especially seeing as the box and the model may only partly overlap in the scene, making the setup even less intuitive.
Therefore, I propose optionally using an empty called "origin". On import, it would not be created, because it would be at the world origin anyway.
You might ask why not use the root object's pivot in this case and skip the empties. The answer is no, because a root object can be multiple orphan objects joined together.
So what's your take on all this?

[6742ccce6013cOlfred]

Well, it would be the best way to work using origins. And usually that's how I work.
But given that the DarkEngine doesn't work with origins but only takes the size (or the biggest dimension) of the model and creates it's own origin out of that working with the boxes is quite more intuitive.

As I am mainly working with old models (or replacing old models), and not with getting completely new models into the game I take the imported bbox (this update is so great) and scale it to a size so the new model is completely inside the box, then I merge this into the model so it will get exported properly.
This way I can keep the old origin.
Even when my model already fits nicely into the old bbox I still need to merge it so I won't change the origin.

I know it's kinda awkward, but that's because of the stupid way the engine handels the models.

So... I don't know about the empty called origin being a good thing...
How would you implement it?
You just place an empty somewhere and the exporter makes sure it will be the center of the model?

[6742ccce604d9nemyax]

How would you implement it?
You just place an empty somewhere and the exporter makes sure it will be the center of the model?

Yes, exactly. And the great thing about empties is you can give them the "Box" display shape and scale it (proportionally!) to fit the model, while leaving the origin intact. In fact, I suppose I could knock together a little script to force an empty to scale to a "bounding" volume based on the selected geometry. That should be the same bounding box you'd get in DromEd.

[6742ccce605e8Olfred]

Well... But when you would do something like that you could also just add a checkbox on exporting which is like "make center origin". (The center of the world coordinates)

[6742ccce606d7nemyax]

Good thinking! That's the way I'll do it.
And the whiskers and floaters should now probably be removed before any calculations.

[6742ccce607d9Olfred]

Just tested something out, before you get started.
You can safely ignore the bbox when you create the dimensions.
The engine doesn't take the bbox into consideration on getting the size of the model.
So you can make the bbox bigger than the model actually is (however that would make sense, I don't know. But it is possible)

[6742ccce608c5nemyax]

Here's an update for you to test, as usual.

[io_scene_dark_bin-0.1.20140703a.zip expired]

[6742ccce609c3Olfred]

Awesome.
Will test it out as soon as I get home.

I did a few test and must say this is working quite well.
Even the automatic creation of a proper bounding box around the model, oh sweet joy.

Awesome update which will help me out quite a lot.
Thanks to you as always!

[6742ccce60accOlfred]

About the vhot on submodels.

I did a few test running models through BSP.exe
There really seems to be no way you can attach a vhot to a submodel. The only accepted way of the engine to bind it to the root object.
So sad