 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello,
POV-Ray 3.6.1c.icl8.win32 running in WinXP SP2.
This scene has 4 mesh2 objects (box, ball, cylinder and bowl) and two
parallel lights. All meshes intersect but do not have coincident
surfaces. Y is up, X is to the right and Z is towards the camera aligned
with the box. The meshes are separate and all have their own material
and are hollow. All are placed inside an union statement. The only open
mesh is the one on the left.
The rendered image is shown below:
http://mysite.verizon.net/sfg0000/images/testscene_render.png
here is the PoseRay mesh and axis orientation preview before rendering:
http://mysite.verizon.net/sfg0000/images/testscene.jpg
Link to scene POV-Ray code:
http://mysite.verizon.net/sfg0000/files/testscene.zip
The problem: There is a significant shadow gap between the left mesh and
the box. I asked this question a while back and I was told to use
inside_vector in the mesh2 statements. That helped somewhat with other
cases but not with this. If I understand the inside_vector statement
correctly then vectors Z and X should work since a ray should intersect
the bowl mesh twice in those directions.
If I place split_union off at the end of the union then the gap
disappears but I lose control on the shadow flag for all objects in the
union. In other words no_shadow does not disable the shadow for any
object.
I could use a texture list on the mesh2 statement but that does not
allow me to use an interior in any of the meshes.
I also disabled the union and listed the objects separately but that did
not have an effect on the gap.
The gap shows with all other light types and can be somewhat covered
using large area_lights.
This gap only shows only if the meshes intersect.
Any insight will be appreciated. I know that open meshes in POV-Ray may
be problematic but I wanted to know if there was a way around this
particular issue. If you see anything wrong with the way I setup the
meshes please feel free to let me know.
regards,
FlyerX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
FlyerX <fly### [at] yahoo com> wrote:
> and are hollow.
I apologize for this non-answer, but it just never ceases to amuse me
how the magical 'hollow' keyword is always used as the panacea cure for
all problems.
I'm honestly curious: What do you think 'hollow' does, and regardless
of your answer to that, why did you think it would be of any help with
this problem?
(If anything, assuming a misinterpretation of what 'hollow' does,
one could assume that actually *using* it would cause the problem
instead of not using it. What you want is a "solid shadow", in which
case it would seem reasonable to want the object to be solid, not
"hollow". So I just can't figure out the logic of how using 'hollow'
could ever solve the shadow problem...
I'm always puzzled why people use the 'hollow' keyword as some kind
of magic spell to try to fix all types of problems which seem (and are)
completely unrelated to object solidness.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hollow being there is not related to this problem and I did not put it
there to help this problem. I placed it there by default for all objects
just in case the camera is inside a closed mesh room. If any atmospheric
media is present hollow makes sure the media is visible inside a closed
mesh. I coded PoseRay and that is the new default for all meshes. From
the POV-Ray manual:
"If you add the "hollow" keyword to the object, POV-Ray will no longer
handle it as solid, so fog and atmosphere will invade the inside of the
object. This is the reason why POV-Ray issues a warning when you put the
camera inside a non-hollow object (because, as it says, fog and other
atmospheric effects may not work as you expected). "
If hollow is not used (and I tested this) media is not visible inside a
closed mesh.
Also using hollow or not does not affect the shadow gap.
FlyerX
Warp wrote:
> FlyerX <fly### [at] yahoocom> wrote:
>> and are hollow.
>
> I apologize for this non-answer, but it just never ceases to amuse me
> how the magical 'hollow' keyword is always used as the panacea cure for
> all problems.
>
> I'm honestly curious: What do you think 'hollow' does, and regardless
> of your answer to that, why did you think it would be of any help with
> this problem?
>
> (If anything, assuming a misinterpretation of what 'hollow' does,
> one could assume that actually *using* it would cause the problem
> instead of not using it. What you want is a "solid shadow", in which
> case it would seem reasonable to want the object to be solid, not
> "hollow". So I just can't figure out the logic of how using 'hollow'
> could ever solve the shadow problem...
> I'm always puzzled why people use the 'hollow' keyword as some kind
> of magic spell to try to fix all types of problems which seem (and are)
> completely unrelated to object solidness.)
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The intersection seam of the surfaces is coincident.
It doesn't matter much if the surface of the box
behind the object surface is shaded, but in the
case of the bowl the surface of the box behind
the seam is lit.
You can make it look right by putting a bottom
on the bowl...
difference { // bowl
object{testscene__null__ }
plane {y,0.102}
uv_mapping material{_null__ }
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
My guess: limited floating point accuracy.
I've run into this problem quite frequently when using poser
figures - mostly with transmapped hair, but also with 'tight' clothes,
lashes or eyebrows. And especially by using figures with a high
poly count. Even if the Poser/PoseRay preview looked perfect.
The problem completely disappeared as soon as I started
to scale all my scenes in a way that 1 POV-unit equals 1 cm
(before I usually used 1 unit = 1 m) . It is not even necessary
to scale the object within PoseRay (but I'm sure this would also
work), it is enough to but e.g. 'scale 100' into the unioned mesh
objects (and adjust the camera and lights).
Your scene renders perfectly when upscaled:
//==================================================
#include "stdinc.inc"
#include "skies.inc"
#include "stars.inc"
#include "textures.inc"
#include "testscene_POV_geom.inc" //Geometry
global_settings {
//This setting is for alpha transparency to work properly.
//Increase by a small amount if transparent areas appear dark.
max_trace_level 15
}
//CAMERA PoseRayCAMERA
camera {
perspective
up <0,1,0>
right -x*image_width/image_height
location <-0.3466585,-0.1462403,3.818377>
look_at <-0.3466585,-0.1462403,2.818377>
angle 4.306029 // horizontal FOV angle
rotate <0,0,12.06625> //roll
rotate <-17.04571,0,0> //pitch
rotate <0,15.46715,0> //yaw
translate <0.425,0.5,0.425>
scale 100 // !!!
}
//Light_1
light_source {
<0.425,1.85,1.775> //light position
color rgb <1,1,1>*0.8
parallel
point_at <0.425,0.5,0.425>
scale 100 // !!!
}
//Light_2
light_source {
<0.425,2.40918830920368,0.425> //light position
color rgb <1,1,1>*0.8
parallel
point_at <0.425,0.5,0.425>
scale 100 // !!!
}
//Background
background { color rgb<0,0,0> }
//Assembled object that is contained in testscene_POV_geom.inc
object{
testscene_
scale 100 // !!!
}
//==================================================
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ive,
Thank you very much for the tip. Scaling seems to indeed fix the
problem. It certainly looks like a floating point limitation.
I would have never guessed that POV-Ray did not rescale the whole scene
internally to maximize accuracy. I was familiar with the problems with
several distant objects in the same scene but not for the coordinates
being too small. I will add scaling to the scene in PoseRay for the
upcoming version.
I just wonder what would be a good scale range. The scene shadows start
to fail with a scale in the order O(0.1). Scaling to O(10) eliminates
the shadow gaps. Maybe scaling the whole scene to O(100) or more should
be a safe approach. This shadow gap problem seems to be more restrictive
than the 64 bit floating point for the scene coordinates. POV-Ray
renders the geometry perfectly in the original file. It is the shadows
that start degrading at small scales.
thanks again,
FlyerX
Ive wrote:
> My guess: limited floating point accuracy.
>
> I've run into this problem quite frequently when using poser
> figures - mostly with transmapped hair, but also with 'tight' clothes,
> lashes or eyebrows. And especially by using figures with a high
> poly count. Even if the Poser/PoseRay preview looked perfect.
> The problem completely disappeared as soon as I started
> to scale all my scenes in a way that 1 POV-unit equals 1 cm
> (before I usually used 1 unit = 1 m) . It is not even necessary
> to scale the object within PoseRay (but I'm sure this would also
> work), it is enough to but e.g. 'scale 100' into the unioned mesh
> objects (and adjust the camera and lights).
>
> Your scene renders perfectly when upscaled:
>
> //==================================================
>
> #include "stdinc.inc"
> #include "skies.inc"
> #include "stars.inc"
> #include "textures.inc"
> #include "testscene_POV_geom.inc" //Geometry
>
> global_settings {
> //This setting is for alpha transparency to work properly.
> //Increase by a small amount if transparent areas appear dark.
> max_trace_level 15
>
> }
>
> //CAMERA PoseRayCAMERA
> camera {
> perspective
> up <0,1,0>
> right -x*image_width/image_height
> location <-0.3466585,-0.1462403,3.818377>
> look_at <-0.3466585,-0.1462403,2.818377>
> angle 4.306029 // horizontal FOV angle
> rotate <0,0,12.06625> //roll
> rotate <-17.04571,0,0> //pitch
> rotate <0,15.46715,0> //yaw
> translate <0.425,0.5,0.425>
> scale 100 // !!!
> }
>
> //Light_1
> light_source {
> <0.425,1.85,1.775> //light position
> color rgb <1,1,1>*0.8
> parallel
> point_at <0.425,0.5,0.425>
> scale 100 // !!!
> }
>
> //Light_2
> light_source {
> <0.425,2.40918830920368,0.425> //light position
> color rgb <1,1,1>*0.8
> parallel
> point_at <0.425,0.5,0.425>
> scale 100 // !!!
> }
>
> //Background
> background { color rgb<0,0,0> }
>
> //Assembled object that is contained in testscene_POV_geom.inc
> object{
> testscene_
> scale 100 // !!!
> }
> //==================================================
>
> -Ive
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
FlyerX,
> I will add scaling to the scene in PoseRay for the upcoming version.
>
I'm not sure if it is a good idea to add this as a feature to PoseRay.
It does very much depend on the kind of scene/object used. Maybe
a hint in the tips/tricks/faq section is enough. Ok, just speaking for
myself and I'm quite happy with the way it currently works.
> POV-Ray renders the geometry perfectly in the original file. It is the shadows
> that start degrading at small scales.
>
well, it is quite a while since I looked into the POV-sources, but IIRC POV
adds a build in constant value (epsilon?) when it shoots a shadow test ray to
avoid problems with self shadowing. Again IIRC there was quite some time
ago a discussion if this value was choosen a bit large - but maybe I'm just
confusing things and anybody with better knowledge of the source may
correct me.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> well, it is quite a while since I looked into the POV-sources, but IIRC
> POV
> adds a build in constant value (epsilon?) when it shoots a shadow test
> ray to
> avoid problems with self shadowing.
Yeah, I think that's what this is. One thing I've been wondering lately is
if it's possible to avoid doing this for objects besides the one the ray is
coming from. So if you hit a sphere, and there's a nearby box, you do
shadow/reflection traces *without* an epsilon, from the exact intersection
point on the sphere. If the trace hits the box, you assume the intersection
is valid. If the trace hits the sphere, you say "hey, this is the same
object we're coming from," and only then do you check the epsilon and
discard the intersection if it's too close.
You could also require that the normal of the intersection is similar to the
normal of the original intersection; this would avoid throwing away
intersections at an "inner corner."
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
