Hi! I’m Ahmet Sait, a Blender user and a passionate developer highly interested in computer graphics
Sorry for being so late, things got busy on my end.
I’m working on my draft proposal but I have some questions about it before I continue (don’t hesitate to share your feedback as a user);
How important this project for the users? How much of a pain this problem actually is for you?
Other potential usability low hanging fruits and ideas related to file I/O?
Some of these have been mentioned before:
Drag & Drop support for files other than .blend to easily import them
Unifying the import/export menu into a single utility and delegate the IO process to the relevant add-ons after automatically detecting the file type
I don’t guarantee that these or suggestions in this thread will be implemented in GSoC, but the above points seem to be on the roadmap already ⚓ T68935 Unifying I/O importing and drag and drop so I’m up for working closely with the UI / Asset Pipeline module teams where necessary.
How important this project in the eyes of organization and mentors? I’m pretty confident that I can come up with a good proposal but I don’t know if this is seen as a time better spent on a different project. Regardless, I do think there are interesting problems to solve in every area, and things don’t have to be technically complex to make a huge difference for the users.
Are there technical issues I may not be aware of in this project (maybe related to the Blender code base or non-obvious file format quirks)? Links that may be of interest?
I suppose I can tackle more complicated projects later on once I get more familiar with the code base and the development process. Besides, GSoC this year supposed to be less work intensive.
I will be submitting my draft shortly.
Purely from a user perspective: Yes! So much yes!
These kinds of improvements are super important and personally, I’d love to see work done in this area.
Drag and drop import, speed improvements, quick exports, batch export options and grouping or whatever you see important. From my mainly game artist perspective anything in that general field is very much appreciated.
I mainly use FBX as my format currently, to import/export from Blender to other popular DCCs. Mainly since OBJ is very slow with other DCCs and an old format. Also FBX supports many more features over OBJ. Although maybe things are moving into other formats now as well.
But, with FBX, it’s suuuuuuuuuuuuuuuuuuuper slow in Blender currently… when exporting/importing highpoly meshes… it is probably 10X slower than other DCCs. It may take 10/20/30 seconds in another DCC’s , but in blender it can take 3-5min or even longer sometimes… Which is just brutal and makes it really hard to iterate/send things back and forth in some cases.
This is mega important and it’s up there with faster user interface in terms of top requests for users working with Blender in a professional capacity. I spent once 4 days converting a 3gb 3ds max project to Blender simply because blender’s python obj/fbx importers and exporters couldn’t handle all the geometry, so I had to import piece by piece.
I hope that this proposal could also take the work from the previous GSOC that seems it hasn’t been merged into master yet.
Something else that could be nice to have unified a bit more is the options available per import/export file type. It currently seems up to the particular import/export addon to define and implement a set of chosen options, e.g. rotate or scale the model on import, or whether to export only the current selection. It might be possible to define a set of common options and operations that could be available for all import/export addons, although you’re of course limited by the particular file format used if those make sense.
OBJ is of course not a full scene description format like FBX, it’s mainly good for exporting static mesh and curve objects. FBX being an undocumented propriety format also makes things a bit more tricky, and I’m guessing there is a policy of not using closed source code in Blender (correct me if I wrong) so Autodesk FBX SDK is not officially integrated.
you are correct. there are some loopholes though, with regard to addons- you can import an addon that accesses a closed source binary, but that is probably too convoluted and out of scope for a short throw project like this.
Yeah, I can understand not wanting to support/update FBX to be faster, for certain reasons.
I just hope to see faster I/O, no matter the format. Like I said, sending to/from other DCCs to Blender, it currently can take 3/5/10+ Minutes, where sending the same geo in other DCCs is seconds. But I really really appreciate anyone taking the time to look into this area/try to improve.
Wow, this totally must be done
Fast drag’n’drop import of any format (or at least OBJ/ FBX/ 3DS) is what I miss the most from Blender.
Ahmet, I can contribute and support this particular development by donating a little sum if you have Patreon or something.
A number of students contacted me during the proposal generating period. I gave some guidance but we (collective potential mentors who will decide on which projects will be accepted) also want to see what students can figure out on their own, interacting witht he Blender community, as that gives some indication of how ready they are to contribute to Blender. Sorry if this meant that some students felt un-communicated-with. Now that we are in the proposal judging period, it is inappropriate to discuss individual proposals publicly.
there has been a fast import/export GSOC project for the past three years straight at least. I think the one from 2019 was merged into master, and the one from last summer i think is getting merged into 3.0 at some point.
As you may have noticed GSoC projects are announced on the official website as well as the Blender Wiki. Congratulations to accepted students, great to see some exciting projects
This project wasn’t accepted but it did reveal some important points. It seems like faster (and hopefully more robust) FBX support would be far more useful to users than improving STL or PLY since these formats are pretty limited in their feature set and not as widely used. I don’t know if FBX IO rewrite is suitable for a future GSoC project, it’s a lot more involved and officially not documented although a potential starting point for anyone who might want to tackle this can check out the excellent work of Godot developers:
The current python PLY & STL addons also has some low hanging fruits for optimization, would be nice to do that until a proper rewrite is in place.