664a0da286c1e

664a0da2870ed
1 Guest is here.
 

Topic: Static model import/export for Blender: development
Page: « 1 [2] 3 ... 7 »
Read 15520 times  

664a0da287a7d
Hey nemyax,
I had a look at your code and saw that the bounding box for the model gets written inside the model file.
Could you add an option that let's you import the bounding box (create a new Object called BoundingBox perhaps)?
And also something which writes a custom bounding box (maybe just look for an Object called BoundingBox, if it is there just take it's coordinates and writes them into the file).

This would be totally awesome and would help me out alot.
(Also I want to try some cheatery *smirk*)
664a0da287ee5
Could you add an option that let's you import the bounding box (create a new Object called BoundingBox perhaps)?
I can do that. How about a wireframe cube without faces?

And also something which writes a custom bounding box
I'm not so sure about this one. From what I've seen in DromEd, the bbox specified in the file is not necessarily the actual bbox. Correct me if I'm wrong, but DromEd seems to generate the bbox based on the maximum absolute value in each dimension. So if your object starts at 0 and stands 1 unit tall, the Z bounds of the bbox will still be -1 and 1.
It's still a grey area to me, and I would like to know how it really works. With this stuff cleared up, I could also implement a real offset option which doesn't require cheating.
664a0da288436
I can do that. How about a wireframe cube without faces?
Even better!

I'm not so sure about this one. From what I've seen in DromEd, the bbox specified in the file is not necessarily the actual bbox. Correct me if I'm wrong, but DromEd seems to generate the bbox based on the maximum absolute value in each dimension. So if your object starts at 0 and stands 1 unit tall, the Z bounds of the bbox will still be -1 and 1.
It's still a grey area to me, and I would like to know how it really works. With this stuff cleared up, I could also implement a real offset option which doesn't require cheating.
Oh what I wanted to test out would be to have a box which is smaller than the actual model.

From what I have discovered is that there are two boxes, or maybe even three.

One box is how the engine handels the model.
Another box is the bracets you get ingame.
And maybe a third which is for collision detection?
Maybe voodoo47 has more insight into this than I do.

Where I have problems with now is that the bounding box needs to match the old model for it to properly replace the old model (at least for the z axis).
So when I create a new model which has a smaller box and put this into the game, it will be floating somewhere in the air because inside the game it still handels the model as being bigger, but the bracets tightly fit around the model.
My guess is that when creating an object in ShockEd it takes the bounding box information of the model (or creates a new bounding box of the model, I don't know) and kind of hardcodes it to the object. So when you change the model file it still takes the bounding box information of the old one (at least for placement). For creating the bracets and the bounding box you see inside ShockEd it still takes the bounding box of the model file.
But I am pretty noobish when it comes to ShockEd, so I might be wrong, this is just my oberservations.
664a0da28855b
Olfred
Could you try hex-editing the model for starters, before I break the exporter? =)
We can discuss the details over PM.

664a0da28895avoodoo47

664a0da2889ac
Maybe voodoo47 has more insight into this than I do.
I'm clueless about pretty much anything model related. I can check them in Shocked and see how they fit and whether they work the same as the old ones, but that's about it.
664a0da288ad2
Suppose I were to add custom bbox export. Currently, the script recentres the model unconditionally, but this would have to be made an option. What should the bbox do if the option's enabled? I suggest it should follow the model to the centre. What do you think?
664a0da288be3
I'm already used to it that the position of the model inside Blender doesn't affect the final position at all and just the centre of the model matters. That's how the engine handels the models anyway.
Why do you want to make it an option? What would change through that?

And yeah, the bbox definitely should follow the model.
664a0da288eb3
Why do you want to make it an option?
You have a point, maybe it doesn't need to be. But what still beats me is the presence of 3 floats for the centre of the model in the header (bytes 48:60). I wonder if there are any vanilla models with a non-zero centre—maybe I should knock together a script to check.
664a0da288fec
Maybe they added it for "maybe we can use this, sometimes... just put it in just in case".
You probably know how programmer think, so you shouldn't be surprised of unneded functions.

Do the information get written the same as the bbox? I could do some test then and check out what happens if you make it non centered and if it could be useful and should go into supported functions for the script.

664a0da28929dZylonBane

664a0da2892ec
But what still beats me is the presence of 3 floats for the centre of the model in the header (bytes 48:60). I wonder if there are any vanilla models with a non-zero centre—maybe I should knock together a script to check.
Check the Z-shifted egg models I posted here.
664a0da289408
I did some testing and it doesn't seem to have any kind of relevance to the game engine.
Tried manipulating the values for a model which already exists in the game, no effect. Then I tried on creating a new item with manipulated model, no effect.
I would say you could just ignore it and always make the model centered.

And your egg models ZylonBane also have just zeros in them for the center coordinates.
664a0da28951f
Olfred
Attached is a blind fix for the z-fighting issue. Please test with some real models, like the energy beams from the other thread. If the problem's gone, this will be incorporated in the bbox enhancement update.

[io_scene_dark_bin-0.1.20140601.zip expired]
664a0da28963d
Tested a couple of models. Looks great!
664a0da289777
Here's a bbox-aware update. Bbox import is always enabled. To export a custom bounding box, give the custom object (must be a mesh) a name that starts with "bbox" (the case doesn't matter). If there are no such objects, the bbox is calculated from the geometry. The objects are centred, as before.
As usual, please do some testing, and if everything is okay, I'll publish it.

[io_scene_dark_bin-0.1.20140602-testing.zip expired]
« Last Edit: 02. June 2014, 15:16:33 by nemyax »

664a0da289979ZylonBane

664a0da2899c6
And your egg models ZylonBane also have just zeros in them for the center coordinates.
Intriguing. So the model really is offset from center just by offsetting its local coordinates, and isn't automatically re-centered by the engine.
664a0da289d7d
So I did a couple of tests now and had a couple of errors.
I made a model for every test scenario and took a screenshot inside ShockEd so you can see what happens.
It's all based on the highsec.bin I was working on, this is a little bit modified to the one originally in the game.

highsec1 - only the imported bbox

The original position of the bbox still gets taken into account on creating the model. It would be much nicer if anything named bbox just gets ignored.
Also the model gets centered inside the bbox, or the bbox centers itself around the model?

highsec2 - the imported bbox renamed

This is really strange, don't know what happens here.

highsec3 - without any bbox

This still works like the previous script

highsec4 - imported bbox renamed, vertices of bbox copied individually, edge deleted.

I tried a different approach as what I did in highsec2. So when I do this the model keeps the size it originally had upon putting it into the game.
Maybe you could only create the vertices for the bbox on importing without the edge?
Or is your vertex order/face direction script interfering, maybe?

highsec5 - highsec4 with added bbox

So when I had the model at the point to get it into game again with its original size, I wanted to add a custom bbox. (Here you can also see what I want to achieve with all this.)
But now the bbox gets shifted into the middle of the model. Maybe you misunderstood me when I said everything should get centered *scratches head*
The bbox should retain it relative position it has, but should move along with the model in case it needs to get centered.



Intriguing. So the model really is offset from center just by offsetting its local coordinates, and isn't automatically re-centered by the engine.
I don't really know what happens when you start on hacking something inside the .e files.
All I ever did there was edit the header with all the materials. But even when I used 3ds2e along with bsp.exe the placement inside Blender had no effect at all.
664a0da28a24f
Olfred
Re-importing into Blender shows where the bbox is in the file. You should get precisely the numbers that are in the header. However, what the engine does with those numbers is anybody's guess.
The bbox should retain it relative position it has, but should move along with the model in case it needs to get centered.
That's what it's supposed to be doing. Again, try re-importing.
664a0da28a3a7
Ah, I see.

What ShockEd is doing is that it just takes the bbox information and centers it around the model.
But when you go ingame the bbox is displayed correctly.
So that is working, nice!
Here's a screenshot of highsec5 ingame.

Only "problem" left then is that the edge of the imported bbox (when renamed) doesn't get exported properly(?).
664a0da28a7ea
Update 0.1.20140602

The bounding box support has been committed.
Some more changes:
  • Objects that are hidden in the Outliner are now ignored during export.
  • Fixed a bug where the number of materials could be erroneously set to zero (there's always at least one).
  • Included the fix for the z-fighting bug.
  • The geometry of objects that have no polygons is now ignored during export (they are not supported by the engine anyway). This is in response to Olfred's observation quoted below.

Only "problem" left then is that the edge of the imported bbox (when renamed) doesn't get exported properly(?).

Download: https://sourceforge.net/projects/blenderbitsbobs/files/
664a0da28abbc
    • The geometry of objects that have no polygons is now ignored during export (they are not supported by the engine anyway). This is in response to Olfred's observation quoted below.
    Oh, no you misunderstood me.
    The problem I encountered now was that when I import a bin model the bbox gets created, which is a edge.
    Now when I export it, the edge doesn't gets interpreted by the engine and so the model won't get the bigger invisible box I wanted.
    So I duplicated each vertex of the edge which gave me a vertex for a min and a max. This way it worked because the game engine accepts vertices.
    So what was needed that on importing the bbox that you only create two vertices, without an edge.
    With the change you made now it isn't possible anymore to have these vertices to make a model "bigger" than it actually is.
    664a0da28b169
    With the change you made now it isn't possible anymore to have these vertices to make a model "bigger" than it actually is.
    But it is. Try it.

    two vertices, without an edge
    Doesn't matter. The only thing that matters is that the mesh have bounds. It can be two vertices, edge or no edge, or a fully-fledged model. I just throw in the edge for ease of visualization.

    Olfred
    Do you use Wings at all? The other plug-in could use some equally tüchtige testing =)
    664a0da28b723
    But it is. Try it.
    I already tried it.
    Look at this file.
    I just imported the original model, I get the bbox, rename it and export.
    Now the model won't receive the bigger size I want it to have.

    Olfred
    Do you use Wings at all? The other plug-in could use some equally tüchtige testing =)
    Unfortunately I don't. I haven't even heard about it until you made the thread in here with your plugin for it.
    I'm quite satisfied with Blender (in terms of free software), so I don't think I will pick it up anytime soon, or at all.

    [highsec9.zip expired]
    664a0da28b9d9
    I get the bbox, rename it and export
    If you rename it, the name still has to start with "bbox". In your case, it should be "bbox-cake" or something.
    1 Guest is here.
    No you won't understand
    Contact SMF 2.0.19 | SMF © 2016, Simple Machines | Terms and Policies
    FEEP
    664a0da28bafc