Thread: [brlcad-tracker] [ brlcad-Bugs-1802329 ] Mixing smooth and flat overlapping BoTs gives bad results
Open Source Solid Modeling CAD
Brought to you by:
brlcad
From: SourceForge.net <no...@so...> - 2007-09-25 22:55:56
|
Bugs item #1802329, was opened at 2007-09-25 22:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=640802&aid=1802329&group_id=105292 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Raytrace Group: other bug / workaround Status: Open Resolution: None Priority: 4 Private: No Submitted By: Sean Morrison (brlcad) Assigned to: Nobody/Anonymous (nobody) Summary: Mixing smooth and flat overlapping BoTs gives bad results Initial Comment: Ran into a curious case where if you have two geometricly identical overlapping bots where one is smooth and one is not, the raytrace will be wrong. Most disturbing is that the bug even occurs if the overlap is from a negative space object (e.g. BoT used in a subtraction). The problem can be seen with a simple sphere and a box used to cut the bottom half of the sphere off. Turn the sphere into an BoT, create a region for the bottom half that intersects the box with a usual unsmoothed BoT sphere, and create a region for the top half that subtracts the box from the *smoothed* BoT sphere. The result should be a unsmooth BoT base to the sphere and a smoothed top portion. The result is an interleaved smooth/unsmoothing throughout. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=640802&aid=1802329&group_id=105292 |
From: SourceForge.net <no...@so...> - 2007-09-25 23:03:43
|
Bugs item #1802329, was opened at 2007-09-25 22:56 Message generated for change (Comment added) made by brlcad You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=640802&aid=1802329&group_id=105292 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Raytrace Group: other bug / workaround Status: Open Resolution: None Priority: 4 Private: No Submitted By: Sean Morrison (brlcad) Assigned to: Nobody/Anonymous (nobody) Summary: Mixing smooth and flat overlapping BoTs gives bad results Initial Comment: Ran into a curious case where if you have two geometricly identical overlapping bots where one is smooth and one is not, the raytrace will be wrong. Most disturbing is that the bug even occurs if the overlap is from a negative space object (e.g. BoT used in a subtraction). The problem can be seen with a simple sphere and a box used to cut the bottom half of the sphere off. Turn the sphere into an BoT, create a region for the bottom half that intersects the box with a usual unsmoothed BoT sphere, and create a region for the top half that subtracts the box from the *smoothed* BoT sphere. The result should be a unsmooth BoT base to the sphere and a smoothed top portion. The result is an interleaved smooth/unsmoothing throughout. ---------------------------------------------------------------------- >Comment By: Sean Morrison (brlcad) Date: 2007-09-25 23:03 Message: Logged In: YES user_id=785737 Originator: YES File Added: botbug.jpg ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=640802&aid=1802329&group_id=105292 |
From: SourceForge.net <no...@so...> - 2007-09-27 00:39:03
|
Bugs item #1802329, was opened at 2007-09-25 18:56 Message generated for change (Comment added) made by johnranderson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=640802&aid=1802329&group_id=105292 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Raytrace Group: other bug / workaround Status: Open Resolution: None Priority: 4 Private: No Submitted By: Sean Morrison (brlcad) Assigned to: Nobody/Anonymous (nobody) Summary: Mixing smooth and flat overlapping BoTs gives bad results Initial Comment: Ran into a curious case where if you have two geometricly identical overlapping bots where one is smooth and one is not, the raytrace will be wrong. Most disturbing is that the bug even occurs if the overlap is from a negative space object (e.g. BoT used in a subtraction). The problem can be seen with a simple sphere and a box used to cut the bottom half of the sphere off. Turn the sphere into an BoT, create a region for the bottom half that intersects the box with a usual unsmoothed BoT sphere, and create a region for the top half that subtracts the box from the *smoothed* BoT sphere. The result should be a unsmooth BoT base to the sphere and a smoothed top portion. The result is an interleaved smooth/unsmoothing throughout. ---------------------------------------------------------------------- >Comment By: John Anderson (johnranderson) Date: 2007-09-26 20:39 Message: Logged In: YES user_id=1185553 Originator: NO This is another effect of the way that rt_boolweave operates. The problem is that rt_boolweave weaves the segments from the intersected primitives together, without knowledge of the Boolean operations that will be applied. In this case, two BOT primitives are intersected resulting in identical start and end points for their segments. These two identical segments are passed to rt_boolweave and it chooses one segment (whichever one it got first), to represent that segment. This segment is passed to rt_boolfinal which does the Boolean evaluation. It knows that the one segment represents both BOT primitives, and correctly performs the Boolean evaluation resulting in a Partition with the correct start and end points. The application (in this case rt) then calls RT_HIT_NORMAL to get the surface normal. RT_HIT_NORMAL calculates the surface normal based on which primitive generated the segment. Unfortunately, in this case, it may be the wrong primitive, resulting in an incorrect normal. This is the same problem that produced bug #1203344. ---------------------------------------------------------------------- Comment By: Sean Morrison (brlcad) Date: 2007-09-25 19:03 Message: Logged In: YES user_id=785737 Originator: YES File Added: botbug.jpg ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=640802&aid=1802329&group_id=105292 |