Texture stretch

[runxel]

Can I somehow stretch a texture (be it inline or project based)?

I can set the origin with COOR{3} – but I can't figure out how to stretch a texture to be a certain size.

The vectors seem to be realigned to be unit vectors, so their length don't contribute anything.

Am I missing something, or is it just not possible? (At least with Nurbs it is doable, afaik)

[Piotr Dobrowolski]

The streching should be defined in the material def.

Piotr

[runxel]

That's what I feared!

And yeah, makes sense most of the time, no doubt.

But there are cases, where I want to have rather "symbolic" textures, to spice up the BimX model, which would otherwise look a bit bland.

[Piotr Dobrowolski]

Make a material def parametrized...but it would work only for the inline materials

[runxel · Accepted solution]

I had a look again. See the following comments on this situation:

There's the PICTURE command.
This places a polygon with the referenced picture as face.
However this implicit polygon still has a material definition, as explained in the manual (under "miscellaneous").
The material and the texture will be combined together. This holds true for any inlined material, too!

E.g. in my case I had a refelective material. In that case the emission RGB is the color which determines the look in the shaded views. But this color will also be set against the texture! If your emission e.g. is fully black, the texture won't be visible at all.

There is the PIPG command as a combination of PICTURE and PGON. This one is just mysterious.

There is VERT and TEVE. Verts are integrated into COOR{3}, but to me this doesn't seem to make any difference, as this is only the definition of the coordinate system but can't warp or stretch textures – as stated above. TEVE on the other hand might be able to do this, but I haven't tested it. The manual states it would only make any difference in the photorealistic view (rendering). That would defy my purpose because I want to have the texture stretched in BimX and the OpenGL viewport.

In the end I just looked in the wrong place:
Instead of stretching the texture in the material definition you do it in the texture definition.
So you'll need to be sure your texture image is in the loaded library.

See example code:

define texture "mytexture" "texture.png", A, B, 128+256, 0

define material "mymat" 20, !/* type (n ⇒ 19) */
   0.8, 0.8, 0,             !/* surface RGB [0.0 .. 1.0] */
   0.0, 0.0, 0, 0,          !/* ambient, diffuse, specular, transparent
      ! coefficients [0.0 .. 1.0] */
   100,           !/* shining [0.0 .. 100.0] */
   0,             !/* transparency attenuation [0.0 .. 4.0] */
   0.8, 0.8, 0.8, !/* specular RGB [0.0 .. 1.0] */
   1, 1, 1,       !/* emission RGB [0.0 .. 1.0] */
   0,             !/* emission attenuation [0.0 .. 65.5] */
   ind(FILL, "Empty Fill"), !/* hatch */
   0,             !/* special value `0` ⇒ use current pen for vectorial hatch */
   ind(TEXTURE, "mytexture")

set material "mymattest"

_idm = ind(MATERIAL, "mymat")  !/* the `ind` will resolve to `-1` */

cprism_{4} "mymat", "mymat", "mymat",
   0,
   4, 1,
   0, 0, 0, 15, _idm,
   1, 0, 0, 15, _idm,
   1, 1, 0, 15, _idm,
   0, 0, 0, -1, _idm

!/* Even tho cprism_{4} works with inline materials,
!   the material for the sides still has to be delivered
!   as an index (integer); you can't use strings there. */

[Piotr Dobrowolski]

I was thinking about just that...(I was told already that my words sometimes are too "short" in describing something)

Piotr