Ok so i want to texture a tire, im using 3 surfaces and not one so i can have a clear sideview shot.
Im just wondering why am i getting these weird UV’s, the inner sidewall is an exact mirror of the other one but its complete transformed.
Also if you look at the thread, towards the seam (end/beginning) its curving upwards.
And using a tire made out of 1 surface doesnt work either, hopefully im missing something here,…
This is by the way what i get using a capped cylinder for uv, a complete mess,…
The time it was taking was due to the density of the custom render mesh set globally in the file. Sparser render mesh settings will unwrap nearly instantly here. I would also Unwrap it in three parts rather than one polysrf. I exploded the tire and used a planar map for the sides and a uncapped cylinder for the tread. I adjusted the UVs for each separately in the editor based on the textures I found in a quick search… I’m sure you’ve got better ones! Then I grouped the surfaces together so they don’t get moved apart by accident.
Yes Brian, i get that, this is what i also did but because i want a seamless transition from sidewall to tread, and using a bitmap (cause i want to go photorealistic) and not just a solid color, this solution will leave a seam which i dont want,…if you look closely you can see the transition is not so nice,…(open in a new window so you can see the bigger picture)…
Thanks for explaining more. The texture you’re using and whether it is laid out linearly or circularly for the sidewalls would change the UV method to use but assuming your texture is linear, how about this approach using a custom single surface as the custom mapping object for the polysrf?
I set the surface to be in wireframe display so you can see through it and I also rebuilt it to have pretty even control point spacing so the texture wouldn’t stretch.
1 - why didnt i think of that
2 - how did you make that surface not having a mesh? (invisible)
3 - does the single surface have its UV’s like that by default?
4 - still not sure how i can project a circular image on the sidewall though?
and isnt cylindrical mapping supposed to be perfect for this? why did i end up with such a weird uv layout?
Thanks btw, im working on a new tire right now for a new concept and i want to make it better than this one, this one was quite ok but still far from photorealistic,…
Yes but, I rebuilt it to have more even control points since that will drive the default ‘by surface’ mapping.
That’s what I was talking about when I said the method would depend on the texture layout… and I don’t have your texture. If the sides are circular textures and the tread is linear, you won’t be able to have them match all the way around once laid out flat using a capped cylinder UV. The caps are planar projections not revolves… but I suppose the custom mapping object method I showed last might work for this if you made a closed revolve with the singularities at the sidewall centers. edit: Nevermind my brain decided that won’t work since the texture would stretch towards the singularity.
With Unwrap I didn’t get what you did but it probably has to do with the edge selection used. The Capped cylinder method is crazy though and I don’t know why… probably a bug and I’ll file it for development to look at. http://mcneel.myjetbrains.com/youtrack/issue/RH-30004
Well thanks for your help Brian, i think the only way right now is use that single surface UV, now i just have to find a way to convert a circular map so that it will match, ive got a new challenge set for me,…
Edit: you know what Brian, i think this is actually easier anyway, thanks alot,…
I think you’re pointing out the seam at 12 o’clock right? If so, I bet you edited the UVs for the polysrf moving those edges away from the single surface/custom UV object or potentially the other way around. If you need to adjust the UVs do so in the editor for the custom object not the polysrf. Then reassign the custom object UV to the polysrf.
I also don’t have your texture map in the file to check. Please use Options>Rendering>Embed associated textures before saving the file. If this doesn’t work with Vray… Just also include the texture in the zip folder. In the screenshots It looks like you have a blend material set up, is this a Vray material and is Vray the active renderer? There are a few variables here that I’m unsure of but I bet what you’re seeing is due to editing the UVs of the polysrf or custom UV object and not reassigning it. Let’s also test all this with just Rhino Render to limit the variables.
I didnt edit the Uv’s and also, if i did, shouldnt the tire be updated? i only see that uv when i extract the mesh or when i go to uv editor, and in the uv editor it does show that the mesh is smaller than the image, but why is it not showing that in the viewport?
Sorry about that, i used vray’s pack scene, ill upload the jpg
Its not a vray material yet, i just rendered with vray, i have no material yet, this is basic rhino with a bitmap applied, the reason why i said its not vray is because as soon as i extract the render mesh, its a different mesh from the viewport mesh, well different UV’s,…
I only see this issue when using the custom UV object surface. I’ll file something for the developers to look at. I tried rebuilding the custom UV surface, rotating it so the seam didn’t match up with the polysrf and also making it periodic thinking maybe that was a factor. None of that helped and if the custom UV srf got the same material it looked just fine when rendered so… My hunch is that the comparison of the polysrf normals to the custom UV srf normals is the issue. The workaround I found was to make a custom mesh for the custom UV srf, extract that render mesh and then use it not the srf for the custom UV assignment. This appears to work fine in both the viewport and the vray render.
Custom mapping objects need to be ‘reapplied’ if they are edited - the target object does not automatically update to match. (The custom object does not need to even exist any more for the mapping from it to work.)
Hi @BrianJ,
some comments on the discussion and the suggested workflow.
You suggest not to use dense meshes for unwrapping.
I understand that the current version of the unwrapper will perform better with less geometry – still high resh meshes were a requirement when the user wanted to displace the tyre profile. For as long as Rhino doesn’t offer Multi-Resolution meshes where UV’s could be assigned to the basemesh good performance of the Unwrapper on HiRes meshes was very desirable.
You suggest to physically separate the model into several chunks.
That is something one really should avoid at any rate – especially with complex materials like gum, which possibly use Subsurface Scattering. Any advanced render engine would expect the render mesh to closed, it should actually even have the wall thickness of a typical tyre in the real world. I understand that by disassembling the model you come to better results, but there are superior approaches available which Rhino should offer instead.
Thanks for your feedback Holger. There is of course always more we can do in any area and hopefully the UV mapping feature requests currently on file (from both of us!) will help to effect positive changes over time. My main goal here was to help find some immediate solutions. If you have suggestions for other programs that you prefer for UV unwrapping feel free to mention those too.
