Thomas de Groot wrote:
> "clipka" <ano### [at] anonymousorg> schreef in bericht 
> news:4aef52aa@news.povray.org...
> 
>> Why? It only complicates matters; for instance, if you want to use 
>> different include files for different frames of an animation, having the 
>> same figure carry the same name is of an advantage.
>>
>> If it is about getting two figures of same base name in a single scene, it 
>> may be easier, too, as in:
>>
>> #declare MyFigures = array[10];
>> #local i = 1;
>> #while (i <= 10)
>>   #include concat("Beggar", str(i,0,0), "_POV_geom.inc");
>>   #declare MyFigures[i-1] = object { Beggar_ }
>>   #local i = i + 1;
>> #end
> 
> Well, it seems inconsistent to me. If I change the name of the file for one 
> reason or another (for instance because I changed the materials but want to 
> keep the original too at the same time), I expect the name of the figure to 
> change too in order to avoid inconsistencies and confusion later in the POV 
> scene.
> 
> Your example is of course also valid, so maybe this change should be 
> optional.
> 
> Thomas
> 
> 

I will look into making it optional if it relatively easy to do.

FlyerX

Post a reply to this message

It appears that the place were the uv_mapping code is placed in the latest 
version of Poseray generates a faulty rendering of transparant materials.

In the present version, uv_mapping is coded in the xxxx_POV_mat.inc file as 
follows:

#declare MyTex_=
material{
texture{ pigment{uv_mapping p_map1}
        finish{specular 0 roughness 0.00286312 ambient rgb <0.00,0.00,0.00> 
diffuse 0.8   reflection{0 } conserve_energy}}
}

or, in the case of a transparancy map:

#declare MyTex__opaque=
texture{ pigment{uv_mapping p_map1}
        normal{uv_mapping p_map2 bump_size -6.192}
        finish{specular 0 roughness 0.00286312 ambient rgb <0.00,0.00,0.00> 
diffuse 0.8   reflection{0 } conserve_energy}}
#declare MyTex_=
material{
texture{  pigment_pattern{uv_mapping p_map3}
texture_map{[0 pigment{Clear}]
            [1 MyTex__opaque]
           }}
}

In particular the alpha channel of the first example does *not* work for the 
shadow casting. In order for this to work in all cases, the code should be 
written as in a previous version of Poseray, i.e. the uv_mapping code is 
written in the xxx_POV_geom.inc file and *not* in the xxx_POV_mat.inc one. 
As follows:

//Model assembly from the meshes
#declare My_Figure_=
union {
object{My_Figure_1_  uv_mapping material{MyTex_1_}}
object{My_Figure_2_  uv_mapping material{MyTex_2_}}
etc...
}

This construction provides a correct render of the transparancy of the alpha 
channel.

Thomas

Post a reply to this message

Thomas de Groot wrote:
> #declare My_Figure_=
> union {
> object{My_Figure_1_  uv_mapping material{MyTex_1_}}
> object{My_Figure_2_  uv_mapping material{MyTex_2_}}
> etc...
> }
> 
> This construction provides a correct render of the transparancy of the alpha 
> channel.
> 
> Thomas

I see your point but as I do never use the material files as generated 
by PoseRay this would force me to also edit the geometry file every time 
I convert an object file. I *need* separate control about the pigment or 
normals or both being uv_mapped for multiple reasons.

A solution that should help us both would be to put the uv_mapping 
statement directly into the texture block and not into the 
pigment/normal blocks like:

material {
   texture {
     uv_mapping
     pigment {MyPigment}
     normal {MyNormal}
   }
}

As far as I do remember this does also solve the transparency by alpha 
channel problem.

-Ive

Post a reply to this message

"Ive" <"ive### [at] lilysoftorg"> schreef in bericht 
news:4afbe599@news.povray.org...
>
> I see your point but as I do never use the material files as generated by 
> PoseRay this would force me to also edit the geometry file every time I 
> convert an object file. I *need* separate control about the pigment or 
> normals or both being uv_mapped for multiple reasons.
>
> A solution that should help us both would be to put the uv_mapping 
> statement directly into the texture block and not into the pigment/normal 
> blocks like:
>
> material {
>   texture {
>     uv_mapping
>     pigment {MyPigment}
>     normal {MyNormal}
>   }
> }
>
> As far as I do remember this does also solve the transparency by alpha 
> channel problem.
>

Yes indeed. This is also the solution proposed by Clipka by the way and it 
is certainly more elegant. My suggestion was just a step back to an earlier 
version, but I admit that it is not the most ideal.

When using a transparency map instead of using the alpha channel, the code 
in Poseray should then also be as follows (note the place of uv_mapping) 
e.g.:

//Material definitions
#declare MyTexTex__opaque=
texture {
  uv_mapping
  pigment { p_map1}
  normal {MyNormal}
  finish {MyFinish}
}
#declare MyTexTex_=
material {
  texture {
    uv_mapping
    pigment_pattern { p_map2}
    texture_map {
      [0 MyTex__opaque]
      [1 pigment {Clear}]
    }
  }
}

Thomas

Post a reply to this message

OK. To reduce confusion as I typed twice the same term:

//Material definitions
#declare MyTex__opaque=
texture {
  uv_mapping
  pigment { p_map1}
  normal {MyNormal}
  finish {MyFinish}
}
#declare MyTex_=
material {
  texture {
    uv_mapping
    pigment_pattern { p_map2}
    texture_map {
      [0 MyTex__opaque]
      [1 pigment {Clear}]
    }
  }
}


Thomas

Post a reply to this message

Thomas de Groot wrote:
> When using a transparency map instead of using the alpha channel, the code 
> in Poseray should then also be as follows (note the place of uv_mapping) 
> e.g.:
> 
> //Material definitions
> #declare MyTexTex__opaque=
> texture {
>   uv_mapping
>   pigment { p_map1}
>   normal {MyNormal}
>   finish {MyFinish}
> }
> #declare MyTexTex_=
> material {
>   texture {
>     uv_mapping
>     pigment_pattern { p_map2}
>     texture_map {
>       [0 MyTex__opaque]
>       [1 pigment {Clear}]
>     }
>   }
> }

As a side note, usually I do use a construct like this:

#local MyTexTex_opaque =
  texture {
    uv_mapping
    pigment { p_map1}
    normal {MyNormal}
    finish {MyFinish}
  }

#local MyTexTex_trans =
  texture {
    uv_mapping
    pigment { p_map1 transmit 1}
    normal {MyNormal}
    finish {MyFinishButWithoutAnySpecularPhongAndReflection}
  }

  #declare MyTexTex_=
  material {
    texture {
      uv_mapping
      pigment_pattern { p_map2}
      texture_map {
        [0 MyTex_opaque]
        [1 MyTex_trans]
      }
    }
  }


This does not make *much* of a difference but occasionally for closeup 
shots and things like lace pattern or trans-mapped hair it looks better.

-Ive

Post a reply to this message

I put the uv_mapping inside the pigment and normal for more control. As 
shown in the POV-Ray manual it can inside or outside of these 
statements. I did not notice a problem because I have not used textures 
with alpha channels in a very long time. Automatically putting 
uv_mapping outside the pigment and normal should not be a problem. 
Thanks for the suggestions.

The material structure has changed significantly in format in the latest 
PoseRay because it now supports specular and transparency mapping at the 
same time. Also I dropped the use of the predefined Clear pigment with 
transparency mapping since I was having problems with it. I replaced it 
by color rgbft<0,0,0,1,1>. I do not remember exactly the reason (I will 
have to review my notes) but I believe the transparency at the edges was 
not working well with Clear.

I will try to release a preliminary version of PoseRay this week since 
it has some of the many changes that were suggested in this forum plus 
other fixes.

Below are samples of the new PoseRay-generated materials. They have the 
transformation at the end of each map. If any of you see anything wrong 
with them please let me know (besides the uv_mapping issue). Most likely 
I will have to define the textures before plugging them into the 
texture_map entries so that uv_mapping could be placed outside the pigment.

pigment only:
http://mysite.verizon.net/sfg0000/files/p.txt

pigment only but multiplied by a color:
http://mysite.verizon.net/sfg0000/files/p_m.txt

pigment+transparency:
http://mysite.verizon.net/sfg0000/files/p_t.txt

pigment+finish+normal+transparency:
http://mysite.verizon.net/sfg0000/files/p_n_f_t.txt

pigment+finish+normal:
http://mysite.verizon.net/sfg0000/files/p_n_f.txt

pigment+normal:
http://mysite.verizon.net/sfg0000/files/p_n.txt

FlyerX

Ive wrote:
> Thomas de Groot wrote:
>> When using a transparency map instead of using the alpha channel, the 
>> code in Poseray should then also be as follows (note the place of 
>> uv_mapping) e.g.:
>>
>> //Material definitions
>> #declare MyTexTex__opaque=
>> texture {
>>   uv_mapping
>>   pigment { p_map1}
>>   normal {MyNormal}
>>   finish {MyFinish}
>> }
>> #declare MyTexTex_=
>> material {
>>   texture {
>>     uv_mapping
>>     pigment_pattern { p_map2}
>>     texture_map {
>>       [0 MyTex__opaque]
>>       [1 pigment {Clear}]
>>     }
>>   }
>> }
> 
> As a side note, usually I do use a construct like this:
> 
> #local MyTexTex_opaque =
>  texture {
>    uv_mapping
>    pigment { p_map1}
>    normal {MyNormal}
>    finish {MyFinish}
>  }
> 
> #local MyTexTex_trans =
>  texture {
>    uv_mapping
>    pigment { p_map1 transmit 1}
>    normal {MyNormal}
>    finish {MyFinishButWithoutAnySpecularPhongAndReflection}
>  }
> 
>  #declare MyTexTex_=
>  material {
>    texture {
>      uv_mapping
>      pigment_pattern { p_map2}
>      texture_map {
>        [0 MyTex_opaque]
>        [1 MyTex_trans]
>      }
>    }
>  }
> 
> 
> This does not make *much* of a difference but occasionally for closeup 
> shots and things like lace pattern or trans-mapped hair it looks better.
> 
> -Ive

Post a reply to this message

"FlyerX" <fly### [at] yahoocom> schreef in bericht 
news:4afc715e@news.povray.org...
>I put the uv_mapping inside the pigment and normal for more control. As 
>shown in the POV-Ray manual it can inside or outside of these statements. I 
>did not notice a problem because I have not used textures with alpha 
>channels in a very long time. Automatically putting uv_mapping outside the 
>pigment and normal should not be a problem. Thanks for the suggestions.

Youa re welcome :-)

>
> The material structure has changed significantly in format in the latest 
> PoseRay because it now supports specular and transparency mapping at the 
> same time. Also I dropped the use of the predefined Clear pigment with 
> transparency mapping since I was having problems with it. I replaced it by 
> color rgbft<0,0,0,1,1>. I do not remember exactly the reason (I will have 
> to review my notes) but I believe the transparency at the edges was not 
> working well with Clear.

Ah yes. I think that I have noticed that as a side effect indeed.

>
> I will try to release a preliminary version of PoseRay this week since it 
> has some of the many changes that were suggested in this forum plus other 
> fixes.

Great! Looking forward to it!

>
> Below are samples of the new PoseRay-generated materials. They have the 
> transformation at the end of each map. If any of you see anything wrong 
> with them please let me know (besides the uv_mapping issue). Most likely I 
> will have to define the textures before plugging them into the texture_map 
> entries so that uv_mapping could be placed outside the pigment.
>
> pigment only:
> http://mysite.verizon.net/sfg0000/files/p.txt

- I am not sure if a diffuse 1 is such a good idea. I prefer 0.6, or 0.8 
when using an image map, like in the current version .
- Why a *double* declare for the pigment? It seems to me that only one 
should be enough, either PR_MAP_DIFFUSE or PF (well, I see some consistency 
now with the other pigments)

>
> pigment only but multiplied by a color:
> http://mysite.verizon.net/sfg0000/files/p_m.txt

- Neat! I like this. I believe that this will work much better than the 
current, rather crude, texture layering.

>
> pigment+transparency:
> http://mysite.verizon.net/sfg0000/files/p_t.txt

- OK. I see the change from Clear. Certainly works better.

>
> pigment+finish+normal+transparency:
> http://mysite.verizon.net/sfg0000/files/p_n_f_t.txt

- This is a difficult one. I need to test this to see how it works. My first 
impression is that it looks fine however.

>
> pigment+finish+normal:
> http://mysite.verizon.net/sfg0000/files/p_n_f.txt

- Same as above.

>
> pigment+normal:
> http://mysite.verizon.net/sfg0000/files/p_n.txt

- I think you put the wrong example file here. No normal visible.


Looking good overall. I am thrilled!

Thomas

Post a reply to this message

Thomas de Groot wrote:
> "FlyerX" <fly### [at] yahoocom> schreef in bericht 
> news:4afc715e@news.povray.org...
>> I put the uv_mapping inside the pigment and normal for more control. As 
>> shown in the POV-Ray manual it can inside or outside of these statements. I 
>> did not notice a problem because I have not used textures with alpha 
>> channels in a very long time. Automatically putting uv_mapping outside the 
>> pigment and normal should not be a problem. Thanks for the suggestions.
> 
> Youa re welcome :-)
> 
>> The material structure has changed significantly in format in the latest 
>> PoseRay because it now supports specular and transparency mapping at the 
>> same time. Also I dropped the use of the predefined Clear pigment with 
>> transparency mapping since I was having problems with it. I replaced it by 
>> color rgbft<0,0,0,1,1>. I do not remember exactly the reason (I will have 
>> to review my notes) but I believe the transparency at the edges was not 
>> working well with Clear.
> 
> Ah yes. I think that I have noticed that as a side effect indeed.
> 
>> I will try to release a preliminary version of PoseRay this week since it 
>> has some of the many changes that were suggested in this forum plus other 
>> fixes.
> 
> Great! Looking forward to it!
> 
>> Below are samples of the new PoseRay-generated materials. They have the 
>> transformation at the end of each map. If any of you see anything wrong 
>> with them please let me know (besides the uv_mapping issue). Most likely I 
>> will have to define the textures before plugging them into the texture_map 
>> entries so that uv_mapping could be placed outside the pigment.
>>
>> pigment only:
>> http://mysite.verizon.net/sfg0000/files/p.txt
> 
> - I am not sure if a diffuse 1 is such a good idea. I prefer 0.6, or 0.8 
> when using an image map, like in the current version .
> - Why a *double* declare for the pigment? It seems to me that only one 
> should be enough, either PR_MAP_DIFFUSE or PF (well, I see some consistency 
> now with the other pigments)
> 
>> pigment only but multiplied by a color:
>> http://mysite.verizon.net/sfg0000/files/p_m.txt
> 
> - Neat! I like this. I believe that this will work much better than the 
> current, rather crude, texture layering.
> 
>> pigment+transparency:
>> http://mysite.verizon.net/sfg0000/files/p_t.txt
> 
> - OK. I see the change from Clear. Certainly works better.
> 
>> pigment+finish+normal+transparency:
>> http://mysite.verizon.net/sfg0000/files/p_n_f_t.txt
> 
> - This is a difficult one. I need to test this to see how it works. My first 
> impression is that it looks fine however.
> 
>> pigment+finish+normal:
>> http://mysite.verizon.net/sfg0000/files/p_n_f.txt
> 
> - Same as above.
> 
>> pigment+normal:
>> http://mysite.verizon.net/sfg0000/files/p_n.txt
> 
> - I think you put the wrong example file here. No normal visible.
> 
> 
> Looking good overall. I am thrilled!
> 
> Thomas
> 
> 
Fixed the pigment+normal sample. The double pigment comes from the color 
multiplication. To avoid extra coding I just left it as is in case the 
material has other layering. It is wasteful and I will look into 
cleaning that up.

FlyerX

Post a reply to this message

"FlyerX" <fly### [at] yahoocom> schreef in bericht 
news:4afd8e82@news.povray.org...

> Fixed the pigment+normal sample. The double pigment comes from the color 
> multiplication. To avoid extra coding I just left it as is in case the 
> material has other layering. It is wasteful and I will look into cleaning 
> that up.
>

Looking good. I think this is going to be a major improvement of Poseray. 
Maybe others will come up with further comments, but at this stage I see 
nothing wrong. A little testing round later may of course bring up 
something.

Thomas

Post a reply to this message