ambiguous texturing of non-triangles?

[simon]

when you texture a quad, (in the general case where the section of the texture and the face are different shapes), it seems to me that there are two ways to do it, one for each of the two ways the quad might be split into triangles, (splitting into triangles being necessary, i think, to be able to interpolate every point into the texture), and i cant see that the specification defines this, so from a vrml file you cant tell, for sure, which parts of the texture go where!

obviously no problem for triangles, or where the texture and face are the same shape, but for faces with a larger number of sides, the possibilities go exponential, not to mention what happens when you have non-convex faces.

BTW what i am trying to do is split, or combine, faces (that are in the same plane) whilst retaining the texturing.

[Joerg Scheurich aka MUFTI]

> when you texture a quad, (in the general case where the section of the
> texture and the face are different shapes), it seems to me that there are
> two ways to do it, one for each of the two ways the quad might be split
> into triangles,

The rules to generate texture coordinates for a shape are not ambiguous

http://web3d.org/x3d/specifications/vrml/ISO-IEC-14772-VRML97/part1/nodesRef.html#IndexedFaceSet

see Figure 6.10

> splitting into triangles being necessary, i think, to be able to interpolate
> every point into the texture)

TextureCoordinate define the assignment of edgepoints and texture points,
why do you need a triangle ?

Please try to demonstrate your problem with a VRML file similar
to the following:

#VRML V2.0 utf8

Transform
{
children
Shape
{
appearance DEF Appearance1 Appearance
{
material Material
{
}
texture PixelTexture
{
image 2 2 3
0x000000ff
0x0000ff00
0x00ff0000
0x00ffff00
}
}
geometry IndexedFaceSet
{
coord DEF Coordinate1 Coordinate
{
point
[
0 0 0
1 0 0
1 1 0
0 1 0
]
}
coordIndex
[
0
1
2
3
]
}
}
}

Transform
{
translation 0.10000000 2 0
children
Shape
{
appearance USE Appearance1
geometry IndexedFaceSet
{
coord USE Coordinate1
coordIndex
[
0
1
2
]
}
}
}

Transform
{
translation -0.10000000 2 0
children
Shape
{
appearance USE Appearance1
geometry IndexedFaceSet
{
coord USE Coordinate1
coordIndex
[
0
2
3
]
}
}
}

Transform
{
translation 0.10000000 -2 0
children
Shape
{
appearance USE Appearance1
geometry IndexedFaceSet
{
coord USE Coordinate1
coordIndex
[
1
2
3
]
}
}
}

Transform
{
translation -0.10000000 -2 0
children
Shape
{
appearance USE Appearance1
geometry IndexedFaceSet
{
coord USE Coordinate1
coordIndex
[
3
0
1
]
}
}
}

[simon]

i'll try to do an example in words, if you don't mind, i think it might be quicker;

suppose you texture a square quad (a face in an IFS) from texture coordinates that form a 'kite' http://en.wikipedia.org/wiki/Kite_(geometry) shape in the texture, then does the colour needed for the centre of the square face come from the pixel in the texture mid-way between the two wing tips or mid-way between the head and the tail?

[simon]

had a free moment, it didn't turn out to be that hard to show;

here the second object is just the same as the first but with the faces start vertex moved round one, (the standard seems to be built with the assumption that no visual effect depends on the start point of a face), however the result is completely different on my vrml viewer, clearly the texture triangulation is dependent on the start vertex! but since it doesn't seem to be defined in the standard, i guess it would be fine for another browser to have produced two identical squares.

#VRML V2.0 utf8

Transform
{
children
Shape
{
appearance DEF Appearance1 Appearance
{
material Material
{
}
texture PixelTexture
{
image 2 2 3
0x000000ff
0x0000ff00
0x00ff0000
0x00ffff00
}
}
geometry IndexedFaceSet
{
coord DEF Coordinate1 Coordinate
{
point
[
0 0 0
1 0 0
1 1 0
0 1 0
]
}
coordIndex
[
0
1
2
3
]

texCoord TextureCoordinate
{
point
[
0 0
0 .5
1 1
.5 0
]
}
}
}
}

Transform
{
translation 0 1.1 0

children
Shape
{
appearance DEF Appearance1 Appearance
{
material Material
{
}
texture PixelTexture
{
image 2 2 3
0x000000ff
0x0000ff00
0x00ff0000
0x00ffff00
}
}
geometry IndexedFaceSet
{
coord DEF Coordinate1 Coordinate
{
point
[

0 1 0

0 0 0
1 0 0
1 1 0

]
}
coordIndex
[
0
1
2
3
]

texCoord TextureCoordinate
{
point
[
.5 0
0 0
0 .5
1 1
]
}
}
}
}

[Joerg Scheurich aka MUFTI]

> however the result is completely different on my vrml viewer, clearly the
> texture triangulation is dependent on the start vertex! but since it
> doesn't
> seem to be defined in the standard, i guess it would be fine for another
> browser to have produced two identical squares.

At least freewrl and cosmoplayer render it differently, but none produce two
identical squares 8-(

so long
MUFTI
--
Anwendungen das "Vista" Certified for Windows-Logo von verdient haben
Stardevelop Pty Ltd Leben Sie Hilfemessenger 2.95.0
Micro$oft Knowledge Base Artikel-ID:933305 Version:1.2

[simon]

i would guess they all use the same 'lower level' texturing triangulation, so this hasn't presented, historically, any noticeable problem, but it seems to me that without the standard specifying this that was basically just luck.

and for me, trying to combine or split faces, the lack of a specification leads me to give up, since i cant be sure that im not wasting my time.

(also there may be other problems related to VRML's use of many sided faces, when lower levels only support triangles, so i think a specification for the conversion may solve other issues.)

[Joerg Scheurich aka MUFTI]

> (also there may be other problems related to VRML's use of many sided faces,
> when lower levels only support triangles, so i think a specification for the
> conversion may solve other issues.)

white_dune can convert almost any X3D shape (except NurbsSwungSurface,
NurbsTrimmedSurface and skin/bones based HAnimHumanoid which are not
rendered in white_dune) to triangles (e.g. for use in the java source
export with Java Monkey Engine or Open Wonderland).
Till now, i did not noticed any problems...

so long
MUFTI
--
Die 47800 ueblich-Beschluss-Fotos wollen pixelate leichter
als die 5400 Hallo-Beschluss-Fotos.
(aus einem Softwarehandbuch, Stichworte: common/high resolution)

[simon]

the start point chosen by browsers depends on the vertex order which effects the triangulation and so the texturing, see here;

Cosmo;

https://mail.google.com/mail/u/0/?ui=2&ik=1e67f5d81d&view=att&th=135ae76a9746a8bf&attid=0.1&disp=inline&safe=1&zw

freewrl;

https://mail.google.com/mail/u/0/?ui=2&ik=1e67f5d81d&view=att&th=135ae76a9746a8bf&attid=0.2&disp=inline&safe=1&zw

but, at least, both these browsers use the same underlying triangulation algorithm.

[simon]

view3dscene;

https://mail.google.com/mail/u/0/?ui=2&ik=1e67f5d81d&view=att&th=137d2d0bdc7782e3&attid=0.1&disp=inline&realattid=f_h393ok3m0&safe=1&zw

here a different algorithm has been chosen, highlighting the problem.

[simon]

BSContact


https://mail.google.com/mail/u/0/?ui=2&ik=1e67f5d81d&view=att&th=137d2df611eb011c&attid=0.1&disp=inline&realattid=f_h394de2l0&safe=1&zw

same as view3dscene, but maybe its OS/GPU/GPU driver dependent, since these two are the same machine and the other two another.