Having hard times with textures (bug)

I have some hard time applying a texture on an object.
Here the object in render preview

Here the object in Raytraced preview

Here the object properties

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?

Here a Rhino 7 version
bug report.3dm (7.2 MB)

I believe Rendered mode does here per-pixel mapping, or am I mistaken here @DavidEranen, @Jussi_Aaltonen ?

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.

Thanks for answering, there is surely a problem on

not far from there as the UV coordinates are from a low mesh.

My problem is not only on Raytraced it is on the mesh that is calculated using ExtractRenderMesh. This problem is exported when I SaveAs “obj” “fbx” …

Or there is a bug in Match Mapping or I have to apply a specific Workflow (that is not clear).

@nathanletwory Sounds like something I’ve been dealing with lately. I’ll take a look. Thanks!

@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.

1 Like

I see, Cycles only bakes decals, procedural textures and multiple mapping channels. Custom object mappings are not baked. That explains.

I’ll add that flag right away, sir.

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

If I look to the UV editor, I see the simplified object and the UV mapping associated with it

And now if I export my object say to FBX and reopen it in Rhino
Everything is messed up, like in Raytraced mode …

So for me it seems that the corrects UV are not set to the rendermesh.

1 Like

@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.

Am I making any sense?

One way to overcome the artifacts along the fillets is to split the fillet surfaces so that there will be an edge running right at the middle.

Should we introduce an option in the exporter to bake all texture mappings? I imagine OBJ for instance would also benefit from that.

In a local build with Raytraced now also getting baked goodness for custom object mappings

1 Like

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 :thinking:
Many choices

  1. Surface modelling
  2. Solid modelling and unwrapping everything

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 :slight_smile:

@laurent_delrieu Here’s a tip for how to find the places that cause texture artifacts:

  1. Mesh the object using dense settings like these:

  2. Then look at the Rendered mode. Artifacts tend to converge towards the places where the mapping has problematic discontinuities:


@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.

1 Like

Yes, that is why I’m pondering if we should have the ability for exporters to use baked bitmaps instead.

1 Like