Dear 3DD,
I’m here with my GitHub account and uploaded from our company account the Job 754330 (kreativekk.de). I failed with errors: 1 but w/o explanation.
It’s a handcrafted USDZ project, originally exported from Fusion360
Hi ,
Thank your for the feedback! Unfortunately we can not reproduce the issue. It could have something to do with your free account and the duration of the processing, as free accounts are queued with all other free requests on our servers. That means the heavier/longer the process is the more likely it runs into time out. We will look into a solution for solving these cases.
For now, you can try to avoid the MB target (as it can take a lot longer in processing time) and avoid ao baking, as this also takes most of the baking processing time.
Let us know if this helps!
Best regards,
Julian
1 Like
Left is the input USDZ (exported from Fusion360, imported to RealityComposer), right is your processing with the Setting “RealityComposer/Medium”
I consider your USDZ export great, but your USDZ import "experimental"or better “tested with X, Y and Z”.
Is DGG committed to improve this? I know that USD can come in hundreds of flavours, so this might become an uphill battle.
Hi PixelPartner,
We will have a look at the data. Our USDZ import was indeed implemented quite recently and we are looking forward to improve it further. All USDZ examples by apple run smoothly through our platform, so we need to pin down the issue with this particular asset.
So far we only support the explicit USDZ subset with PreviewSurface Material as specified by apple. All other flavors if USD are “experimental” at the moment, but we are commited to constantly improve this.
Thanks for your feedback so far!
We will come back to you as soon as we have some findings or solutions!
Best Regards,
Julian
1 Like
Thank you Julian
my assumption is that the USD flavour of Fusion360 differs in:
- It uses a matrix
transforminstead of Apple’sorientationscaletranslate - It uses transform nodes to rotate, scale, translate
st/UV texture mapping - no chance to handle automatically (AFAIK)
1 Like
Hi PixelPartner,
Yes, indeed the matrix transforms were not supported. For the texture transforms we will look into that, we already support a similar feature with glTF afaik.
I will ping you here once there is an ETA for the update.
Best,
Julian
2 Likes
Weitere Schmerzpunkte, die ein effektives Arbeiten mit RealityComposer vereiteln:
-
Bitte UV Koordinaten nicht als
Texture_uv, sondern Industrie-konform alsstbenennen, damit es von Blender und anderen DCCs korrekt geladen wird. -
Hinweis, daß RealityComposer nur sauber mit max. 4K Texturen umgehen kann (beim .reality-Export)
-
Beim Import nach RealityComposer müssen alle texture Pfade/Dateinamen eineindeutig sein, sonst herrscht Chaos (ungewollte Mehrfachnutzung).
Beispiel, wie es RealityConverter macht: Während einer Konvertierung-Sitzung werden die Texturen in Unterverzeichnisse verteilt, deren Name Asset-/Material- übergreifend durchnummeriert werden. -
TimeCodes werden nicht korrekt übernommen, sondern ungefragt nach 24fps konvertiert.
2 Likes
Ah, und beim Importieren von RGB(A) Farbwerten aus USD (ohne Textur) wird der Wert nicht als linear interpretiert, womit der export drastisch anders aussieht.
1 Like
My own workarounds because Apple USDZ only allowing a single UV map per mesh:
- Split meshes according to their texture orientation and rotate their UV
- Have multiple materials assigned and use copies of the original texture, but rotated.
Thanks for sharing your workflow! We think once we have an implementation for this going, the RapidCompact UV creation and baking process comes in handy, as it can display multiple materials with one texture or automatically create new UVs for each meshes or materials.
Hi PixelPartner,
We did some improvements on the USDZ import side. Unfortunately these updates are not on the cloud yet. We will let you know once you can see it for yourself.
In the following the changelog for the latest 3 patches (not on the cloud yet) and a screenshot of the glb output with the latest version:
RapidCompact v5.4.3
- Fixed some issues with USD instancing on import
- USD import can now handle texture scaling
- USD import will now maintain material names
- Fixed textures not exported with the requested format when converting GLB to GLB
- Fixed a multithreading issue in visibility computation
- Added a warning if exporting a GLB file greater than 4 GB
RapidCompact v5.4.2
- Fixed emissive values missing in USD export
- Fixed rare bug where duplicate triangles could lead to visual errors in meshes after UV unwrapping
- Fixed bug that could lead to a crash when meshes get decimated to zero faces
- Fixed bug that could lead to a crash when baking normalmaps on meshes missing normals and tangents
- Fixed issue that could cause errors when exporting USDZ files
RapidCompact v5.4.1
- USD export will now write alpha masks if appropriate instead of converting to alpha blending
Thank you - that looks really promising.
How about the color space issues?
Hi PixelPartner,
“Ah, und beim Importieren von RGB(A) Farbwerten aus USD (ohne Textur) wird der Wert nicht als linear interpretiert, womit der export drastisch anders aussieht.”
Could you provide a concrete example for this, as far as our engineering team tested, we could not detect any color space issues, RapidCompact does not do any gamma corrections.
Thanks!
If I only use textured meshes (sRGB) as input, all works as expected.
If I only use object colors (linearRGB) as input, the same is output, as expected.
If I mix linearRGB object colors with sRGB textured meshes, the result is baked into a new atlas, but the object colors are not translated from linearRGB to sRGB prior to baking. This results in changed colors. I just tried again with job 1061679, simple brown cube (linearRGB 0.75, 0.5, 0.25)
1 Like
on the other hand, I’m not sure if my DCC exported the object color properly in the first place.