Importing orbx file into UE5 via Octane plugin - various is Tweet

[MB]

I have a small test file of rectangular objects of known height that have been assigned various materials.

I am experiencing several issues that are quite elementary and I'm unable to solve. They could be user error, or bugs
The original geometry was authored in Revit and exported as obj with units of mm. i.e. all the numbers in the obj file represented mm.

It was imported into octane standalone with import units set to mm. materials were assigned in Octane.
The scene was then saved as a package, i.e. an orbx file.

ISSUE ONE
When I use the Octane plugin in UE5 to import the orbx file, it seems to come in extremely large.
I have been unable to find any UI to control this, and no info is presented to the user at time of import.

If I import the original obj file directly into UE5, the model is much smaller and seems to be reasonably sized.
If i scale the orbx file by 0.01 (1/100), the two models are the same size in UE5. It would be great if it just worked, and the orbx file got sized to the UE5 'real world size' whatever that is. Since orbx is under your control you should be able to store octane import settings so u can calculate the required multiplier for UE.

It takes a lot of time to figure out this stuff as a novice user of UE, and leaves a bad taste in the mouth since it raises its ugly head within the first minute of using the software.

ISSUE TWO
when importing the orbx illustrated in the attached file, it only assignes one material to the geometry, however the process does build all the materials present in the octane scene, and all of the texture assets those materials use, and it does a great job with good fidelity between an octane material and a UE5 material, kudos to whoever mapped this i'm sure it was harder than it looks. Can you tell me how to map all of the materials to the geometry instead of just one. Or is this a bug, i kinda doubt it though. If I import the obj directly into UE5 it also fails to apply the materials that are defined in the .mtl file, so perhaps this is a UE problem, not an Otoy problem.

ISSUE THREE
The folder of materials created during the orbx import process duplicates each material, there is one named to match the material in the original obj/octane scene, and a duplicate of it with "_Converted" appended to the string.


My goal is a simple workflow where I get a nicely rendered octane scene into the Oculus Quest 2 with as close to Octane quality materials and lighting as possible for people with no UE skills to use. I have built such a thing using Lua and Unity so that is two clicks in Octane to a complied Unity game. It was quite astonishing to uncover all sorts of poorly conceived and implemented features in unity that had to be coded around to make it work, and also the agonizingly slow texture backing/lightmapping process in unity that made improving the results through multiple iterations tweaking lights and material commercially unviable. I'm hoping UE5 will be a better platform.

That brings me to my final question, is there a way to bake the original octane render materials to the UE5 geometry using the power of the GPU, if not, is it planned, and when?

many thx

Mark

[MB]

More information:

If I enable obj groups, g [group name] and export the obj from Revit, when imported into UE5 via plugin's orbx function, I do get some materials.
However, they don't match, i.e., are not applied to the same objects to which they were applied in octane standalone.

the same obj file directly imported to UE5 using their function does not have materials.
Wondering what would happen if obj objects were used o [object name]. My exporter from Revit does not use these. I could modify code and implement if need be.

[ChrisHekman]

ISSUE ONE

Would it be possible to share you orbx file with me? You can DM me the file via google drive.
Most likely this is a MM - CM issue as unreal is in CM.

ISSUE TWO
when importing the orbx illustrated in the attached file, it only assignes one material to the geometry, however the process does build all the materials present in the octane scene, and all of the texture assets those materials use, and it does a great job with good fidelity between an octane material and a UE5 material, kudos to whoever mapped this i'm sure it was harder than it looks. Can you tell me how to map all of the materials to the geometry instead of just one. Or is this a bug, i kinda doubt it though. If I import the obj directly into UE5 it also fails to apply the materials that are defined in the .mtl file, so perhaps this is a UE problem, not an Otoy problem.

That should be a bug I think. OBJ materials should be mapped correctly when converted.
Do you mean that only one of the octane materials is set to the geo asset in unreal?
Could you send me your test orbx?

and it does a great job with good fidelity between an octane material and a UE5 material, kudos to whoever mapped this i'm sure it was harder than it looks.

Thanks. It was quite complicated yes. This whole ORBX import asset unpacking was a lot of work.

ISSUE THREE
The folder of materials created during the orbx import process duplicates each material, there is one named to match the material in the original obj/octane scene, and a duplicate of it with "_Converted" appended to the string.

The "_converted" materials are converted Unreal Materials. Because unreal cannot render octane materials, we create a conversion of the octane material to an unreal material that unreal can actually render. You can turn this off in the import UI, but unreal objects will then display black.
This converted unreal material is then set as the Octane material parent. This parent material is the one that is displayed in the unreal renderer instead of the octane material.

My goal is a simple workflow where I get a nicely rendered octane scene into the Oculus Quest 2 with as close to Octane quality materials and lighting as possible for people with no UE skills to use. I have built such a thing using Lua and Unity so that is two clicks in Octane to a complied Unity game. It was quite astonishing to uncover all sorts of poorly conceived and implemented features in unity that had to be coded around to make it work, and also the agonizingly slow texture backing/lightmapping process in unity that made improving the results through multiple iterations tweaking lights and material commercially unviable. I'm hoping UE5 will be a better platform.

That brings me to my final question, is there a way to bake the original octane render materials to the UE5 geometry using the power of the GPU, if not, is it planned, and when?

This "baking" feature is on the feature list. I dont think this is possible at this moment to code yourself with blueprints, as there is no access to the renderer at this point.

[MB]

Would it be possible to share you orbx file with me? You can DM me the file via google drive.
Most likely this is a MM - CM issue as unreal is in CM.


Certainly, I will DM you with a OneDrive location. It may well be a MM to CM issue. It is my understanding that you could store, or perhaps already store the units under which the orbx file is imported into octane originally, and therefore could use this information to set a scale factor to the orbx geometry as or after its imported. When you say UE is in CM, I'm taking that to mean it assumes all numbers in an obj or fbx represent cm. A poor choice on their part as I don't believe it's a unit that product manufactures or the building industry in any country use as a standard in dimensioning drawings, or digital data exchange. Is it possible to set these in a UE starter template so we can make this issue go away without coding. For architecture, which Epic as recently courted heavily MM is a good choice as it is less than industry construction tolerances, and dimensions can be rounded to the nearest MM, meaning all numbers can be represented as integers yielding performance benefits with some data structures in code.

ISSUE TWO

That should be a bug I think. OBJ materials should be mapped correctly when converted.
Do you mean that only one of the octane materials is set to the geo asset in unreal?
Could you send me your test orbx?

Yes, only one, will send orbx. However, it depends, if the originating obj file does not have groups being utilized, the statement is true. If I implement groups in the obj, and group by material, I get more materials, however they were not applied to the same objects as the material itsef was applied. see obj file snippet below, with groups (g) implemented redundantly with (usemtl).

usemtl * Default - Wood 2 - Medium
g * Default - Wood 2 - Medium_Layer
f 1123/1123 1124/1124 1125/1125
f 1126/1126 1127/1127 1128/1128
f 1129/1129 1130/1130 1131/1131
f 1132/1132 1133/1133 1134/1134
f 1135/1135 1136/1136 1137/1137
f 1138/1138 1139/1139 1140/1140
f 1141/1141 1142/1142 1143/1143
f 1144/1144 1145/1145 1146/1146
f 1147/1147 1148/1148 1149/1149
f 1150/1150 1151/1151 1152/1152

usemtl * Material - Sheathing - Gypsum Wall Board
g * Material - Sheathing - Gypsum Wall Board_Layer
f 1153/1153 1154/1154 1155/1155
f 1156/1156 1157/1157 1158/1158
f 1159/1159 1160/1160 1161/1161
f 1162/1162 1163/1163 1164/1164
f 1165/1165 1166/1166 1167/1167
f 1168/1168 1169/1169 1170/1170

following image is an orbx created from an obj with groups utilized as in snippet above
file rendered from octane standalone

following image is exported from UE5 after importing the above orbx:
Note that transparent materials are no longer transparent, wood and granite textures were lost, and what material go applied to what column has been shuffled, e.g., brick has moved from third column in top row to first column in bottom row. Note that if groups were not utilized in the original obj file, all elements in the scene would have received the same material.

following image is exported from UE5 after importing the above orbx:
in this case the orbx was created from an obj with without utilizing groups

I have not implemented Object [0] and tested the impact of that record on your import code. Clearly your code (or is it epics code) reacts to the presence of g, what's odd is that it affects the application of the usemtl. g itself is nothing more than a text attribute applied to the subsequent faces until it is eventually changed. I Octane Standalone, if present, it will implement the Object Layers feature and it works beautifully. This (and the unit's issue) leads me to believe you are using UE's code to parse the obj file, not yours.

ISSUE THREE
I think I understand, and it makes sense that UE could not render an Octane Material, so you mapped all octane materials to the best approximation possible that can be represented by the more limited UE implementation of materials. You keep both definitions using one set in the octane view port and the other in UE viewports. to get both I need to check "Create Previz Materials" (a little confusing as there is a user concept mismatch, they are subsequently called 'converted', not previz) Since I am only interested in output to VR and not in rendered frames, I don't care about the Octane material definitions. Since models can have hundreds of materials, from my perspective, I would like not to keep the Octane Materials as its just clutter. That said if keeping them does not have negative performance or file size implications, separating the two types into different folders instead would help. If I was to tweak a material, it would always be to a UE material.

Can't wait for baking, the productivity impact and quality impact will be profound.

Finally, can you tell me a little more about the orbx package format as it would help in some of my coding decisions.
I have deduced correctly or incorrectly the following based on the results of Octanes unpacking feature.


When I unpackage an orbx file;

I get all of the textures used by the materials that are in actual use by scene geometry.

I get an obj file, that's identical to that which was originally imported in standalone. i.e., Otoy has not rewritten it, and in particular the material names in the obj file are those assigned by the original authoring software, and do not reflect the names of Octane materials that might subsequently have been applied to material pins.

I don't get a material, (.mtl) file anywhere. (This fact means the unpacked orbx (set of files) is not particularly useful in moving octane scenes to other platforms, such as Unity and UE as the all-important material info is not included, you can manually include the original .mtl file to complete the package, however since both the obj and the mtl don't reflect any changes applied in Octane, the value is diminished).

[ChrisHekman]

I fixed the following issues. The fixes will be part of the next build.
1. Material are now always connected to the correct slots for OBJ meshes
2. Meshes with different unit scales (millimeter, feet, poser units, meter, etc) are now correctly scaled when imported.

I could not fix the issue where unreal does not create material slots because the underlying OBJ file lacks groups.
This seems to be an issue with the OBJ importer with unreal, as it refuses to create material slots for each usemtl section and only looks at groups.

Code: Select all

 (a little confusing as there is a user concept mismatch, they are subsequently called 'converted', not previz)

I changed this aswel. They are now called _previz. From a programmer perspective _converted makes sense, as I am converting them, but I understand a user might not think of it that way.

I don't get a material, (.mtl) file anywhere. (This fact means the unpacked orbx (set of files) is not particularly useful in moving octane scenes to other platforms, such as Unity and UE as the all-important material info is not included, you can manually include the original .mtl file to complete the package, however since both the obj and the mtl don't reflect any changes applied in Octane, the value is diminished).

Octane automatically converts the mtl materials into octane materials when importing an OBJ, and then ditches the .mtl file.
I think the assumption is that the materials should be stored in Octane format as you can and most likely will change them after importing.
This is why i added the previz/converted materials, otherwise you would get a white scene in unreal.

Code: Select all

Can't wait for baking, the productivity impact and quality impact will be profound.

Out of curiosity. Why are you interested in full wrapping style baking. Why not just use the unreal lightmass, or another lightmap tool?

Code: Select all

Finally, can you tell me a little more about the orbx package format as it would help in some of my coding decisions.
I have deduced correctly or incorrectly the following based on the results of Octanes unpacking feature.

Your deductions are correct. ORBX files created by octane are similar to zip files in the sense that they are a list of asset files.
These asset files can be textures, meshes, vdbs, etc. With an additional OCS file that contains all the scenegraph data.
This OCS file also contains all the material information used in the scene.

[MB]

I fixed the following issues. The fixes will be part of the next build.
1. Material are now always connected to the correct slots for OBJ meshes
Thank you, will enable me to move forward now.

2. Meshes with different unit scales (millimeter, feet, poser units, meter, etc) are now correctly scaled when imported.
Again, many thanks, it will limit potentially hours of trial and error trying to figure this out via experimentation.
If you had pull with Epic, it would be sensible if the labeled a grid/plane in one of the templates with the units/size


I could not fix the issue where unreal does not create material slots because the underlying OBJ file lacks groups.
This seems to be an issue with the OBJ importer with unreal, as it refuses to create material slots for each usemtl section and only looks at groups.

I find this bizarre behavior on the part of Epic Games. .OBJ is a 'standard' quite clearly explained on Wikipedia, and they should follow the standard.
Seems it never occurred to them that someone might want to import geometry and materials for each mesh. Nevertheless, they must use the 'group' as a lookup key to the 'usemtl' since if groups are present i can get some materials. They should fix, they want to penetrate our industry, and we author in other products, so material translation is highly necessary. OTOY has very high-quality software and great .obj import. It would be very helpful if you could export to .obj the octane scene with octane applied material definitions, and revised naming of such in the .obj geometry.


Code: Select all
(a little confusing as there is a user concept mismatch, they are subsequently called 'converted', not previz)

I changed this as well. They are now called _previz. From a programmer perspective _converted makes sense, as I am converting them, but I understand a user might not think of it that way.
Thankyou!

I don't get a material, (.mtl) file anywhere. (This fact means the unpacked orbx (set of files) is not particularly useful in moving octane scenes to other platforms, such as Unity and UE as the all-important material info is not included, you can manually include the original .mtl file to complete the package, however since both the obj and the mtl don't reflect any changes applied in Octane, the value is diminished).


Octane automatically converts the mtl materials into octane materials when importing an OBJ, and then ditches the .mtl file.
I think the assumption is that the materials should be stored in Octane format as you can and most likely will change them after importing.
This is why i added the previz/converted materials, otherwise you would get a white scene in unreal.

Code: Select all
Can't wait for baking, the productivity impact and quality impact will be profound.

Out of curiosity. Why are you interested in full wrapping style baking. Why not just use the unreal lightmass, or another lightmap tool?
I might be jumping to conclusions here but:
I am assuming you will create a texture by utilizing the octane materials, not those converted to UE. Octane materials/visuals are much higher quality, so we want these. Similarly, I'm assuming you will utilize the GPU to do this work, which is a hundred times faster than waiting for Unity and presumably UE to do this. We need to do many iterations to find all the material assignment errors people make, and designers want to study different materials on different building components to determine a final decision. If it takes 8hrs to back and i need to have 5 iterations, the workflow is unusable in the current context of industry turnaround times. This is why gamification in architecture has not taken off. It's too hard to move data, and too slow to process it.
Code: Select all




Code: Select all
Finally, can you tell me a little more about the orbx package format as it would help in some of my coding decisions.
I have deduced correctly or incorrectly the following based on the results of Octanes unpacking feature.


Your deductions are correct. ORBX files created by octane are similar to zip files in the sense that they are a list of asset files.
These asset files can be textures, meshes, vdbs, etc. With an additional OCS file that contains all the scenegraph data.
This OCS file also contains all the material information used in the scene.

Many Thanks

Mark

[MB]

One last thing, you know I had to ask
Is there an ETA for the next release so I can get back to working on this.

Best

Mark

[MB]

Chris, I have downloaded the latest build. The new scaling of orbx on import works great, no more getting lost in space. Thankyou.

I still have some issues with material mapping, non-texture map-based materials in particular. Things like procedural Glass, Metal. All materials with maps came across fine with good fidelity to the Octane original material. All others did not.

So is this user error, a known issue being worked on, or a bug.

in each case I was able to create a new UE5 material with good fidelity, so it looks like it is possible to map from one to the other.

If need be, I can document more thoroughly with illustrations.

[ChrisHekman]

Chris, I have downloaded the latest build. The new scaling of orbx on import works great, no more getting lost in space. Thankyou.

I still have some issues with material mapping, non-texture map-based materials in particular. Things like procedural Glass, Metal. All materials with maps came across fine with good fidelity to the Octane original material. All others did not.

So is this user error, a known issue being worked on, or a bug.

in each case I was able to create a new UE5 material with good fidelity, so it looks like it is possible to map from one to the other.

If need be, I can document more thoroughly with illustrations.

The octane-> conversion was never meant to have high fidelity.
But ill check what i can add if you give me illustrations.

[MB]

Octane to UE5 MATERIAL MAPPING.pdf

(4.75 MiB) Downloaded 138 times

Chris,

Here is a document detailing what I have encountered in the current mapping of octane materials to UE5.
Good news is it is not difficult to get a fairly faithful reproduction inside of UE.

I hope it helps, let me know if you have more questions

Best

Mark