Theimage props were constructed by masking a photograph in Photoshop and/or Affinity Photo to create a texture and saved as PNG with a transparent background. The imageprops were created in VW by using the aforementioned texture file with the options shown in these dialog boxes.
Note the image below. On the left is how my plant with alpha appears outside of VW, as created by me. The same plant as it appears as a texture exported from VW, either via extract image or C4D export. The tree on the right is a default VW tree image prop exported via C4D.
I suspect something is slightly different with the alpha channel or image definition, I just can't figure out why the images I am creating are behaving this way. I'm beyond frustrated by this mystery. Any help is appreciated.
In the example below, I opened up the exported image for its texture, added the mask back in, resaved the PNG, and then reloaded the TwinMotion scene. Magically, that plant now works (the other two plants with the black boxes are using different textures even though they look identical.
The other images were generated by Vectorworks during export to C4D. You will note the source file has alpha channel and a clear background while the images created for the same plant has a black background in the exported texture. That seems to be where the problem is. It is also noteworthy that the default Vectorworks plant did not create this black background for the texture file.
Additionally, I am building a library of around 30 3D modeled plants that use images like this for textures that I hope to use for a custom library. While most of these work fine within the Vectorworks environment, exporting to C4D is where the trouble starts. My goal is to identify how to solve this issue so I can have a productive workflow to TwinMotion using my native and custom Vectorworks plants.
I don't think it has to do with how Twinmotion imports the C4D based upon the test I did with my plants and a default Vectorworks plant. In that example, the VW plant was fine in Twinmotion, but my plants are not. Vectorworks seems to be changing my image file's alpha channel when exporting to C4D format. I'm fine with changing the way I make my plant images and textures, I just need to know the best practices before doing so.
Here is another example. I purchased a textured 3D model of a plant in OBJ format. It uses texture files, a base image and an alpha channel image. When directly imported into Twinmotion, it looks fine. When the same model is imported into VW with the same texture references, it too looks fine. I hope to create a design in VW using this and many similar models. However, when I export that same model from VW to C4D format and import it into Twinmotion, welcome back black boxes ? I think this further strengthens the argument that something is happening during the Vectorworks export process.
And here is the OBJ imported into VW earlier and then exported to C4D format. Note how the thorns and flowers now have black where they should be transparent. The only thing I did was export it from VW....
If the alpha image is being imported correctly it should not matter what the background colors are in the color image. The color and alpha are separate images. If the alpha pixels are black then you should see clear - the alpha of the color image shouldn't matter because it is only supposed to use the RGB not the A. The A comes from the alpha channel image which I think looks correct (white plant black background pixels).
In the example below, the plant with the black box is imported from VW->C4D export. The two plants w/o the black box have been retextured in Twinmotion using my original png with transparency. I don't know what goes into the programming of these tools, but it seems like it is a simple switch that is being flipped without my permission ?
I have to go into the texture folder that Vectorworks creates during C4D export and manually look at each texture to figure out which ones VW decided to modify by adding a black background. I then take a copy of my master texture image used to create the plants, rename it to match the VW exported texture name, and replace the VW generated texture with my master. This automatically loads in Twinmotion and I can then get to work. Sure would be nice to know why VW is doing this in order to eliminate this unnecessary step.
Here's a test of the 3D plants I have been working on with the texture replacement work around I just described. It's effective, but takes unnecessary time that the computer should do automatically. I'm really just trying to develop a successful workflow to add fairly realistic 3D representation of my plants into Vectorworks Plant Objects and fulfill the promises of landscape BIM. For this to be effective, the assets need to survive export to other rendering engines and then survive inevitable updates to the VW model exported back to Twinmotion.
@Dave Donley, I am not sure if it is related, but I had similar problems with VB Libraries. On some of the images there was some sort of special mapping that could only be fixed with the Gimp disabling "Save color values from transparent pixels" during export.
I contacted Twinmotion tech support. Twinmotion apparently does not support separate alpha maps. The alpha channel needs to be part of the diffuse color map image. This Twinmotion limitation would require a code change in Vectorworks to put the alpha pixels into the color map, just in case you take the textures to Twinmotion. I will be looking for how to incorporate this info so that you have a nicer experience. Until then the color image must have the alpha channel pixels in it, for Twinmotion to understand the mask.
The Color image of the plant and has an embedded alpha channel representing the background. The Transparency image shows the background as black and the object as white. It imports into Twin motion just fine and I doubt that Twin motion uses that Transparency file since the Color file has the alpha baked in.
The entire point of a separate alpha mask is that the alpha pixels values in the diffuse map should be completely irrelevant to the renderer. The alpha mask and only the alpha mask should be required to get a masked texture in a rendering. Twinmotion does not understand separate alpha masks. Vectorworks assumes a renderer can understand separate alpha masks correctly. Modifying the alpha channel in the diffuse color map would normally be irrelevant, but is not for Twinmotion.
@Dave Donley is there a specification for how to make the image props VWX includes in the program? Let say VWX decided to have a staff member or hire a company to make a library of plants, I imagine you guys would require the responsible party to produce the textures that meet a set of standards guaranteed to work with VWX.
I then saved this file to effectively replace the default VWX texture. I then opened up the C4D export file in Twin Motion and it works fine, mapping my texture onto the VWX plant with transparency. This leads me to believe that there is some magic formula I am not aware of for making textures and/or image props suitable for export.
This looks to be related to box mapping. Removing the box mapping and running refresh shade removes the seams. I think this behavior is expected for box mapping, since it needs to divide the mesh to be mapped to different sides of the box.
Still makes me wonder why this would crash. How do you export?
Interesting, removing the box mapping and even reapplying box mapping afterwards does fix the crash. The extracted analysis mesh still shows the weird seams and all, but the export to twinmotion does not crash rhino anymore.
Hi, this is James Simmons. I would like your opinion on something @solver@DavidJPotter. So recently I have been exporting pictures for a project I have finished and last night I was playing around with the resolution, width and height of exporting a image. I want to get the best resolution out of my images without making them too big in width and height. I normally set the width to 1920 and resolution to 900.0 but after playing around I noticed that when I set my width to 3,840 and 9,000 in resolution, I got the best resolution picture out of all of them I have tried. I got 3,840 after multiplying 1,920 times 2 and I did create some images that had a bigger width but when I upgraded my resolution, It didn't seem like I was getting a better resolution picture. When you export images what width and resolution do you set it to get the best resolution for your images?
I mainly create images for use in PDF presentations and website presentations/sharing for the purpose of structural/Architectural design, so the "resolution" is secondary to the simple graphic content. Imagery is for the communicating and discussion of Architectural designs and not primarily as "works of Art" per se. Some clients require higher resolution output, usually large, expensive projects over and above that of custom homes.
Most of the high resolution work I have done was to promote to others, my skill in doing so as opposed to supporting a particular project. On the other hand, I also primarily use Chief Architect Premier (not HD Pro) which has more choices relative to purely rendering a 3D view. Chief by default has always had the ability to create Photo-Realistic images at ANY size or resolution up to and including the size of a roadside billboard. Some users specialize in Photo Realistic imagery and often use other applications to give them greater and greater control over the final product (Photo Shop, Lumion, Twin Motion, and others).
The Mac I'm using is a mid-2012 MB Pro Retina 15" with a 1GB graphics card. However, I don't have any major problems with Shaded Full, except for not using Ambient Occlusion, and I rarely use shadows.
I just tested your Cube Sample file again in version 9.1, and the same jaggies of the lines happened this time when exporting. So it may be related to your hardware if it is not very recent and, indeed, the new version could have some graphics problem when exporting the images.
3a8082e126