Should tMR allow .blend files?

[Sir Teatei Moonlight]

I posted this idea a bit ago in the general suggestions thread, but it only garnered minimal discussion, so I'm bringing it to its own topic for greater visibility.

The current rules for model submission formats are that:

• There must be either a .dae or .obj.
  
• There may be a .fbx or .smd, if the above is still true.
  
• There must not be anything else (such as .blend) because they are proprietary. Exception: For edited/custom models, something else can be allowed.
  

I am putting forth two premises:

• The current standards are outdated. .dae does not support normals. .obj doesn't support rigging or vertex colours and requires an additional .mtl file. Neither handles more than one UV map very well, if at all. .fbx is opaque (unlike the other three) and so cannot have minor issues fixed by mods. .smd has been considered outdated by its main audience for several years. As a submitter, I am finding it increasingly difficult to work around these problems with modern game models (it's part of why I haven't beeen submitting much recently).
  
• .blend, while proprietary, is free and open source. There is a high likelihood that users downloading models from tMR are already planning to bring them into Blender. Giving them a .blend to begin with will decrease initial friction by a lot.
  

Given the above, I would like to suggest that .blend be made a generally legal secondary format. It can't be a primary format because it still is proprietary (I presume), but it would allow the proper retaining of so many more model properties than the current formats, and is likely to have a large "market share" of users who can just open it up and not need to make their own materials.

[Petie]

I have always been in favor of incorporating Blender into the tMR mix but as I don't really know much about models myself, I haven't really been able to push that opinion. I will say that I wouldn't consider .blend files proprietary any more than I would .zip or .mp3. Sure, support for .blend files isn't necessarily baked into the OS but there's no barrier to entry given that the software is freely available. I realize that you could make the same argument for .rar or .7z in that case but I'd argue that limiting archives to .zip makes sense since pretty much all systems have native access to that format. Since basically nothing has native 3D model viewing capabilities (though it seems Windows is trying to incorporate a rudimentary viewer now?), you need to download something to view and interact with them and a free and open source tool is far easier to stomach than a closed, paid software suite.

[Raccoon Sam]

DAE absolutely supports normals, but suffers from terrible implementation problems.
It's no secret that the majority of rips are finalised with Blender, and because it's free open source software, I would see no problem adding .blend files to the mix. Ironically FBX is proprietary and nonfree, but has wide support and zero implementation problems to my knowledge.
Petie's points are fair.

My hot take: allow any format (even .c4d or .max), recommend .blend but require OBJ or DAE for compatibility sake.
I mean, I'd love to post my PSD sprite rips so animation and layering would be apparent, but obviously that's a bad idea because Photoshop is a paid program. PNG works for sprites in the same "compatibility reasons" as OBJ in the 3D sense of things.

Then there's .glb and .gltf too, which absolutely would be good to have, but the sad reality is that there is no (and _can_ be no) real true super all-encompassing format for any 3D stuff. If you wanna be pedantic, there can be no "true" sprite format either, but I digress.

I would like to hear Peardian's and Dazz's takes on this.

[Peardian]

Here are my thoughts on this.

.dae does not support normals.

I'm not sure where you got this idea, but the DAE format explicitly supports normals. Search for semantic="NORMAL" in the specification doc.

.obj doesn't support rigging or vertex colours and requires an additional .mtl file.

Correct, OBJ is an old and limited format. It is certainly not ideal. However, the format is stable and still commonly supported. Bones and vertex colors can't always be ripped, such as with screenrips, and many models don't have them at all. In those cases, OBJ is perfectly fine.

Neither handles more than one UV map very well, if at all.

It is true, OBJ does not support multiple UVs at all. However, DAE explicitly supports multiple UVs just fine. The problem with multiple UVs is that they can be difficult to work with. This is why we ask people to include a version that splits the UVs apart onto separate mesh copies, for cases where importing multiple UVs is not possible. In cases where the UVs are split, an OBJ is perfectly fine because each mesh would have just one UV anyway.

.fbx is opaque (unlike the other three) and so cannot have minor issues fixed by mods.

Correct, which is why it's only allowed as a bonus. Also, the format is being updated over time, which means newer programs can't open old FBX files and older programs can't open new ones. These reasons are why it is unsuitable for a primary required format. (Just clarifying for others who read this.)

.smd has been considered outdated by its main audience for several years.

I have no strong opinion on SMD. I've personally never used it.

.blend, while proprietary, is free and open source. There is a high likelihood that users downloading models from tMR are already planning to bring them into Blender. Giving them a .blend to begin with will decrease initial friction by a lot.

Given the above, I would like to suggest that .blend be made a generally legal secondary format. It can't be a primary format because it still is proprietary (I presume), but it would allow the proper retaining of so many more model properties than the current formats, and is likely to have a large "market share" of users who can just open it up and not need to make their own materials.

The main issue with BLEND files is that they only work with Blender. Those files will be useless to anyone using 3DS Max, Maya, Cinema 4D, etc. However, it is true that Blender is freely available and widely used. I am not completely opposed to their inclusion, but the files are a lot more complex and more difficult to vet. BLEND files can not only have resources packed inside, but also custom layouts, scripts, and other things. If any of these things had a problem, we'd have to either spend extra time to fix the issue or remove the file entirely. That adds even more time to review each submission, not to mention potential issues with Blender version compatibility.

One situation that I very much want to avoid is people relying on Blender for handling everything difficult. The last thing I want is for someone to download a ZIP and the readme says "Animations are in the Blender file" or "Other UVs are in the Blender file" or "Vertex colors are in the Blender file" or "Bones are in the Blender file" or even "Textures are in the Blender file".

I agree that there is some value in being able to provide material setups for complex materials like those in Splatoon, even if it only works for Blender users. However, from what I have seen in other submissions, this same information can also be conveyed through images of the node setup and/or tutorial text. Personally, I think teaching users how to make the setup themselves is better than just giving the finished package. ("Give a man a fish..." and such.)

Again, I am not completely opposed to its inclusion. However, I worry that the potential convenience it can provide will be outweighed by the issues it can bring.

I will say that I wouldn't consider .blend files proprietary any more than I would .zip or .mp3.

It seems I have not been using the word correctly. Blender files are not, by definition, proprietary. However, I would still lump them in the same category as .MAX or .MAYA files because Blender is the only program that uses them to any degree.

Ironically FBX is proprietary and nonfree,

Huh, I didn't know that.

My hot take: allow any format (even .c4d or .max)

This would be a nightmare for reviewing. We're not going to blindly trust such files, so it would either create a bottleneck based on which staff has which program, or it would require all of us to shell out money and install a bunch of programs. Either that, or we'd end up deleting the ones we can't personally verify, which would be a lot of them. Regardless, it would just be a lot of extra hassle for very little benefit.

Then there's .glb and .gltf too, which absolutely would be good to have

We do allow GLTF as a bonus, but not ones with images packed inside. There is no reason to pack 10 MB worth of textures into a model file when those same textures are sitting in the zip. We don't allow GLB since they are opaque and usually have the textures packed inside anyway.

but the sad reality is that there is no (and _can_ be no) real true super all-encompassing format for any 3D stuff.

This is true, and that's why we prioritize the essential things (polygons, UVs, base texture, bones, etc.) over extra stuff (normals, animations, morphs, most vertex colors).

[Petie]

The main issue with BLEND files is that they only work with Blender. Those files will be useless to anyone using 3DS Max, Maya, Cinema 4D, etc. However, it is true that Blender is freely available and widely used. I am not completely opposed to their inclusion, but the files are a lot more complex and more difficult to vet. BLEND files can not only have resources packed inside, but also custom layouts, scripts, and other things. If any of these things had a problem, we'd have to either spend extra time to fix the issue or remove the file entirely. That adds even more time to review each submission, not to mention potential issues with Blender version compatibility.

One situation that I very much want to avoid is people relying on Blender for handling everything difficult. The last thing I want is for someone to download a ZIP and the readme says "Animations are in the Blender file" or "Other UVs are in the Blender file" or "Vertex colors are in the Blender file" or "Bones are in the Blender file" or even "Textures are in the Blender file".

I agree that there is some value in being able to provide material setups for complex materials like those in Splatoon, even if it only works for Blender users. However, from what I have seen in other submissions, this same information can also be conveyed through images of the node setup and/or tutorial text. Personally, I think teaching users how to make the setup themselves is better than just giving the finished package. ("Give a man a fish..." and such.)

Again, I am not completely opposed to its inclusion. However, I worry that the potential convenience it can provide will be outweighed by the issues it can bring.

I just want to add that this is exactly the kind of feedback I was hoping for. My understanding of models is extremely limited so I see something like Blender and think, "We should use this - it's free, open source, and most users will be using it anyway - there's no downside." And while that may well be at least partially true, I did not have the insight into the approval process (or even the general workings of the software) to understand how that might cause problems. Even having read that, I do still think there may be merit in incorporating Blender but I now have a much better understanding of why it's not as simple as just allowing .blend files and calling it a day so thank you.

It seems I have not been using the word correctly. Blender files are not, by definition, proprietary. However, I would still lump them in the same category as .MAX or .MAYA files because Blender is the only program that uses them to any degree.

No, you've been using it correctly. I just meant that .blend files are much more easily accessible to everyone than .max or .maya as the latter two require paid (and typically very expensive) software whereas the former is free. .blend is absolutely still a proprietary format, it's just not as locked down due to licensing requirements.

[Fawfulthegreat64]

Personally I don't see why an optional blend file of a rip is any more of an issue than an optional blend file of a custom which is allowed (and I'm assuming is subjected to the same checking a rip submission would be).

Speaking as someone who barely knew my way around 3D when I first discovered the site, I really just wanted to make renders and struggled a lot with the amount of things that weren't set up by default and had to be manually set up. I think a rip that provides the user with the model with as many of its in-game features intact is a valid thing that most users downloading models would appreciate having. Not as a requirement obviously but considering Blender is free, and it wouldn't replace the .dae/.obj that's already required in a submission, I think it would only be a positive thing to have should the submitter choose to include it. I get the checking thing, and I think maybe adding a caveat of not allowing blend files with images embedded (so they just use the textures already included in every submission) might make it easier.

I already know that I'd have preferred to set up the materials and include ready-to-go blend files in most of my rips, a huge pet peeve of mine is the textures not being transparent when loading a dae into Blender. I had to scour the web to find a script that would automate fixing that with one click since some of them have many different materials. I think the more convenient a model is to download and use, the better. If it ever does become allowed I will definitely try to go back through my rips and add one. I personally would want people who download my rips to be able to open them up and have them look like they do in the preview render.

[Sir Teatei Moonlight]

I'm not sure where you got this idea, but the DAE format explicitly supports normals. Search for semantic="NORMAL" in the specification doc.

I admit I hadn't dug too deep into this. All I know is that when I round-trip .blend -> .dae -> .blend, I lose the custom normals data, and I see no related options in the importer/exporter. (Or at least that's how it was last time I checked. Something could have improved since then.)

for cases where importing multiple UVs is not possible.

(emphasis mine)
Okay I had misremembered this one, I got it backwards. (Though I dunno it seems like a pretty big issue if your program of choice can't import that properly these days.)

One situation that I very much want to avoid is people relying on Blender for handling everything difficult. The last thing I want is for someone to download a ZIP and the readme says "Animations are in the Blender file" or "Other UVs are in the Blender file" or "Vertex colors are in the Blender file" or "Bones are in the Blender file" or even "Textures are in the Blender file".

I completely agree. If the secondary format is removed, the rest of the submission should still be valid by itself.