Any SU render engines that renders distorted textures?

thomthom

Tomasz: When you discover a distorted texture (from the Q value), and use TW to write out a unique material;

What UV values do you send to you renderer?
If the render material has a bumpmap applied to it - how is that handled? Won't you end up with mismatching bump?

Frederik

The method uses TW which crates 'a second texture'==additional 'Thea material'.

Yeah - that's what I thought...
This is - again - how everyone else is able to handle it...
However, I believe thomthom is trying to find out if this can be handled differently...

@thomthom said:

Yea, Make Unique generates a new texture and gives the face new UV co-ordinates.

What I'm trying to find out though, if there is any renderers that actually handles this. More importantly, I'm interesting in how they handle it.

IMHO, I hardly never see distorted textures used and thereby it has never been a great issue, certainly not a dealbreaker...

tomasz

@thomthom said:

What UV values do you send to you renderer?

When all textures has been loaded to TW I use:

					uvHelper=face.get_UVHelper(true, false, tw)
					point_pos=mesh.point_at(p).transform!(trans.inverse) #trans='nested transformation' of the parent
#thanks to Stefan Jaensch for figuring out that this trans has to be inverted and applied here
					uv=uvHelper.get_front_UVQ(point_pos)

@thomthom said:

If the render material has a bumpmap applied to it - how is that handled? Won't you end up with mismatching bump?

I use same UVs. I assume that the bumpmap is the same size as the main texture.

thomthom

@unknownuser said:

@thomthom said:

What UV values do you send to you renderer?

When all textures has been loaded to TW I use:

					uvHelper=face.get_UVHelper(true, false, tw)
> 					point_pos=mesh.point_at(p).transform!(trans.inverse) #trans='nested transformation' of the parent
> #thanks to Stefan Jaensch for figuring out that this trans has to be inverted and applied here
> 					uv=uvHelper.get_front_UVQ(point_pos)

@thomthom said:

If the render material has a bumpmap applied to it - how is that handled? Won't you end up with mismatching bump?

I use same UVs. I assume that the bumpmap is the same size as the main texture.

where do the p variable come from?

tomasz

@thomthom said:

where do the p variable come from?

It is an index(starting from 1) of a point in a PolygonMesh. You get the Polygon mesh from a face.mesh #.
You probably can get point position in other way.

thomthom

Also, why don't you use uv = mesh.uv_at(p, true)? Appears it would give the same result.

thomthom

If you use my Probes plugin: http://forums.sketchucation.com/viewtopic.php?f=323&t=21472#p180592

Press Tab to see raw UVQ data
By default it will use UVHelper to get the UV data
Press F2 to make it sample the data from the PolygonMesh

From my testing, the data never differs.

UVHelper seem to be made to sample UV data from a Face.
But if you have a PolygonMesh of the Face, it includes the UV data (provided you asked for that when you used face.mesh).

tomasz

@thomthom said:

Also, why don't you use uv = mesh.uv_at(p, true)? Appears it would give the same result.

I simply use UVHelper because it seems to be designed to this task. What would be the purpose of it otherwise?
I am not so sure if it would give same result for two distorted faces sharing same distorted texture (the last pair in the modified skp test scene).

BTW. I have found that there is some memory leak when using UVHelper, at least those objects are not being dumped well (rubbish collector). In my exporter I stay away from UVHelper as long as I can. I read uv coordinates in all other scenarios using uv_at.

tomasz

@thomthom said:

If you use my Probes plugin: http://forums.sketchucation.com/viewtopic.php?f=323&t=21472#p180592

Press Tab to see raw UVQ data
By default it will use UVHelper to get the UV data
Press F2 to make it sample the data from the PolygonMesh

From my testing, the data never differs.

UVHelper seem to be made to sample UV data from a Face.
But if you have a PolygonMesh of the Face, it includes the UV data (provided you asked for that when you used face.mesh).

Ok. Try this. Just load a face with distorted texture to the TW, then you will see the difference if you will use same TW to get uv from UVHelper.
What you have written is true as long as you use blank TW. It gives coordinates in relation to the original 'picture', but when you load a face to TW then it 'makes it unique inside TW' therefore uvs change.

It looks like this thread would better fit in the new developers section

Chris_at_Twilight

@unknownuser said:

I have never received false negatives by checking the 1.0 with enough precision.

Really? That's good to know. That's a much faster test.

As far as why some projected textures aren't distorted, I think Al and thomthom are both right, given the respective circumstance. It could be that the texture is not truly 'distorted' as Al suggest; it could be that the level of subdivision is high enough that you just don't see the distortion, like thomthom said.

And Tomasz hit it right on the head as far as using tw and uvhelper; you have to make sure you are using a tw 'loaded' with the face in question, before using it in the uvhelper.

thomthom

@unknownuser said:

if you will use same TW to get uv from UVHelper.

Use a TextureWriter to get UV data?

tomasz

@thomthom said:

@unknownuser said:

if you will use same TW to get uv from UVHelper.

Use a TextureWriter to get UV data?

It is the required parameter: uvHelper=face.get_UVHelper(true, false, **tw**)

thomthom

Aaah!!! That's why it asks for a TW. Duh!
That fills in a great hole in the API doc.

Thanks Tomaz!

thomthom

Here's a simple test I did. (doesn't take into account nested groups etc)
but it's a rough ruby version of Make Unique.

uv_make_unique.rb

distort test.skp

AdamB

Just a quick word as to what you're seeing.

The texture coordinates in SU are mostly 2d but there is support for projected textures in which the 3rd element of the texture coordinate is a projection. ie by dividing through by the 3 element you get a 2d texture coordinate.

You can get a ok approximation by doing the projection at the vertices and then interpolating across the polygon in 2d (this is what LightUp does), or you can interpolate the 3-element texture coordinate and do the divide at each pixel which is slower but you'll get the right answer. Not sure there are many renderers that do that.

Adam

AdamB

Oh, and the corollary of this is that if you subdivide the faces into smaller pieces, you'll get a progressively more accurate rendering. So try cutting the distorted quad into 16 quads.

Adam

tomasz

@adamb said:

You can get a ok approximation by doing the projection at the vertices and then interpolating across the polygon in 2d (this is what LightUp does), or you can interpolate the 3-element texture coordinate and do the divide at each pixel which is slower but you'll get the right answer. Not sure there are many renderers that do that.

SU is using OpenGL. Does it mean that SU, for its own 'rendering', does same interpolation and sends the 'unique' texture to OpenGL?

Al Hart

@unknownuser said:

SU is using OpenGL. Does it mean that SU, for its own 'rendering', does same interpolation and sends the 'unique' texture to OpenGL?

I suspect so - it is a lot faster to create the distorted image as a bitmap, and then send it to OpenGL - rather than starting to sub-divide faces.

Also, that would explain why SketchUp makes to pre-distorted image available to 3DS output and to us.

AdamB

@unknownuser said:

@adamb said:

You can get a ok approximation by doing the projection at the vertices and then interpolating across the polygon in 2d (this is what LightUp does), or you can interpolate the 3-element texture coordinate and do the divide at each pixel which is slower but you'll get the right answer. Not sure there are many renderers that do that.

SU is using OpenGL. Does it mean that SU, for its own 'rendering', does same interpolation and sends the 'unique' texture to OpenGL?

No, it means SU sends 3-component texture coordinates to OpenGL and allows OpenGL to interpolate and divide at each pixel.

But as Al says, given you can 'bake in' your projection to a unique texture once your happy, its not a big deal.

Adam

Chris_at_Twilight

@adamb said:

No, it means SU sends 3-component texture coordinates to OpenGL and allows OpenGL to interpolate and divide at each pixel.

Just as Adam says, OpenGL provides methods not just for 2 coordinates (UV), but 3 and even 4. glTexCoord3f, glTexCoord4f