POV-Ray : Newsgroups : povray.tools.poser : Future implementations of Poseray. A wish list Server Time
28 Mar 2024 11:49:13 EDT (-0400)
  Future implementations of Poseray. A wish list (Message 11 to 20 of 22)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 2 Messages >>>
From: clipka
Subject: Re: Future implementations of Poseray. A wish list - an additional wish
Date: 2 Nov 2009 16:44:10
Message: <4aef52aa@news.povray.org>
Thomas de Groot schrieb:
> If, when saving a figure to POV-Ray, one changes the file name, this name 
> should also be changed accordingly at the declared figure name, within the 
> xxx_POV_geom.inc.
> 
> Thus, an original Poser figure *Beggar*, saved under the file name: 
> Beggar2_POV_geom.inc
> 
> should contain:
> 
> //Model assembly from the meshes
> #declare Beggar2_=
> union {
> .....
> }
> 
> instead of:
> 
> //Model assembly from the meshes
> #declare Beggar_=
> union {
> .....
> }
> 
> as happens under the present version of Poseray.

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


Post a reply to this message

From: Thomas de Groot
Subject: Re: Future implementations of Poseray. A wish list - an additional wish
Date: 3 Nov 2009 03:36:16
Message: <4aefeb80$1@news.povray.org>
"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


Post a reply to this message

From: FlyerX
Subject: Re: Future implementations of Poseray. A wish list - an additional wish
Date: 3 Nov 2009 12:00:17
Message: <4af061a1$1@news.povray.org>
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

From: Thomas de Groot
Subject: Re: Future implementations of Poseray. Place of uv_mapping code
Date: 12 Nov 2009 04:40:18
Message: <4afbd802$1@news.povray.org>
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

From: Ive
Subject: Re: Future implementations of Poseray. Place of uv_mapping code
Date: 12 Nov 2009 05:38:17
Message: <4afbe599@news.povray.org>
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

From: Thomas de Groot
Subject: Re: Future implementations of Poseray. Place of uv_mapping code
Date: 12 Nov 2009 08:22:01
Message: <4afc0bf9@news.povray.org>
"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

From: Thomas de Groot
Subject: Re: Future implementations of Poseray. Place of uv_mapping code
Date: 12 Nov 2009 08:26:07
Message: <4afc0cef$1@news.povray.org>
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

From: Ive
Subject: Re: Future implementations of Poseray. Place of uv_mapping code
Date: 12 Nov 2009 12:23:33
Message: <4afc4495@news.povray.org>
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

From: FlyerX
Subject: Re: Future implementations of Poseray. Place of uv_mapping code
Date: 12 Nov 2009 15:34:38
Message: <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.

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

From: Thomas de Groot
Subject: Re: Future implementations of Poseray. Place of uv_mapping code
Date: 13 Nov 2009 04:57:15
Message: <4afd2d7b@news.povray.org>
"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

<<< Previous 10 Messages Goto Latest 10 Messages Next 2 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.