Looking at the export side of things. Could you add a few parameters to automate the naming of the mesh? For instance instead of naming the file manually and then making sure you have .tres or maybe .res, or whatever format is needed. - You could have that as a dropdown/enum and have it automatically applied to the naming. - Same with the export name. You can have a dropdown to use the collection name, object name, or custom where you can change it if you'd like. So you just choose the path, and configure the naming and file type via dropdowns and have things a bit more foolproof/automated.
These are great ideas and I am going to be looking to do "quality of life" updates in the near future to address this kind of thing. An "auto naming panel" with some options might be necessary to implement your suggestions.
Thanks for the video, really awesome to see someone applying professional standards to 3D modelling for Godot. Most tutorials I've seen don't care about draw calls and don't even mention reusing meshes. I was horrified after importing my level and finding out that I couldn't easily manage repeating objects. I do have one question though, what is the difference between doing the collision primitives your way and just using the -colonly or -convcolonly? Is it just for animating them inside of blender?
No problem! Glad you enjoyed. I do have a video called "Blender- Godot pipeline, ok, but why?" That goes into details on the import hint flags (-conv, -colonly) etc. I explain all the different import options and why you might choose one over the other.
Thanks for the tutorial. Naive question: Wouldnt it be possible to write a python scirpt for blender, such that it can check if any 2 objects share the same mesh data, and if yes automatically converts them to a linked mesh? From what I understood this alone would allow GoDoT to start batching drawcalls, and it would be a extremely low effort with still substantial result solution.
It's a great idea! Implementation might be a bit difficult, however. In this case the artist created unlinked duplicates, meaning the mesh data for each object is completely unique (even though the vertices were identical). So natively, there's no way to "know" that objects are using the same mesh. You could do an ad-hoc solution to check to see if they use the same material. The "real solution" would be that the python script checks the vertices of one mesh against all the vertices of the other meshes in the .blend file (with some float approx equal function) to check to see if they are effectively the same. That could be a very expensive and slow operation. At that point you could link it to the same mesh.
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
Looking at the export side of things. Could you add a few parameters to automate the naming of the mesh?
For instance instead of naming the file manually and then making sure you have .tres or maybe .res, or whatever format is needed.
- You could have that as a dropdown/enum and have it automatically applied to the naming.
- Same with the export name. You can have a dropdown to use the collection name, object name, or custom where you can change it if you'd like.
So you just choose the path, and configure the naming and file type via dropdowns and have things a bit more foolproof/automated.
These are great ideas and I am going to be looking to do "quality of life" updates in the near future to address this kind of thing. An "auto naming panel" with some options might be necessary to implement your suggestions.
Thanks for the video, really awesome to see someone applying professional standards to 3D modelling for Godot. Most tutorials I've seen don't care about draw calls and don't even mention reusing meshes. I was horrified after importing my level and finding out that I couldn't easily manage repeating objects. I do have one question though, what is the difference between doing the collision primitives your way and just using the -colonly or -convcolonly? Is it just for animating them inside of blender?
No problem! Glad you enjoyed. I do have a video called "Blender- Godot pipeline, ok, but why?" That goes into details on the import hint flags (-conv, -colonly) etc. I explain all the different import options and why you might choose one over the other.
Hey i got the addon from the "Blender Market's Essential Game Modding Toolkit " bundle. I wonder if it gets updated?
Hey there. I can get you the update, you just have to DM me on Twitter @_michaeljared
Can you share the code for this small window on the bottom right that show all the info
Just hit the three dots next to "Perspective" in the 3D viewport, then check "View Information". Hope that helps!
Thanks for the tutorial.
Naive question:
Wouldnt it be possible to write a python scirpt for blender, such that it can check if any 2 objects share the same mesh data, and if yes automatically converts them to a linked mesh?
From what I understood this alone would allow GoDoT to start batching drawcalls, and it would be a extremely low effort with still substantial result solution.
It's a great idea! Implementation might be a bit difficult, however. In this case the artist created unlinked duplicates, meaning the mesh data for each object is completely unique (even though the vertices were identical). So natively, there's no way to "know" that objects are using the same mesh. You could do an ad-hoc solution to check to see if they use the same material. The "real solution" would be that the python script checks the vertices of one mesh against all the vertices of the other meshes in the .blend file (with some float approx equal function) to check to see if they are effectively the same. That could be a very expensive and slow operation. At that point you could link it to the same mesh.