Any SU render engines that renders distorted textures?
-
hm...
@unknownuser said:
This problem is rooted in the fact that SketchUp does not provide correct UV coordinates for distorted textures. Try rendering that scene in Podium (or another rendering engine) and you will see the same problem. AFAIK, the only renderer that supports rendering of distorted textures is Kerkythea.
-
HyperShot
Twilight
-
Ok. so far: Kerkythea and HyperShot.
-
Only Hypershot - the image from the Twilight is distorted. Hypershot converts everything to obj before rendering.
-
I saw Twilight was wrong. Though Whaat mentioned in his post whic I quoted that Kerkythea rendered correctly.
-
@aerilius said:
This example renders really well in Kerkythea, even with projected textures.
Actually, in that image, the distorted is not rendered correct.
-
Kerkythea does not render correctly same as Podium or Twilight.
I will try LUp later. -
Vue.
-
How does Vue work with SU?
-
Export to .3ds, open in Vue, hit render.
-
I see. So Vue doesn't read the Su data directly...
What does Hypershot do?
-
I have not used Podium or Twilight yet, but some days ago I read in the forum that they are based on the Kerkythea engine (???).
This example renders really well in Kerkythea, even with projected textures.
But I have experienced many times that distorted textures look strange and it's always an annoyance when everything is fine in SU and you have no idea what to correct:
Also some distorted textures can appear resized to ca. 10px width (then replace by original texture and it's ok). -
This is definitely a curious problem. Here's some thoughts on it.
This is an image from Twilight with the edge line drawn where Twilight triangulates the quad. It's quite obvious that the distortion moves in different direction on either side of the split. But what's important to notice is that the exact corners are not 'wrong'. As I'm sure you know, texture is mapped via UV, and those UV coordinates exist only where there are geometric vertices. They are basically anchor points for the texture, and here, the anchor points are correct. What is wrong is how the texture is interpolated between anchor points.
I think the difference is that SU uses a kind of 'quad' interpolation for textures, using four anchor points (even when the face is 3 or 5 or whatever sides), whereas Twilight, and probably many other applications, interpolates textures using only 3 anchor points because the math is fast (which makes for faster renders!). If so, this makes it a fairly fundamental difference that will be difficult to correct for.
What surprises me the most is the SU exports, at least in .3ds, in such a way that it's interpreted correctly in Vue. Is it Vue, or is it the export process? I'd be curious to see an export to .3ds and rendered in another app, like Kerkythea.
Anyway, I could be mistaken about the whole thing, but it seems a possible scenario.
-
interesting....
Indigo:
open skp and push render:
export as 3ds.. import 3ds and push render:
these are the settings i used for the 3ds export (i didn't try any other variations.. i set it like this first try and it worked)
-
Huh. The .3ds format only supports triangles (I think), so there is a way to represent the texture interpolation used by SU using only 3 UV coordinates (and the .3ds export knows it! )
-
I just tried an export with Collada and was amazed that, despite the fact that the UV coordinates were very simple, it somehow was distorting it correctly.
Well, turns out, the export produces an output texture that is "pre-distorted"
Is that what the .3ds export does? That may be the only way to do it, to distort the texture image rather than have the render app try to reproduce the mapping technique... -
another quick experiment... (indigo)
i made a sphere with quads, added a texture and used UVtools spherical mapping...
typical results when trying to render...
i then exported the sphere as a 3ds file and was wondering why it was taking so long.. well, 1100 separate jpgs were being exported to my desktop
(used two 48 segment circles for the sphere)when i brought i back into sketchup, you could see the individual jpgs and you can see it in the indigo render as well.. (but it did keep the mapping correct)
.
so i guess 3ds exporting is just making everything individual textures.. ?here's the material browser of the sphere after i brought the 3ds back in (note the scroll bar on the right side.. that's a very long texture list
-
@thomthom said:
I see. So Vue doesn't read the Su data directly...
What does Hypershot do?
There is a menu entry "Export to HyperShot" to open the scene inside HyperShot. In the HypeShot's installation folder there are executables XXXtoObj.exe for every supported file format - so, it converts everything to obj before rendering.
-
@chris_at_twilight said:
I think the difference is that SU uses a kind of 'quad' interpolation for textures, using four anchor points (even when the face is 3 or 5 or whatever sides), whereas Twilight, and probably many other applications, interpolates textures using only 3 anchor points because the math is fast (which makes for faster renders!). If so, this makes it a fairly fundamental difference that will be difficult to correct for.
Yes. This is what it seems to me as well from trying to make UV tools in SU. I found taking UV from vertices failed when it came to triangles and distorted textures.
I had to sample four points of the face's plane in order to get correct data set.
In SU, when you set UV mapping using.position_material, you don't set UV data per vertex, it only has to be UV data that related to points on the plane.But that had lead to problems when trying to use
PolygonMeshto sample, as thePolygonMeshonly returns UV data at each vertex. Meaning that I have not found any way to get correct data from that.So question is: how can SU's data be converted into a format that most renderer's and external program uses?
-
Important question:
If most other renders use 3 anchor points for UV mapping, how is a distorted texture defined? How can you define a distorted texture using only three points?
Advertisement