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?
this is very very important, current import/export process is slow and no much intuitive, mainly if you coming from another DCC tool that has these features.
I hope you can success
thank you.
Fair enough
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.
This is very important feature affecting almost all blender users. I have wished improvement on this area, feel glad to hear you’re gonna work on this!!
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.
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.
Oof, that sounds painful.
I hope that this proposal could also take the work from the previous GSOC that seems it hasn’t been merged into master yet.
Right, from what I learned Howard wants to get soc-2020-io-performance in mergeable state before summer but he’s also rather busy so let’s see what happens.
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.
Have you talked to the Devs about this project? it’s odd that i don’t see any interaction from them since this place where they should welcome new contributors.
I did get a response from Howard in blender.chat but that’s about it. It could be that my proposal was a bit late or something else I don’t know exactly ¯\_(ツ)_/¯
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.
Wasn’t another gsoc very similar to this one? Anyway I’m glad this is tackled once again.
This is probably beyond the scope but while you’re at it, I think these changes are a low hanging fruit
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.
