![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
It seems that in Megapov, the mesh2 statement doesn't recognize
material{}, only texture{}, which is not consistent with usual mesh
behaviour. Not a big problem with ior, as it still works in the finish
statement (with a warning), but of course it can be a problem with
media. I was wondering if this was fixed in Pov 3.5 ?
G.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Gilles Tran wrote:
>
> It seems that in Megapov, the mesh2 statement doesn't recognize
> material{}, only texture{}, which is not consistent with usual mesh
> behaviour. Not a big problem with ior, as it still works in the finish
> statement (with a warning), but of course it can be a problem with
> media. I was wondering if this was fixed in Pov 3.5 ?
> G.
But it is legal, mesh describes one object with one interior, specify
another interior (the second part of material than texture) with some
faces is useless.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Gilles Tran wrote:
> It seems that in Megapov, the mesh2 statement doesn't recognize
> material{}, only texture{}, which is not consistent with usual mesh
> behaviour. Not a big problem with ior, as it still works in the finish
> statement (with a warning), but of course it can be a problem with
> media. I was wondering if this was fixed in Pov 3.5 ?
> G.
I looked at the source, and it doesn't seem to do anything
unusual...does it work if the material statement is the last thing in
the mesh other than transforms?
Or are you talking about a material per triangle? If so, are you sure
that works with the ordinary mesh?
In article <3A4139AD.B2A8A0D5@hlavacek-partner.cz>, Disnel
<dis### [at] hlavacek-partner cz> wrote:
> But it is legal, mesh describes one object with one interior, specify
> another interior (the second part of material than texture) with some
> faces is useless.
What?
Were you saying that it doesn't make sense to let each triangle in a
mesh have it's own interior statement, because they are parts of a
single object?
Hmm, this could be seen both ways:
1: If it lets you specify a texture for a specific portion of the
surface, it should let you specify a whole material for that portion.
2: Individual triangles are parts of one object with one interior, so
materials don't make sense for individual triangles.
It probably could be "fixed", but it wouldn't be very useful, and would
increase the amount of memory used.
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
What?
> Were you saying that it doesn't make sense to let each triangle in a
> mesh have it's own interior statement, because they are parts of a
> single object?
> Hmm, this could be seen both ways:
> 1: If it lets you specify a texture for a specific portion of the
> surface, it should let you specify a whole material for that portion.
If we have blinn highlitgs, then I need to specify different interiors
for different faces ...
> 2: Individual triangles are parts of one object with one interior, so
> materials don't make sense for individual triangles.
... but individual triangles ARE parts of one object and we don't have
variable ior in POV-Ray (and if we have, then it should be specified in
another way than different iors for all faces, because it is propetry of
interior of solid and not its surface), so its useless to specify
different interiors for different faces. In this case, ior for blinn
highlights should be a finish property instead of interior property.
>
> It probably could be "fixed", but it wouldn't be very useful, and would
> increase the amount of memory used.
>
> --
> Christopher James Huff
> Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
> TAG: chr### [at] tag povray org, http://tag.povray.org/
>
> <><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Huff wrote:
> I looked at the source, and it doesn't seem to do anything
> unusual...does it work if the material statement is the last thing in
> the mesh other than transforms?
> Or are you talking about a material per triangle? If so, are you sure
> that works with the ordinary mesh?
In mesh2, the textures are listed within the mesh definition :
texture_list {
2,
texture { T_1}
texture { T_2}
}
It doesn't accept material{} instead of texture{}.
In a regular mesh statement, you can use material{} and it does work
properly (media makes nice ghostly Poser figures).
In fact, I came upon this while trying to uv-map a bottle mesh, as I needed
an ior. For the time being, the workaround is to put the ior in the finish
statement.
However the problem is more complex than I thought, because uv-mapping media
or ior doesn't make sense. I still have to test what happens in a
multi-textured mesh2 with several ior values...
G.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3A41CEFA.D396F67E@inapg.inra.fr>, Gilles Tran
<tra### [at] inapg inra fr> wrote:
> It doesn't accept material{} instead of texture{}.
> In a regular mesh statement, you can use material{} and it does work
> properly (media makes nice ghostly Poser figures).
But (from looking at the source) it seems that it will take a material
or interior with no problems when it is texturing the whole mesh, not as
part of the texture list or individual triangles. This was what I was
talking about...
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> But (from looking at the source) it seems that it will take a material
> or interior with no problems when it is texturing the whole mesh, not as
> part of the texture list or individual triangles. This was what I was
> talking about...
Yes it should, as for normal mesh.
Now, when a triangle carries its own texture/material definition, it
supersedes the one you specify for the whole mesh. Hence, if every triangles
of the mesh have their own textures, the global mesh texture is not exactly
useful. I found only one case when it's necessary: when each triangle has
its own texture which is partly transparent; the mesh will cast correct
shadows only if you add a transparent global texture to it.
In other words: the mesh global texture is not promoted to the
individual triangles. I suppose that the interior{}, finish{} and material{}
stuffs might behave the same, but I'm not sure.
*** Nicolas Calimet
*** http://pov4grasp.free.fr
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Huff wrote:
> But (from looking at the source) it seems that it will take a material
> or interior with no problems when it is texturing the whole mesh, not as
> part of the texture list or individual triangles. This was what I was
> talking about...
OK, I didn't get it because usually it doesn't make sense adding an overall
texture statement to a mesh2 object that already contains its own texture
list.
After further testing, and reading what Nicolas and you say, it's working :
adding the interior statement at the end of the mesh definition works like
it should.
mesh2{...12Mb of vertices... texture_list{...}... interior{...}}
In fact it's quite logical, but a heavy mesh2 user like me was confused by
the fact that the mesh2 syntax is rather strict when it comes to textures.
Nothing to "fix" then, though something about this could be added in the 3.5
documentation about mesh2.
Thanks
G.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3A4325E1.CF03007C@inapg.inra.fr>, Gilles Tran
<tra### [at] inapg inra fr> wrote:
> In fact it's quite logical, but a heavy mesh2 user like me was
> confused by the fact that the mesh2 syntax is rather strict when it
> comes to textures.
Well, some more information: the "interior" statements fill the interior
of an object, and generally don't work properly with objects that aren't
closed(because of clipping or meshes that have "holes"). If individual
triangles in a mesh had their own interior, and assuming a simple mesh
like a sphere, with at most two intersections, it would hit a triangle
on the front then continue to one on the back, and the interior would be
everything on the line segment between the two intersection points.
Which interior would it use? The front one? The back one? Something
halfway in between? The average result of computing both interiors? How
would it handle ior differences? Etc...
It probably wouldn't be a difficult feature to code, it just needs to be
defined better.
> Nothing to "fix" then, though something about this could be added in
> the 3.5 documentation about mesh2.
Probably a good idea...
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Huff <chr### [at] mac com> wrote:
: It probably wouldn't be a difficult feature to code, it just needs to be
: defined better.
Why it should be coded when it makes no sense in the first place?
A triangle has no interior. Why one should be able to specify interior
properties for it?
A bunch of triangles defining a closed surface can have an interior without
problem.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |