How can i change the side of surface with texture?

what attribute is responsible for the side of the surface on which the texture will apply?

Are you trying to render double-sided surface, if not what do you mean with side? AFAIK, COLLADA and most other formats only specifies an image and texcoords for texture, not side. If you want to render texture to other side of surface then you could negate NORMAL to light other side after activated/enabled two-sided rendering. In this way you could render two side with same texture.

But if you need different texture for back face then you may need you render that surface twice once for front face and once for back face. Or as alternative you could bind extra texture and if back face (simply by testing gl_FrontFacing) is being rendered then you could use different sampler.

In the end I am not aware of an attribute which specifies texture side. Except if your texture is cube texture then COLLADA defines face attribute in init_from element (follow image element in spec):

POSITIVE_X
NEGATIVE_X
POSITIVE_Y
NEGATIVE_Y
POSITIVE_Z
NEGATIVE_Y
POSITIVE_Z

of course COLLADA can be extended via extensions. You could write an extension for your needs if you use application/engine-specific features.

[QUOTE=recpas;43571]Are you trying to render double-sided surface, if not what do you mean with side? AFAIK, COLLADA and most other formats only specifies an image and texcoords for texture, not side. If you want to render texture to other side of surface then you could negate NORMAL to light other side after activated/enabled two-sided rendering. In this way you could render two side with same texture.
[/QUOTE]
Can you please give me the example with xml code where and what should i write to render double-sided surface.

Here an example of two-sided rendering: GLSL Programming/GLUT/Two-Sided Surfaces - Wikibooks, open books for an open world

If you have normal like vNormal in fragment shader, then you could use -vNormal as normal:

Disabling face culling will enable two-sided rendering.


glDisable(GL_CULL_FACE);

GLSL fragment shader:


in vec3 vNormal;

void main()
{
  if (gl_FrontFacing) {
      // color calculated using vNormal
      gl_FragColor = color;
  } else {
      vec3 N;

      N  = -vNormal;

      // color calculated using N

      gl_FragColor = color;
  }
}


I think no need to give XML/COLLADA example since it doesn’t matter for double-sided rendering. But in the future an extension would be great for specifying if material is double-sided. AFAIK, currently there is no such attrib like this (there is one in glTF)

I guess this will render back face same as front.

i work only with collada file, so i can change xml only. i see in spec 1.5 that there is semantic attribute with double_sided. I also find:
<extra>
<technique profile=“GOOGLEEARTH”>
<double_sided>1</double_sided>
</technique>
</extra>
But nothing from this help me to have texture on both side of my surface.

It doesn’t matter what data you put in COLLADA file as semantic or as extra/extension. Importer and/or renderer must parse and understand that data, otherwise it will no affect. It is not issue related to COLLADA, It is all about how importers and engines implemented COLLADA, AFAIK not all importers support all COLLADA features.

IIRC, you mentioned about web, do you use THREE.js or something? Maybe you could ask them about double-sided is supported or not (if this is what you really want). Probably double-sided is supported in engine you use, since you need to pass this info via COLLADA file, importer/engine must support this feature.

i use c# to create xml with collada and export it in cesium (smth like google earth).

      • Updated - - -

i also try to change normal array to change side of surface but nothing changed too

Cesium has great community, you may want to move this issue to there: GitHub - CesiumGS/cesium: An open-source JavaScript library for world-class 3D globes and maps by creating new issue: Sign in to GitHub · GitHub

Thank you.

Going by the manual, there is mention of <semantic>DOUBLE_SIDED</semantic> used with <param> or <newparam> or <setparam> for instance via <material><instance_effect>.

I think the Cg profile may have built-in parameters for this. The GLSL profile is more open-ended, but you can program shaders that branch on a fragments side-of-the-face.

P.S. Sorry for my absence! I have not been receiving notifications about new posts in this forum, and so forgot it existed. Sorry. On the plus side, there is just two new threads. I thought there were more because I hadn’t posted in some, but I do remember the others. I have to figure out why I am not receiving notifications:!:

Off-Topic/Follow-up: The webmaster tells me I helped to notice a vBulletin bug they’d suspected themself that they’ve promptly addressed overnight. It’s funny but I think the vBulletin team didn’t know about it… although could be it was not as simple as just not sending mail for subscriptions (or notifications?)

FWIW, I get email notifications for new forum threads or updates, but I do not get email notifications for Inbox/Messages (don’t know how to fix it) :S

Off-topic/@recp I have received notifications for the last two replies, so it seems like the webmaster (James) did fix the problem. They said there was not a single post to the OpenGL.org forum in the period where notifications were broken. BTW: They are trying to merge the OpenGL.org forum into these forums, and for a long time (like 2yrs) they’ve been trying to switch to a different forum software.

P.S. For a few days now I’ve been doing work in service of COLLADA again: COLLADA Document Object Model (DOM) / Discussion / Open Discussion: Namespaces: New round of work (late 2018)

(I’m now working on the namespace problem, that is fortunate because the last work I did was adding xs:anyAttribute to COLLADA-DOM, even though COLLADA itself doesn’t use it. However I did it mainly to have an xs:anySimpleType, and to be lossless… in theory to work with other COLLADA unrelated schemas. BUT AS IT TURNS OUT without realizing it, it laid a groundwork for XMLNS support, since the xmlns attributes work exactly like xs:anyAttribute. It makes the most sense to to not have a special pathway for XMLNS. Namespaces are actually a very hard problem when it comes to moving elements around in a document, because it’s not obvious how to interpret the prefixes after a move. I’m interested to find out how this is going to work.)