As the object is solid I use Match Mapping from another object that is more simpler. This simple object is first unwrapped, a texture is calculated using procedure described here
I saw lot of discussions about textures problem, unwrapped geometry with bugs, flipped faces …
As there is a good object representation (render view) is it possible to use the mesh behind it instead of ExtractRenderMesh?
I know at least for Raytraced we get a baked version of the texture. And then it is up to the texture coordinates on a probably quite low-density mesh to do the interpolation.
For Raytraced / Cycles in the future it would be cool to add raytraced custom mapping, but currently that doesn’t exist yet.
@nathanletwory Actually Rendered mode bakes the texture and Raytraced for some reason doesn’t. I believe Raytraced should bake like you said (and in fact it does bake the texture but it doesn’t use it). I will check this with a clean install of Rhino 7 and log a bug if needed.
There was a time when this happened - we fixed that with @andy on January 22nd, 2021 in what will become 7.4. Has to do with the render hash calculation, used IDs and so on.
Thanks for looking into the problem. For sure the custom mapping (here I use Match Mapping) is not saved on the render mesh.
If I take my 3dm withe the polysurface
The render view is correct
@laurent_delrieu Thanks for the model, it’s been of great value for me as I’ve been testing latest improvements for applying custom mesh mappings. So, things will improve slightly in the near future but there are also issues that need to be addressed some other way. I’ll explain one of the major cause for texturing issues on your model.
The model itself seems well modeled and clean. Also the simplified mapping mesh looks good. Problem is that the simplified mapping mesh has detail and discontinuity that gets mapped to the middle of a polysurface face. One such detail is the horizontal step:
For Rendered mode the object gets baked and therefore it can present the discontinuities and result looks good.
But FBX export always uses the original bitmap texture. Object mesh that is exported has faces that span the area where the discontinuity is. So in order to look correct FBX export would have to add unwelded edges to the exported mesh along the texture discontinuities - and we may add an option to do that in the future.
Another issue is at the fillets. There are enough mesh edges along the fillets to present the texture discontinuity but unfortunately those edges are all welded - all internal edges on surface render meshes are always welded. So in order to correctly present that discontinuity FBX export should unweld those edges - and that is also something that might be added in the future.
But for now the best thing is to take these restrictions into account when working on texture mapping.
Thanks you are making sense, the confusion for me was the difference between raytraced and render.
So on the workflow I have to find the best way to cope with these difficulties. It is quite hard to make “solid” model, model with thickness compatible with render model that usually doesn’t need that.
So I need to ingest that
Many choices
That’s also one possibility. Although for example in this case the texture is already kind of baked and the UV layout is pretty efficient. So baking again with the standard Rhino baker would decrease the quality a little. It’s easy to test by running _Bake
@Jussi_Aaltonen thanks for the tips. @nathanletwory having consistency between render and raytraced is a good thing if we stay in Rhinoceros but as far as I understand, there will be some problem after export as other tools will use the texture bitmap.