In my opinion it's best to use CD_PROP_FLOAT2 as name for the datalayer as that describes the data layout. And since currently the UV system is the only one that uses CD_PROP_FLOAT2 layers I don't think it's already necessary to add special flags. Currently in my patch all CD_PROP_FLOAT2 layers *on face corners* are listed as UV maps. If there would ever be a pressing need for other float2 data on face corners we can always decide to add extra tagging then. I think if a user purposefully creates a float2 attribute on face corners (s)he won't mind them appearing in the UV maps list as well. Trying to solve that issue pre-emptively looks like premature optimization to me.

The USD changes look good! Not only is it a good optimization, but it also removes code which otherwise required cleanup. Thank you for this.

A simplified solution has been submitted -> rB317dfc17358f: Fix T96776: Assets dropped upside down when looking through camera

While this solution works, I don't think it's a good idea to expose ray_start and ray_normal.
These variables are only calculated if we have snap to face or occlusion testing.
Also, it's not really the ray_normal that we're looking for to solve the problem, but rather the direction from the ray_origin to the snap point (which could be a vertex or a nearby edge).

The way I see it is we're not removing the ability to store generic 2D vector data on geometry, since you can just use a 3D vector. For me that's a reasonable long term solution.

only CD_PROP_UV and no CD_PROP_FLOAT2

This is functionally the same as only having a float2 type though, only it has a different name.
Then the downside is that the name of the data-type encodes how the attribute is used, which is exactly what we wanted to move away from with the generic attribute system.
I think it has been a huge improvement in terms of flexibility and simplicity to have a way to store truly-generic data on geometry.

Awesome!

• Revert "Fix T98055: Library Filters do not work in Source Files"
• Updated with more straightforward fix to check if the file is the main file, and if so use the is_filtered_main_assets() filter instead.

@Julian Eisel (Severin) Thanks for the feedback, that is substantially more straightforward. I'll clean up this PR to implement the fix you mentioned, and then create another to separate out the filtering code.

Thanks a lot for the patch, this is really helpful!

Thanks a ton for the fix!

Ok will make these changes asap, just saw

Personally I would have only CD_PROP_UV and no CD_PROP_FLOAT2. It's not clear to me there are good use cases where using either CD_PROP_UV or CD_PROP_FLOAT3 would not work well. I don't think users care much about the differences, they would mainly get in the way.

In D13958#411406, @Aras Pranckevicius (aras_p) wrote:

In D13958#411356, @Martin Malmqvist (Malmqvist) wrote:

When importing OBJ files exported from Gaea (800 MB, 11 mil faces), using this experimental importer, the speed is absolutely amazing! However the object imported gets a default name "New object".

@Martin Malmqvist (Malmqvist) are you trying this in Blender 3.2 or in 3.3? The "New Object" case should be improved in 3.3 (rB99847cd6423), I'll see about getting that into 3.2.1 too.

Overall the concept for this patch seems like a good idea to me.

There are many exporters/importers that need to know what the UV maps are, so it seems like something that must be resolved before UV map to float2 attribute conversion lands.

Having at look at this issue, interestingly enough the following comment is present in collection_drop_exec

Looking at this again, looks like I missed some things and shouldn't have accepted it yet.

The patch is getting in a better shape. I've left a bunch of inline notes where I think things can still be improved.

Instead of changing existing material assignment enum values, add a new dedicated function BKE_object_material_assign_single_obdata instead (based on Bastien's review)

In D13958#411356, @Martin Malmqvist (Malmqvist) wrote:

When importing OBJ files exported from Gaea (800 MB, 11 mil faces), using this experimental importer, the speed is absolutely amazing! However the object imported gets a default name "New object".

When importing OBJ files exported from Gaea (800 MB, 11 mil faces), using this experimental importer, the speed is absolutely amazing! However the object imported gets a default name "New object".

Thanks for fixing this mess up!