I have made a small list of features I would like to see implemented in a 
future version of Poseray. These features are derived from cases met in the 
use of Poseray, in combination with Poser and/or external modellers.



1 Naming a POV-Ray export of merged meshes



After using the "Merge 3D model..." command under "Load...", the exported 
(merged) object to POV-Ray should have a specific name. Presently, the name 
given in the "Model assembly from the meshes" section of the 
xxx_POV_geom.inc file, is derived from the *last* of the merged object. 
Example of what is exported now:



//Model assembly from the meshes

#declare MyObject_Third_=

object{ MyObject _ Third _First_  material{First_} hollow}

object{ MyObject _ Third _Second_  material{Second_} hollow}

object{ MyObject _ Third _Third_  material{Third_} hollow}

}



This should either be declaring the name MyObject_ or a name given through a 
selection box. The result should then be either:



//Model assembly from the meshes

#declare MyObject_=

object{ MyObject _First_  material{First_} hollow}

object{ MyObject _Second_  material{Second_} hollow}

object{ MyObject _Third_  material{Third_} hollow}

}



or, with a name given separately:



//Model assembly from the meshes

#declare MyMergedObject_=

object{ MyObject _First_  material{First_} hollow}

object{ MyObject _Second_  material{Second_} hollow}

object{ MyObject _Third_  material{Third_} hollow}

}





2 Saving uv transformations in the Materials section



It is sometimes necessary to, e.g. scale up or down the uv of a material in 
order to better fit it to the mesh. This can be done in Poser too, however 
the result is not exported/imported into Poseray, so additional 
transformation on the uv is needed there. Like the other material 
parameters, it would be important to be able to save these transformations 
to file for future use, preferably into the same xxx_material_settings.mtl 
file.





3 Showing (and using) the origin of the object in the Preview window



The origin of the object should be visible in the Preview window (three 
axis). This origin may not be identical to the World origin, so both should 
be visible. Note that this is not identical to the orientation axis already 
visible which is not related to the origin itself. In addition, a 
possibility to translate the object towards the World origin, if necessary, 
could be considered.



-- 
All the best,

Thomas

Post a reply to this message

Thomas de Groot wrote:
> I have made a small list of features I would like to see implemented in a 
> future version of Poseray. These features are derived from cases met in the 
> use of Poseray, in combination with Poser and/or external modellers.
> 
> 
> 
> 2 Saving uv transformations in the Materials section
> 
> 
> 
> It is sometimes necessary to, e.g. scale up or down the uv of a material in 
> order to better fit it to the mesh. This can be done in Poser too, however 
> the result is not exported/imported into Poseray, so additional 
> transformation on the uv is needed there. Like the other material 
> parameters, it would be important to be able to save these transformations 
> to file for future use, preferably into the same xxx_material_settings.mtl 
> file.


I support your wish list, Thomas. I hope that you have submitted it to 
FlyerX :-)

Your second point is interesting. I have been complaining that Bishop3D 
actually imports the complete PoseRay generated meshes into the scene. 
While Moray uses the UDO in the scene and the full mesh and materials 
are only included. One advantage of this is, in B3D, that you can edit 
the mesh materials directly and it is saved in the Bishop3D file for 
exporting.


-- 

Best Regards,
	Stephen

Post a reply to this message

Thomas de Groot wrote:
> I have made a small list of features I would like to see implemented in a 
> future version of Poseray. These features are derived from cases met in the 
> use of Poseray, in combination with Poser and/or external modellers.
> 
> 
> 
> 1 Naming a POV-Ray export of merged meshes
PoseRay exports the mesh by default by material. PoseRay does keep the 
groups and materials separate when merging a mesh by adding a number at 
the end of the material or group name if it already exists. I could 
create a higher level entity (object) for each mesh read. That way the 
merged meshes could be kept separate with their own materials. Like this 
for 3 meshes with 2, 4 and 3 materials respectively:

//in the geometry file...
#declare object1=
union{
object(object1_material1 material{material1} hollow}
object(object1_material2 material{material2} hollow}
}

#declare object2=
union{
object(object2_material4 material{material3} hollow}
object(object2_material5 material{material4} hollow}
object(object2_material6 material{material5} hollow}
object(object2_material6 material{material6} hollow}
}

#declare object3=
union{
object(object3_material7 material{material7} hollow}
object(object3_material8 material{material8} hollow}
object(object3_material9 material{material9} hollow}
}


//in the scene file...
object{object1}
object{object2}
object{object3}

if only a mesh is exported then the exported files would look as they do 
now. For those wondering why hollow is because it allows media to work 
inside the mesh.


> 
> 2 Saving uv transformations in the Materials section

I will look into the U and V scale, offset and mirror for image_map 
entries in the Poser materials. I have Poser 6 so I cannot test it for 
later versions but I doubt it will change.

> 
> 3 Showing (and using) the origin of the object in the Preview window
> 

Relatively easy to do and could be toggled.

Post a reply to this message

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

> PoseRay exports the mesh by default by material. PoseRay does keep the 
> groups and materials separate when merging a mesh by adding a number at 
> the end of the material or group name if it already exists. I could create 
> a higher level entity (object) for each mesh read. That way the merged 
> meshes could be kept separate with their own materials. Like this for 3 
> meshes with 2, 4 and 3 materials respectively:

Yes, that would answer my question to satisfaction.

>
> I will look into the U and V scale, offset and mirror for image_map 
> entries in the Poser materials. I have Poser 6 so I cannot test it for 
> later versions but I doubt it will change.

I think those have not changed. I have Poser 8 so I can test it for you.


>> 3 Showing (and using) the origin of the object in the Preview window
>
> Relatively easy to do and could be toggled.

Thank you! Neat!

Thomas

Post a reply to this message

"Stephen" <mca### [at] aolDOTcom> schreef in bericht 
news:4adadc7f$1@news.povray.org...
> I support your wish list, Thomas. I hope that you have submitted it to 
> FlyerX :-)

Well, FlyerX found it here already :-)
I wanted to post the list here so that people could comment and/or add their 
own wishes (if any).

>
> Your second point is interesting. I have been complaining that Bishop3D 
> actually imports the complete PoseRay generated meshes into the scene. 
> While Moray uses the UDO in the scene and the full mesh and materials are 
> only included. One advantage of this is, in B3D, that you can edit the 
> mesh materials directly and it is saved in the Bishop3D file for 
> exporting.

In that regard, Moray is lacking in functionality, but we knew that already 
:-)  Moray 4.0 will overcome all that ;-)
My motives in my second point are: first the possibility to transform the uv 
one way or another: basically in Poser and export those settings to Poseray 
and beyond; secondarily, doing this in Poseray and save those 
transformations in the settings mtl file; as a last resort doing 
transformations directly into the POV-Ray material file which is much less 
elegant although giving similar results. The first and second options are my 
favourite ones
and need some further implementation in Poseray to become powerful tools.

Thomas

Post a reply to this message

FlyerX schrieb:
> Thomas de Groot wrote:
>> I have made a small list of features I would like to see implemented 
>> in a future version of Poseray. These features are derived from cases 
>> met in the use of Poseray, in combination with Poser and/or external 
>> modellers.
>>
>>
>>
>> 1 Naming a POV-Ray export of merged meshes

I would like to add to this request:

 From what I see, the output file names are generated from the input 
file names as well, and therefore do depend on the oder in which meshes 
are added to the merger.


Another thing:

For me, it would often be desirable to export geometry only, and keep 
the material export "unharmed", so I can change the pose of a figure 
without having to re-do all the changes to the materials again. (I 
prefer to edit them after export.)

Post a reply to this message

clipka wrote:
> FlyerX schrieb:
>> Thomas de Groot wrote:
>>> I have made a small list of features I would like to see implemented 
>>> in a future version of Poseray. These features are derived from cases 
>>> met in the use of Poseray, in combination with Poser and/or external 
>>> modellers.
>>>
>>>
>>>
>>> 1 Naming a POV-Ray export of merged meshes
> 
> I would like to add to this request:
> 
>  From what I see, the output file names are generated from the input 
> file names as well, and therefore do depend on the oder in which meshes 
> are added to the merger.
> 
> 
> Another thing:
> 
> For me, it would often be desirable to export geometry only, and keep 
> the material export "unharmed", so I can change the pose of a figure 
> without having to re-do all the changes to the materials again. (I 
> prefer to edit them after export.)

I have received a couple of messages recently about the lack of control 
on the names for the POV scene. I will implement the names and flags for 
the exported POV files. I removed this from an earlier version because 
of clutter.

FlyerX

Post a reply to this message

FlyerX wrote:

>> Another thing:
>>
>> For me, it would often be desirable to export geometry only, and keep 
>> the material export "unharmed", so I can change the pose of a figure 
>> without having to re-do all the changes to the materials again. (I 
>> prefer to edit them after export.)
> 
> I have received a couple of messages recently about the lack of control 
> on the names for the POV scene. I will implement the names and flags for 
> the exported POV files. I removed this from an earlier version because 
> of clutter.
> 
> FlyerX

Hi FlyerX,
	Unrelated but could you make an option to remove the confirmation popup 
asking if you are sure that you really want to close when you ask 
PoseRay to exit?
It is a very small thing but I find it quite irritating :)


-- 

Best Regards,
	Stephen

Post a reply to this message

Stephen wrote:
> FlyerX wrote:
> 
>>> Another thing:
>>>
>>> For me, it would often be desirable to export geometry only, and keep 
>>> the material export "unharmed", so I can change the pose of a figure 
>>> without having to re-do all the changes to the materials again. (I 
>>> prefer to edit them after export.)
>>
>> I have received a couple of messages recently about the lack of 
>> control on the names for the POV scene. I will implement the names and 
>> flags for the exported POV files. I removed this from an earlier 
>> version because of clutter.
>>
>> FlyerX
> 
> Hi FlyerX,
>     Unrelated but could you make an option to remove the confirmation 
> popup asking if you are sure that you really want to close when you ask 
> PoseRay to exit?
> It is a very small thing but I find it quite irritating :)
> 
> 

I put that in because I lost many scenes by closing the program by 
mistake while thinking I was closing another window. Not a problem... I 
can put that optional.

FlyerX

Post a reply to this message

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.

Thomas

Post a reply to this message

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

"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

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