While being in this state.
I really like that you can associate different objects within a Blender-file with different exported file-names–that’s a rather neat feature! 
Overall, I’m liking the looks of this exporter thus far!
I did this in order to use the blender file as a level project.
1 Like
So, if I may ask, what is currently supported, and what to you intend to later support? (Animations, tags, etc.)
I will support animations and tags. As for textures and materials, I have a panda-based editor(also in the original state) to edit them.
Thanks to rdb’s pybamwriter library, can do a lot.
Example of an editor.
About the present tense, only the mesh. I’m struggling with the blender interface. I still need to determine how I will export the object hierarchy.
1 Like
Ah, fair enough! Thank you for the answer!
It definitely seems like an interesting approach, then!
Love the look of your material viewer. Is the GUI done in wx? How did you get the dark theme?
Yes, this is wxPython, it uses the OS theme. Accordingly, this is a third-party theme for Windows 10.
Finished programming the camera export.
Now you can export the configured camera, useful when developing a 2D interface. Create cut scenes and much more.
1 Like
Minor update.
- Added vertex smoothing.
- Texture coordinates
- Vertex colors.
The most important news, the plugin under the hood now uses panda. In this regard, unlimited opportunities have opened up. However, now to use this plugin, you need to install panda in the blender. I know for sure that there are no problems with this in Windows, but with Unix systems I do not know how things are. I think I will need to test this feature.
I think I’m close to posting a pilot release of the plugin.
Test export of this model.
vertext = 7958
trangle = 15744
Export time: 0.4 sec
File size: 1.25 megabytes
YABEE
Export time: 0.6 sec
File size: 6.05 megabytes
It looks like YABEE is using a bad console output practice. So the time changes. I had to get rid of the warnings and other things. Now the time showed 0.6
2 Likes
Thanks for continuing to work on your exporter. It looks to be a great addition to our tool ecosystem.
I made an algorithm for exporting CollisionPolygon, with a division by materials, so that you can conveniently program the game logic.
2 Likes
Another video that gives an idea of the plugin interface and the sequence of actions.
2 Likes
Nice! This is really coming along, it does seem!
The only thing that torments me is whether to use ModelRoot or PandaNode. The hierarchy seems too bloated. If you’re still doing the division by materials, there will be many more names.
Hmm… Is there much point to using ModelRoot?
The API seems to indicate that it does nothing more than indicate a model that has been loaded, which seems a little superfluous to me.
Conversely, there is an argument in favour of including it in order to conform to the behaviour of the engine and other exporters…
I’m not helping, am I? 
1 Like
It seems that the fullpath property of a ModelRoot is used to index it into the ModelPool. So it could be that without a ModelRoot, loading the model multiple times would also add it multiple times to the ModelPool (and load it again in memory) instead of just once. But I’m not entirely sure about that; some testing of this theory is likely called for.
Indeed, there might also be users who developed tools that depend on the existence of a ModelRoot when loading a model into these tools.
This node also prevents unwanted merging when using flattening methods.
Good points, all. In that case, I’d suggest going with ModelRoot, rather than a plain PandaNode.