Le_Forgeron <jgr### [at] freefr> wrote:
> I would rather assume that if both part of a CSG operation do share the same SSLT
setting,
> they should be considered as "a single object".
>
> For instance, it is possible to merge a semi-transparent object with an opaque one.
> Merge would simply remove all internal surfaces. (or a blue sphere on a red
cylinder:
> there would be a separation mark; with a green sphere on a green cylinder,
everything is
> just green...)

This is not as easy as it seems at first glance: *Because* merge removes all
internal surfaces, the SSLT code will not be able to find the boundary between
the two parts of the thing.

And the merge may be done just to apply a different finish to two parts of an
object


> Union is usually a manipulation short-cut, to handle a tree of distinct objects. But
for
> opaque objects, it is often preferred to merge.

For SSLT objects, merge should be used at any rate. That's quite a plain thing.


> May be the sslt code should navigate in the CSG tree a bit ?
> (a bit is tricky... just like transformation and other... it's usually a depth
exploration
> which might be needed with CSG)

I don't really think this is feasible. After all, the SSLT code needs to compute
about 100 intersections per pixel. A clear rule like "merge & intersection =
same object, union = different objects" would really be of benefit there.


> Smarter coincident surface handling... speak of the holy graal!

I did poste some idea a while ago. Didn't yet find the time to implement it
though.

Post a reply to this message