Hello Michael,

Do you think it would be possible to write, as integer, the Nurbs surface id per polygons when exporting in .FBX ?
Basically the same feature we have in the .lwo exporter (WritePartTag). In case of .lwo it was actually writing a string ? I would rather have a simple integer as it's seems way lighter.

This data can be very useful for different purpose : building wireframe at rendertime around surface and thus recreate Nurbs wireframe.
I'm also using this data to automate uv's creation, by de-streching existing uv's per Nurbs surfaces.

Until now I was using the unweld export option to rebuild surface ID's by connectivity, but the fact vertex are un-welded can be problematic in some workflow (animation / deformation, or geometry selection).
Re-fusing the vertex are not always possible as sometimes you can have overlapping polygones/geometry sharing the same vertex position that shouldn't be merged.

My last resort was to use 2 exports (weld and unweld), but a friend report that sometimes primitives id can change between those 2 export method, making the data transfer not reliable.

I know it's a very unusual request that probably 99% of the users don't really care about, but if it's doable without to much work the few tech art around will really appreciate :O)

Hi PaQ,

re:
> Do you think it would be possible to write, as integer, the Nurbs surface id per polygons when exporting in .FBX ?

It sounds like you mean an ID value that would persist across different modeling sessions?

That doesn't seem like it would be feasible to fit in a single integer value.

Do you have any example FBX files that have this info set on them? Preferably something simple like a box.

The part IDs for LWO export work the same as smoothing groups that are currently written out to OBJ format.

- Michael

Hi Michael, I thought .lwo tag were more 'complex' than that.
No I don't "need" anything persistent between modelling session, but a way to get the individual surface id's from the Nurbs model without having to use the unweld export option.

Here's a filleted cube example. If we talk about smoothing group, there isn't any right ? (I don't see any need of splitting vertex normals in this example).



The way I create this data is by using a 'tag by connectivity' in Houdini, using the unweld feature in the MoI export options.
This allows me to iterate on every surface form the Nurbs model individually. The data is visualized here with random colors.

Houdini 'tag by connectivity' simply add an unique integer attribute for every polygon that are connected (and thus belongs to the same Nurbs surface).

The issue here by using unwelded models is that I can't really refuse the vertex in case surfaces are overlapping (like an perfect array of cubes, all the shared surfaces will be merge together).

I have also attached the result .fbx from Houdini with the data stored under the name "id" (could be any name). However at this point I'm not really sure if .FBX can actually store custom attribute or if it's an Houdini shenanigans.
This data is exported and reloaded properly only by using binary .FBX format (ASCII export discard it).

Hi PaQ,

re:
> I thought .lwo tag were more 'complex' than that.

Nope, it's just the same as smoothing groups. The only other thing is that if you have welding turned off it will have a separate part ID for each connected pieces.


> Here's a filleted cube example. If we talk about smoothing group, there isn't any right ?

If welding is turned on then there would be just one smoothing group (and one PartID in LWO) and all faces would be in that same group.

If welding is turned off then there would be a separate smoothing group/ PartID for each surface.


re:
> The issue here by using unwelded models is that I can't really refuse the vertex in case surfaces are
> overlapping (like an perfect array of cubes, all the shared surfaces will be merge together).

Why do they need to be merged?


> I have also attached the result .fbx from Houdini with the data stored under the name "id" (could
> be any name). However at this point I'm not really sure if .FBX can actually store custom attribute
> or if it's an Houdini shenanigans.

Hmmm, well I was looking through the FBX SDK briefly and I couldn't find anything that looked like "surface id" in there, so this may be some custom information that only Houdini is looking for.

I have a tool "FBX Explorer" that diagrams the info in an FBX file, but it can't load your example file. Is it possible to generate an older FBX version, like 2013?

- Michael

Hello Michael,

So here's a 2013 version. I don't think there is indeed a specific attribute name like "surface_id" supposed to be used for that purpose.
However I just came across this example (maya to unity) where custom attribute is created and stored in .FBX file (even animated in this example) ... so it's not completely odd to store additional information with that format.
https://www.techarthub.com/how-to-import-custom-properties-from-maya-into-unity/

Having vertex merged is kinda useful to actually exploit "true" connectivity, like assigning materials or groups. In many polygon modeler it's common to simply double click on a polygon to select the whole connected mesh ... like a bunch of bolts that doesn't have any group/name set yet, you can just double click on them and tag them.
With the "unweld" options I have tons of individual surfaces (on purpose), very handy for uv'ing, but not so much for 'normal' selection work.

Hi PaQ, thanks for the 2013 version .fbx, the "FBX Explorer" app is able to load that one ok.

Looking through there I see some chunks of data for Material, Normal, UV, and "UserData 0" and "UserData 1". So presumably one of the user data chunks is for the surface ID values.

Do you know if there is any documentation on how Houdini is expecting the surface ID user data to be structured?

Thanks,
- Michael

Hello Michael,

Thanks a lot to looking at this already !
I didn't find any doc about that subject, however maybe I did something wrong on my side previously, but the ASCII version works too now (maybe by switching to .FBX 2013).
Here's a simple cube example where I did assign a custom 'id' and saved as .FBX 2013 ASCII. I can see in a text editor the 'LayerElementUserData', describe as such :


LayerElementUserData: 1 {
Version: 101
Name: "UserDataLayer1"
MappingInformationType: "ByPolygon"
ReferenceInformationType: "Direct"
UserDataId: 1
UserDataArray: {
UserDataType: "Integer"
UserDataName: "id"
UserData: *6 {
a: 0,1,2,3,4,5
}
}
}

Hi PaQ, can you please test this file to see if Houdini recognizes the surface id data that I've put in it?

- MIchael

Hello Michael, that's perfect !!!! Thank you so much !