I'm having an issue which I'm hoping someone can give me some insight into.

I created a mesh (original non 'mesh2' object) macro to create a spherical
segment based on parameters specified (ie theta angle, sigma angle, radius of
inner shell, radius of outer shell).

View an image of a sample at
<http://news.povray.org/web.50f3576db4e014d682dd1ac40%40news.povray.org>.

In a nutshell its created by first cunstruction of a tiny closed mesh object
(thereby enabling use of the 'inside_vector' modifier), comprised of 6 sides and
12 'triangle' objects, and  with UV parameters supplied by the calling macro.
The calling macro creates a union of the smaller mesh objects based on a set
number of divisions in the theta and sigma (angles), and radius directions.

My problem is that no matter how I apply the use of the 'uv_mapping' and the
'texture' statements, POV always applies the 'texture' first then applies the
'inside_vector'. The problem with this is when working with transparent
'image_map' objects (such as the icon image in the upper right quadrant of the
image) yields unintended results  such as those in the corners of the
mapped image (upper left quadrant).

I've tried changing the order such that the texture is applied both to the
'mesh' objects individually, and to the 'union' of the individual meshes, but
with the same result. I would think that since the 'inside_vector' is applied to
the individual mesh objects, if the texture is applied to the 'union' object
this would do the trick, but this does not appear to be the case

Since the documentation says it was designed for CSG, I've tried encasing the
mesh in other "normal" objects (such as a 'sphere' or 'box') hoping this would
resolve the issue. The 'inside_vector' does appear to be working correctly as
indicated by the two bottom pictures (left with the 'inside_vector' parameter
added to an intersected object, right without the 'inside_vector'  parameter
added).

It seems to be an issue in determining what is the surface that needs to have
the 'inside_vector'. Ideally, POV would calculate the surface first (thereby
making it solid), then apply the texture with the transparency. But as
indicated, it seems to be applying the texture incororating the transparency
first, thereby making parts of the mesh faces transparent, and then applying the
'inside_vector' (and making the result solid) secondly.

Anybody have any recommendations for a fix?

I know this is in unitended consequence (at least for me), but is this a bug in
general? Or just some limitation?

Is it something that can be corrected in future versions of POVray so as not to
require a fix? That is can POV be programmed so the user can change the order in
which the 'inside_vector' and transparent 'image_map' are applied?

-Jeff

Post a reply to this message

Hi Woody,

I think it would be more helpful to have some code to inspect. In fact I did not
understand the description of your problem. Looking at the picture you gave, I
would judge it more as a problem with the geometry and not with the texture
(especially the right bottom part). I have no experience with mesh objects (only
have used mesh2 so far myself). With mesh2 and an inside vector (it seems to be
more important to have one defined than to have the best direction) one can cut
down a mesh2 object with usual csg-operations in parts, texture them
individually and put them together again - or leave them apart. Some months ago
I posted a picture to the p.b.i with a mesh2 object handled in this way
exactelly:

http://news.povray.org/povray.binaries.images/message/%3Cweb.50329242de95511561a6f3b40%40news.povray.org%3E/#%3Cweb.503
29242de95511561a6f3b40%40news.povray.org%3E

The body of the magpie is this mesh2 object.  But to understand your special
problem I think it would be helpful to look at some sample code.

Best regards,
Michael

Post a reply to this message

>
> Hi Woody,
>
> I think it would be more helpful to have some code to inspect. In fact I did not
> understand the description of your problem. Looking at the picture you gave, I
> would judge it more as a problem with the geometry and not with the texture
> (especially the right bottom part). I have no experience with mesh objects (only
> have used mesh2 so far myself). With mesh2 and an inside vector (it seems to be
> more important to have one defined than to have the best direction) one can cut
> down a mesh2 object with usual csg-operations in parts, texture them
> individually and put them together again - or leave them apart. Some months ago
> I posted a picture to the p.b.i with a mesh2 object handled in this way
> exactelly:
>
>
http://news.povray.org/povray.binaries.images/message/%3Cweb.50329242de95511561a6f3b40%40news.povray.org%3E/#%3Cweb.503
> 29242de95511561a6f3b40%40news.povray.org%3E
>
> The body of the magpie is this mesh2 object.  But to understand your special
> problem I think it would be helpful to look at some sample code.
>
> Best regards,
> Michael
>
>

The difference between a regular mesh and a mesh2 object in only in the 
way it's defined. Otherwise, everything that apply to one also apply to 
the other, as, internaly, they are exactly the same thing.
The only requirement for the inside_vector of a closed mesh is that it 
should not be parallel to a triangle of the mesh.

The problem is that the object is composed from an array of small mesh 
objects to whitch an image_map is applyed using UV mapping. That 
image_map have some transparent parts that let us see the inside. It's 
very similar to a clipped_by case. The bits you see are the inside of 
some of the constituent component meshes.


Alain

Post a reply to this message