Alias' OBJ export and UV texture mapping

[systembolaget]

Why is it that since version 2010 and higher Alias' OBJ export can no longer be properly surface (UV) textured in Maxwell Render MXST, bunkspeed Shot, etc.? Are there any plans to re-enable texture coordinate output when saving tessellated NURBS as OBJ to render in proper render softwares? Other Autodesk products such as 3DS Max or Maya support proper interaction with rendering softwares, but not Alias. Thanks for explaining.

[Derek_Hain]

Hello, I have forwarded your question to the Alias team lead based in the USA, I will await his response and reply via the forum  and support issue that it has been escalated to.

regards

[Anonymous]

Hi Derek,

Can you tell me what happened to the issue requested by 'systembolaget'?

Also why is Alias not hooking up with Maxwell Render to creat a plug in version for Alias? 

Look forward to your reply.

Best regards,

Giuseppe

[Anonymous]

@gdellasala I got the information from Alias support in December that Alias products don't output UVs with the OBJ file format - although it originated with Alias/Wavefront. I was told it may be considered in the future. Until then, I am rendering in Maxwell and Shot Pro via Rhino where you can assign UVs to your NURBS and OBJ data and for which native plug-ins exist 🙂

[systembolaget]

When you save an OBJ file from Alias and you try to assign surface mappings (not projection or solid mappings which are by nature UV independent) in Maxwell Render, Arnold, Octane and Vray, the surface texture is "smeared" across the surface.

When we convert a NURBS model from Rhino or Solidworks into an OBJ file, all rendering softwares recognize the UV coordinates and it just works.

Please see one of the old threads from as far back as 2011(!) https://forums.autodesk.com/t5/alias-forum/alias-obj-export-and-uv-texture-mapping/m-p/3237650#M2899

Autodesk should get this to work. After all, the OBJ format was invented by Alias/Wavefront 20 years ago!

[systembolaget]

Bump.

Is there any other workaround other than Alias users having to export to Rhino, Rhino being able to write a proper OBJ format (invented by Alias/Wavefront over 20 years ago)? It's more than irrational having to buy Rhino or SolidWorks just to obtain OBJ files with UV co-ordinates!

Thanks!

[systembolaget]

Alias still exports no UV co-ordinates for rendering Softwares.

The OBJ file format was invented by Alias/Wavefront over two decades ago. After years of asking, still no proper OBJ file export. None of the leading rendering packages works. I have 30 Alias users from January onwards and have to tell them to use Rhino or Onshape.

This feels more than ridiculous.

It should take a coder an hour to bring UV co-ordinates back, so one can do high-quality renderings or send OBJs to some top-tier rendering houses.

[rauscht]

Hi & Happy New Year to you,

thanks for re-raising this topic as it obviously got lost through the years - sorry for that!

Allow me to describe what Alias is providing today:

When using File > Save As > OBJ the according options dialog "OBJ Options" provides the user with the option "Tessellate". If (and only if) this option is checked, a mesh will be exported into the OBJ (rather than the Bézier surface representation of the geometry). And only in this case surface coordinates will be exported (in the Bézier case the domain of the surface parametrization will be included).

The take-away point is that those coordinates are surface coordinates rather than texture coordinates. To explain that please consider the following
Example: Let's assume the wire file only contains a single surface which is a rectangle with parameter space [0,2] x [0,1]. Assume further that the yielded tessellation consists of four vertices v_0, v_1, v_2, v_3 and two triangles, where v_1 equals the surface point at u = 2, v = 0. Then v_1 will have coordinates (2, 0) in the OBJ file.

Mainly there are two reasons why this is happening:

1. the tessellator does not know about texture assignments and even if it would ...
2. texture assignment in Alias can be done on various channels, so in general there is more than just one texture assigned (with potentially different texture coordinates) to one geometry. Which would raise the question which one to use.

In the example above (the one with the rectangular) assigning a texture to the yielded mesh in the used rendering software would result in showing the texture's image twice in u direction.

In the case of a surface of revolution (which I suppose has been used in your example), the surface coordinates in v direction will probably vary between 0 and 2*Pi = 6.28...; hence the image will be repeated 6 times and a "quarter". I guess this is the effect you were referring to in one of your past postings ("smearing effect").

As a side-note: I really can't tell what happened for the screen shot in the middle. My best guess:

• in Alias: OBJ export with the "Tessellate" option toggled off (see above)
  => Bézier representation been exported
• in used software: tri-planar texture projection (as default mode) has been applied to that Bézier surface

But that is just a guess - it might even be that the "Tessellate" option was on but the used software ignores the contained uv-coordinates, and then poorly applies tri-planar texture projection.

Finally - and this might be the most interesting part for you - let's see what Rhino is doing differently. It simply "normalizes" the surface coordinates such that it varies between 0 and 1 for both directions. You might say that this is the expected behavior and ask why Alias is not acting that way. Hmmm, for some cases you are right while for others... Remember: in the rectangle example above the texture image would be distorted by two in u direction, for the surface of revolution it would be distorted by 6.28 in v direction.

However, as there are cases (like yours I guess) where this normalization makes sense, I will create an enhancement request for the OBJ export and will raise product managers attention to it. Does that meet your requirements?

Hth

Thomas

[systembolaget]

Hej Thomas,

a happy new year 2019, too!

Thanks for your in-depth comment. I don't have the technical knowledge you possess, so I can only describe things from the designer's perspective, so please excuse me.

With your answer, you already solved half the problem! Please see the attached screenshot. A shows the good old problem, an arbitrary cubic projector attached across the three surfaces. B shows already better behaviour in the sense that the two inner surfaces have a UV set stretched onto them. C is odd, because it is using method B but the surface of revolution has a one or more UV sets stretched onto each of the eight spans. D is good again, because the trimmed surface has one UV set stretched across it, unfortunately distorted by the parameterisation.

Now, what is the difference between the models? A was exported as we have done it for nearly 10 years: stitch into a shell, use hardware shade to see and adjust the number of triangles, use nurbs to mesh to convert that into a mesh, finally weld the vertices, then export that mesh as OBJ. B, C and left D were exported as you suggested, simply exported as OBJ with the tessellation option.

So, for single and multi span surfaces, your method solves the problem almost. Remaining issues: the left D surface has UV co-ordinates stretched (can that be bettered?) and for some reason surfaces of revolution C have each span treated as if these were separate surfaces.

Are these two issues easily rectified?

Your method of saving an OBJ plus 0 -> 1 normalisation in both surface directions would make rendering all anisotropic materials (bent plywood and any wood with masers, brushed sheet metals, leather upholstery, sport shoe uppers, etc.) a piece of cake.

Thanks!

[systembolaget]

Hej Thomas,

did you have the time to look at my last comment? Looks like we're very close, apart from the 0->1 parameter space issue and that on revolved surfaces each patch receives its own UV set, whereas on normal multi-span surfaces it does not.

A reply would be very much appreciated!

[rauscht]

Hi again,

sorry for keep you waiting for my answer!

However, it's nice to hear my suggestion brings an improvement. To answer your questions:

• In cases like left example of D where the surface parametrization implies a distortion / a stretch of the texture image, there is nothing much that can be done to prevent the effect automatically. Every action would need to take the surface's geometry into account while ignoring its parametrization. This is what texture projection is doing!
• The surface of revolution having more than one span in example C seems odd to me. Thought I have seen a different behavior in my local tests - I will double-check this and will get back to you with my findings.

Cheers

Thomas

[systembolaget]

Thanks Thomas, much appreciated, that only leaves the issue B and C (left) open, as what happens in D (left) is expected behaviour.

Would be great if you find a solution why what we see in B and C is happening, as it is not very intuitive to understand in comparison to "self-made" multi-span surfaces where the UVs simply cover the entire surface from parameter space 0 to 1 in both U and V direction. To us, it seems as if a surface of revolution with, say, 8 spans, is "broken up" into 8 separate underlying entities, each then associated with its own UV set.

Maybe there's an easy fix?

[rauscht · Accepted solution]

Re-hi,

While looking into example C again, the pictures you have provided shows the texture to be shown 7 (or 6.28) times. This is implied by fact that the v parameter of a surface of (full) revolution varies between 0 and 2*pi = 6.28...

In other words: normalizing the v parameter interval from [0, 6.28] to become [0, 1] would yield the texture image being wrapped around the entire surface of revolution (rather than being replicated 6.28 times).

Thanks

Thomas

[systembolaget]

Tack!

On both B and C (left) the revolve surface shows the void texture 8 times (both revolves have 8 spans)... So, to me, it looks as if the 0 -> 1 normaliastion occurs - but on each span of a revolve surface, whereas, for example, a multi-span surface such as shown in D (left) has the texture applied exactly once (with the trimmed-off parts not showing of course). So, something seems odd with revolved surfaces, no?

[Andreas_Bergmann]

Hi,

this is by far my most wanted and needed feature, and it really confuses me that this is not possible since Maya can handle it easily when I export OBJ from it.

So far I have a workaroud with primitives which behave differently - why I don't know,

When I use a plane instaed of a skin, I have a UV layout as I need it. I can even raise up the degree of the plane and it still remains the good UV layout on OBJ export. It's just some annoying work to make the hulls fit to a given surface.

Please make OBJ export with UV coordinates.

[systembolaget]

As you can see, if you export the "Rauscht Way", there are UV co-ordinates. The only problem left is that on revolved surfaces, each patch has an own UV set, whereas multi-patch surfaces created manually have a single UV set, as they should. Also it is a shame that when previewing triangles from Hardware Shade and then using the Nurbs to Mesh, the exported OBJ does not have any UV co-ordinates assigned - hence one does it the "Rauscht Way" without interactive preview, which is not so good (Rhino has triangulation preview on OBJ export).

So from my point of view, the problem is nearly solved...

[Andreas_Bergmann]

Hi, 

thanks for pointing this out again. In fact I always exported obj with tesselation on to get some UV representation but the sizing was always a problem and I was not aware of the parametrization issue.

Did a test with rebuild surface >uniform rebuild (top left) in alias  to get a mostly identical surface with 0>1 parametrization and voilà octane (lower two) is showing the uv map as I need it and as in hardware shade. Have to see  if this workflow will help with different type of surfaces (revolve...) but I am positive.

By the way - the forum is great!

[systembolaget]

You are rendering in Octane? That's very interesting to hear, because most top render engines only offer plug-ins, and they all have no Alias plug-in, hence the OBJ route. So, using the standalone version of Octane works well? I'm interested to find out about it.

I don't like having to rebuild surfaces prior to rendering though, it costs valuable time...

[Andreas_Bergmann]

Hi systembolaget,

Yes, more control over Alias OBJ output would be so much better!



The octane standalone is still some work since you have to export OBJs
manually which is time consuming, cameras go separately via FBX. I do most
of shading and all lighting in standalone then and it is so fast although
unbiased even on a single mobile GTX1070. The new build-in denoiser was a
big & necessary hit. They have great community, ~every month a software
update and it is fairly cheap so possible to purchase more licenses and do
network rendering.

[systembolaget]

Thanks, I see.

So Octane standalone simply requires each part exported from Alias as OBJ. That's easy then. A great alternative to the dreadful Keyshot renderer that does not even do sky simulations, fur, upholstery, grass, or liquids. I will actually give this a try; I have 30 users who could very much benefit if the Octane route works.