When exporting data from Sketchup to USD, the resulting prims contain no transform information. It seems that it’s transform gets baked into the points position of a mesh, resulting in everything having its origin at 0,0,0.
Does someone have any insight as to why that is or how to get around that?
@iavina a few questions that could help the dev team to repro:
- Which OV app are you using? Composer, Code, etc
- What version of the OV app and Sketchup are you using?
- Are you using the Sketchup connector?
- Can you take a screenshot of your export setting?
@Simplychenable Thanks for getting back to me, I’ll elaborate :)
I’m using SketchUp Pro 2023 and the latest SketchUp Connector (Build: 200.1.668 - June 23 2023)
These are the settings I’m using. I’m Publishing as a Project, and not using Nucleus.
For example, a randomly selected Prim has an Identity Matrix Transform on its Mesh Prim, and none of it’s parent Xfrom Prims has any transform information on it.
The points attribute looks like this, which is how it gets correctly “placed” in the world.
[(-51039.04, -53377.258, 177.88017), … , (-51067.207, -53288.434, 206.29643)]
And inspecting the result in Composer, but I’m also familiar with USDView or raw USDA.
For context, this is what the selected Prim looks like.
I would ideally like to have vertex positions be local, and have the Xform Prims have 3D transformed data of the Sketchup component, because otherwise I’m losing Rotation and Scale information.
@iavina i understand what you are after and the desire to preserve the respective local transforms instead of having those data blown away from/baked into the meshes (and resetting pivot to the world origin).
that said, if you don’t mind me ask what the intent is for having access to them in Composer? the reason why i am inquiring is because the Sketchup connector at this time only behaves in an uni-directional fashion (excluding livelink, but doesn’t sound like you were using that feature?). if the goal is be able to manipulate things easier with proper local data, you wouldn’t be able to translate those changes back into Sketchup. in other words, having access to local transforms, in my opinion, would benefit you more within Sketchup as opposed to OV.
i suppose it all comes down to your pipeline and choosing what you want to leverage in OV. my experience with the connector is such that all prims and xforms from the export (tried FBX, USD, and USDA) would all result in baking the local transforms to 1’s and 0’s (nothing new from what you’ve seen thus far). If changing the workflow is not feasible for you, the most you could do before they add in new feature to accommodate this is to utilize the Pivot Tool extension. it would at least help move the pivots of the prims (if inclined, the xforms as well) to specific spot to allow easier editing.
alternatively, if you have room to adjust your workflow, is to export each prop/asset one time into USD (where they are kept aligned to the world origin and axis in Sketchup) then setdress your scene(s) with those USD assets as instanceable payloads that would keep all of the local transforms inside of OV. this would also improve your memory overhead and overall performance as well.
of course, what i just described is simply my personal take of how one could access local transforms inside OV. perhaps the smart people at Nvidia could consider adding this as a new feature where those data are respected, so i’ll let them chime in.
regarding the Xform not having any transform value upon the export process, which i believe it’s the default behavior, it could be added after the fact manually if you desire. unless you are looking for a way to automate that process?
@Simplychenable Thanks a lot for your detailed response.
I definitely understand why the export process behaves this way. We do have a very specific pipeline which is why I am exploring Omniverse.
We have a relatively big and complex SketchUp file, consisting of several buildings, roads, parks, etc. So manually editing every object is not an option. Our target experience is an Unreal Engine 5 application, that has several layers of interactivity and functionality. Because the source SketchUp file is receiving considerable revisions constantly, we are trying to build an automated pipeline using USD as intermediary between SketchUp and Unreal. The goal being that we are able to make edits to the USD scene that will persist across iterations.
To give you an example, we’d like to be able to replace all the instances of a particular tree, with a higher quality one. If the architects decide to add, move or delete trees of that particular type, our pipeline would be able to automatically replace those trees; but this only works if we have transform data.
The other problem that we are solving with USD, is that we can iterate over Prims in the exported USD stage, and manipulate them individually, then write them as individual USD files, and then compose a USD stage with t hem. Other formats like FBX require the entire file to be loaded in memory to access its information, so this is a win for USD :)
So to clarify, I was just using Composer to inspect the USD file and make edits to the USD stage before moving onto Unreal.
For additional context: we already have a working pipeline that is using this plugin:
This handles transforms like we’d like to, and it also is able to use USD references for instances in the scene (although it makes references for SketchUp shapes, instead of components which is not ideal, but good for performance).
What I liked about the Omniverse exporter, is that it keeps the hierarchy and naming consistent with the SketchUp source, as opposed to Simlab’s exporter (which generates a random ID to every prim). But like I mentioned before, we lose transform data. The Omniverse exporter also doesn’t make use of USD references, and instead it creates a new copy of a mesh for every SketchUp Component instance.
The other option that we are exploring is going from SketchUp to Datasmith, and then use the resulting individual FBX files to then turn them into individual USD files, and compose the USD stage at that stage. This is looking to be a promising solution, but it’s still in progress.
I guess it would be nice to know if there are any plans to include this functionality at some point in the future, Or if other people have stumbled into this problems.
Yes – we do have plans to implement this functionality in the next SketchUp release which is in progress now and should be out in the next month or so.