Jump to content

mvr re-engineering has borked texture export


Recommended Posts

When exporting to MVR from Vectorworks, texture transparency and bump are no longer exported.

 

The example is of 3d polygons with a texture that has an alpha channel. The texture is of audience member silhouettes and their transparency (image mask with alpha) allows their heads to be seen with the rest of the rectangular polygon transparent:

 

image.png.477b73ba30bfb9df2c86a0f9f94e8da5.png

 

In the Properties window, you can see that the above selected geometry has been brought in from the Renderworks texture properly:

 

image.png.e78eb312384e1b838b485c3ad44d09ec.png

 

When exporting MVR from VWX2022 SP3, we can see that the name of the geometry has now been changed to "meshes[0]" and the transparency is no longer there. Note the black rectangular polygon outline where there should be transparent alpha channel:

 

image.png.3ccf6e55bcd940d1dd3321c40134283f.png

 

And now the Properties window indicates that the geometry has no Alpha texture:

 

image.png.0ae88e343b1aee60dc603d21ecc7933c.png

 

This happens when "Image Mask" Transparency is used in the Renderworks texture from "This Texture's Color" then selecting Alpha Channel

It also happens when a separate transparency image is prepared in Photoshop by generating an image with white for the pixels you want rendered and black for transparent (essentially the same process that Renderworks is doing, but manually).

 

Could this be repaired? Transparencies are an essential part of the Vision workflow, saving countless polygons when illustrating complicated objects with just a few polygons.

 

Thanks

aj

 

 

 

Link to comment

The workaround for this is to first create transparency images for any image you plan to turn in to a texture, then assign the transparencies individually from within Vision. 

 

This is of course tedious, adding hours to any model build since you need to prepare the image in a different program twice (three or four times if you're adding Bump or Reflectivity).

 

 

Link to comment
  • Vectorworks, Inc Employee

@ajpen You can also try selecting the option to exporting using 3ds in the export VMR dialog.

The new glTF based format uses a completely different method of texturing (PBR) than 3ds.

Using 3ds may be a faster solution for you while we investigate the problem.

Link to comment

@klinzey

Aha! Had not seen that option; MVR export is such a reflex for me now that I didn't notice that little box!

 

Found it in the release notes, no less: VB-185453Export MVR with glTF breaks glTF textures

 

I have confirmed that the legacy .3DS export works as it did before.

 

I just had a crazy idea (but maybe a good one)... A "check engine" light for Vectorworks that draws attention to the features you use most often somehow. Opening the full release notes and searching for one's favourite features is a start...

 

Thanks Kevin!

aj

 

Link to comment
  • Vectorworks, Inc Employee

Hey! Sorry for the late response.

 

So, there's a few things going on here. In my own tests, almost everything is working properly and I think there are just some misunderstandings. There was one bug I found when running through the MVR texture workflow, which can be worked around. I will cover the bug at the end.

 

The 3DS file format supports bump images. The glTF format does not; instead preferring normal map images.

The 3DS file format also supports independent alpha images. The glTF format does not; instead preferring the alpha be "baked" into the primary color image's alpha channel.

 

One thing to note for anyone else reading this who is not aware, both 3DS and glTF may require higher Texture Quality settings in Vision to render all textures properly. Lower Texture Quality settings may ignore certain texture images in order to gain better performance.

 

The easier case to talk about in regards to this post is the Bump Shader. When VW performs an export of a Renderworks Texture whose Bump Shader is set to Image, VW converts this bump image to a normal map programmatically. So, when importing a glTF or a glTF-backed MVR into Vision, you should see a Normal Texture instead of a Bump Texture. This is different than 3DS, by glTF/Khronos Group design. But, the result and functionality should be nearly identical and performance may increase as normal maps generally are more performant than bump/parallax/displacement maps. If/When glTF adds support for bump/parallax/displacement images, we can investigate adding this support to our glTF code in VW and Vision.

 

In regards to the Transparency Shader, there is something I want to reinforce as we taught "bad practices" in the past. If you read the "Preparing High-Quality Textures in Vectorworks for Export to Vision 2021" forum post/guide linked at the end of this comment, you will notice that on July 8th of 2021 we edited the guide. This was to correct an error with our suggestion for Transparency Shaders. It used to suggest that you use Image for this shader, but this is bad for performance and rendering quality in VW. What should really be used is Image Mask. The guide was updated a little while ago to demonstrate this. While 3DS will technically export either Image or Image Mask, glTF will now only export Image Mask. This was a requirement of the glTF exporter for technical reasons, mostly involving the number of channels allowed in an image.

 

With that caveat out of the way, when VW performs an export of a Renderworks Texture whose Transparency Shader is set to Image Mask, VW "bakes" this grayscale image into the alpha channel of the primary color image. We tried to do this in an intelligent way such that if the Color Shader is set to Plain, it will still generate a proper glTF image at export time. When importing a glTF or a glTF-backed MVR into Vision, you will no longer see an Alpha Texture as this will always be baked into the main/primary color texture. This is different than 3DS, by glTF/Khronos Group design. But, the result and functionality should be completely identical and also may result in better performance by reducing the total number of images required for rendering. If/When glTF adds support for independent alpha images, we can investigate adding this support to our glTF code in VW and Vision.

 

Now, I said there was one bug I found when testing all of this earlier. The bug is that Vision, for some reason, is not automatically checking the "Use Alpha Channel" checkbox for meshes when importing glTF and glTF-backed MVR files. This is causing the alpha mask effect to not render properly even though all of the necessary data is present. The workaround is fairly simple; select all meshes necessary, using multiple selection if needed, and check the Use Alpha Channel checkbox. This will save into the VSN and should only need to be performed after the import. We are investigating the cause of this issue and hope to have a fix sooner than later. I apologize for this inconvenience.

 

  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...