#34 Bolt crossed by a black line

open
nobody
Raytrace (49)
4
2006-01-12
2005-05-17
No

Look at http://ronja.twibright.com/3d/ and search fro
string "perpendcut".
Then display the first view if perpendcut. The ping
cutaway bolt is crossed over by a black line which
shouldn't be there. Corresponding .g file is on the
same page. Isn't this supposed to not be there?

Discussion

  • Sean Morrison

    Sean Morrison - 2005-05-18
    • status: open --> open-accepted
     
  • Sean Morrison

    Sean Morrison - 2005-05-18

    Logged In: YES
    user_id=785737

    While your link to perpendcut.g is a dead link, I was able to find
    "perpendcut" in your perpend.g file. If I use rt to view the geometry, it
    appears without a slice through the bolts. If I use rtedge, it does seem to
    slice the edge for some reason like your diagram shows. I'd normally
    question the boolean construction, but since rt and rtedge don't even
    agree, it seems to hint at something else going on. Thanks for the report!

     
  • Karel Kulhavy

    Karel Kulhavy - 2005-05-19

    Logged In: YES
    user_id=1194787

    Instead of "ping" should have been "pink".

    Thanks for the report of the deadlink. It was a missing -l
    option in the rsync script I am using to upload Ronja,
    therefore symlinks were not transferred. I have already fixed
    it.

     
  • Lee Butler

    Lee Butler - 2005-06-14
    • status: open-accepted --> open
     
  • Lee Butler

    Lee Butler - 2005-06-14

    Logged In: YES
    user_id=1179270

    Works for me. Have seen this behavior at times when dealing with floating
    point tolerance issues. What is typically happening is that a hit on
    foot1a.s ymax face is SLIGHTLY closer than the hit on cut1.s XMIN face.
    However, this should be handled by the Boolean of the hole and cut1.s.
    This is definitly something that needs closer scrutiny

     
  • Lee Butler

    Lee Butler - 2006-01-12
    • priority: 5 --> 4
     
  • John Anderson

    John Anderson - 2006-04-15

    Logged In: YES
    user_id=1185553

    I believe this bug is a result of the basic algorithm used
    by BRL-CAD ray-tracing. Briefly, the algorithm is:
    1. Intersect the ray with primitives to produce segments.
    2. Weave the segments into partitions.
    3. Determine which region each partition belongs to.

    In step 2, partitions are defined such that every unique hit
    distance (from the segment inhits and outhits) along the ray
    separates adjacent partitions. The partitions are assigned
    in hits and out hits (and normals) from the segments. I
    believe the problem is in this step when more than one
    segment has identical in or out hits. In this situation, an
    in (or out) hit for a partition must be selected from the
    segments that have identical hit distances, but there is no
    information on which to base the choice (step 2 does not use
    the region definitions). Since the hit distances are
    identical, any choice will produce the correct hit points,
    but the wrong choice could produce incorrect normals. I
    believe the wrong choice is being made in this case
    resulting in an incorrect surface normal and an undesired
    line. The line appears where the surface of the cutting
    solid intersects the surface of the "foot" solids. When a
    ray hits this line, several segments with identical hit
    points are created. This only happens in this case because a
    vertical scanline exactly coincides with that surface
    intersection. Running rt at 511x511, rather than the default
    512x512, produces the correct image (the scanlines are
    slightly moved).Note that the region definitions are not
    consulted until step #3

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks