Attached is a minimal scene that demonstrates the artifact. Essentially 
where CSG ojects join, there are seams. At first I thought this was due 
to union, but this occurs even with merge.
-- 
~Mike

Post a reply to this message

Attachments:
Download 'us-ascii' (2 KB)

Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> Attached is a minimal scene that demonstrates the artifact. Essentially
> where CSG ojects join, there are seams. At first I thought this was due
> to union, but this occurs even with merge.

I already expected that (didn't yet bother to try myself), though I was hoping
"merge" would make a difference.

This is a basic problem of the algorithm that needs to be sorted out in the POV
environment: To compute the surface color of a certain object at a certain
location, it needs to find nearby points on the surface of the very same
object.

Define "same object" in a CSG setting... tricky.

I think it is prudent to presume that if an object is part of a merge, then the
whole merge should be considered as "the object"; similarly with intersections
and differences; but in a union, each object should go on its own, as far as
SSLT is concerned.

(Even that will not yield realistic results with a union, as in reality light
would be transported from one object to the other at the interface; however, a
radiosity-aware SSLT in combination with a smarter coincident surface handling
might be able to do the trick.)

Post a reply to this message

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

Le_Forgeron <jgr### [at] freefr> wrote:
> Smarter coincident surface handling... speak of the holy graal!

Would the suggestion at the following link work?
http://news.povray.org/web.49e12af5149f0cf9addfbead0%40news.povray.org

(please post any comment there, to keep this thread on-topic)

Post a reply to this message

"MessyBlob" <nomail@nomail> wrote:
> Le_Forgeron <jgr### [at] freefr> wrote:
> > Smarter coincident surface handling... speak of the holy graal!
>
> Would the suggestion at the following link work?
> http://news.povray.org/web.49e12af5149f0cf9addfbead0%40news.povray.org
>
> (please post any comment there, to keep this thread on-topic)

No, the thing I plan to implement is only geared at objects more or less
perfectly "touching" each other, i.e. cases where a ray leaves one object to
enter another one. Simply speaking, the idea is to handle "currently inside"
objects different from "currently outside" objects.

Cases where multiple intersecting objects would be competing for the "next
object" would be beyond the scope of that implementation.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> A clear benefit for your coding and our brains, but that is not how CSG is going to
be
> used nowadays and in the futur.

If, as you concede, it is indeed a clear benefit not only for my coding but also
for your brains, then there's not much more argument to be made about it.

An easy-to-grasp concept reduces the instances of "duh, why does it behave
*this* way?"

And an easy-to-code concept reduces the instances of both "duh, when will SSLT
support CSG at last?" and later "duh, when will SSLT be fixed to work with this
special CSG case as well?"


Your intention may be to devise a sophisticated rule-set for interaction between
SSLT and CSG that will catch all possible current and future uses of CSG to
allow for using SSLT materials in each and every case, and achieve exactly the
desired effect both regarding the CSG and the SSLT.

My intention is to devise a basic rule-set for interaction between SSLT and CSG
to easily and consistently allow for CSG-modelling of SSLT-enabled objects.

Because my intention is to implement such support in due time and due quality,
so that people toying around with SSLT are no longer restricted to primitives,
blobs and meshes.

SSLT will remain experimental, and so will the integration into the CSG
framework. More sophisiticated rules may well follow later, once SSLT as a
whole closes in on maturity. I don't really expect this to happen too soon.


> As a final note, I would be happy if the SSLT CSG-handling was able to deal natively
with
> my personal extension of csg: intermerge & interunion (parametrized n-ary operations
of
> +/- based on number of components matched, very useful to make stellated polyhedrons
but
> also thinks like gears without multiplying the number of basic objects, see them in
French
> at http://jgrimbert.free.fr/pov/patch/inter.html )

I don't really have much of an idea what you're talking about, but I'd be
interested to hear about this concept. Though, currently, definitely not in the
context of SSLT: There's still too many other open issues to work on.

Post a reply to this message

One more thing...

Le_Forgeron <jgr### [at] freefr> wrote:
> Do not restrict innovations to existing concepts, think them globally!
> Special cases are bad.

I'm definitely not one to normally restrict innovation, and rather think two
steps ahead into the future and flexibility than just one.

It is a given fact that currently there *IS* a restriction to an existing
concept regarding SSLT, which is:

    SSLT and CSG don't mix.

Please note that I am not placing *additional* restrictions, but pushing
*existing* ones a good deal further.

In my spare time.

In task packages that I deem feasible to handle without becoming frustrated
about it.

If you're not happy with it, you're welcome to join the effort. I must confess
that I currently do consider SSLT to be "my baby", but I'd gladly share the
workload of raising it to maturity.

I will not, however, take from anyone that I'd be "restricting innovations" when
as a matter of fact I'm busy *adding* to POV's features.


Maybe I took the tone of your posting wrong, but this is how I received it.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> I'm ok with your baby, it might just be that the main branch/beta of expected
release is
> not the best place for experiments. (Oh, I'm not any pov-team/rulers, just a user
here,
> with its load of expectation (currently, get the definitive 3.7 out as soon as
possible
> now, so we can play with it all!)).

There is some point to this. However, there are also two "buts" to it:

"But" #1 - a very general one - is that currently, the "beta proper" seems to be
the only reasonable testbed available for new features; It does not make sense
*now* to develop new features based on 3.6 code. Yet it is legally not possible
to distribute 3.7 derivatives yet.

"But" #2 - an SSLT specific one - is that (a) SSLT is actually not totally new
to POV; in fact it started out as an approach of porting an old 3.6 patch to
the 3.7 framework (the famous "Sarah Tariq / Lorenzo Ibarria patch"); and (b)
it's not like I kind of "hijacked" POV 3.7 beta for the SSLT development - nor
that main 3.7 beta development is suffering from it. To the contrary: The work
was actually started by the POV dev team, until they kind of "outsourced" the
job to me.

I think that the main motivation behind it was that with 4 years focused on SMP
development, there was a feeling that POV-Ray needs to move forward in other
fields as well.

I do agree with you that 4 years of beta development should be about enough, and
that development should move ahead to get POV-Ray 3.7 to a first official
release. I also agree that it would be good to have POV-Ray regain "market
share" in the benchmarking area. But think again: Who would want to do
benchmarking with an SMP-enabled version of POV-Ray if it was obsoleted by
technical innovation in other fields of 3D rendering, with no sign of catching
up?

I also do not think that SSLT development progress will in *any* way affect 3.7
release planning (except maybe triggering one or two additional in-between beta
releases): I expect 3.7.0 proper to be released as soon as everything else is
ripe for it, but regardless of SSLT status. At best, I expect SSLT to be an
experimental feature of 3.7.0 proper - at worst, it may still be considered too
unstable, and "cut out" of the release proper.


> The 3.7 is a major recoding, thus it is difficult to fork for experimentation
already
> until it goes out without issues on basic functionality (iso-level to the 3.6 at
least, no
> more bugs, which seems nearly done, at least from my point of view now)
> (source code was not available before beta 25, and the rewrite introduced a number
of
> issues (performance & bugs) which needed to be fixed before diving into fancy
innovations)

It seems to me that performance issues are mostly sorted out now, too, Radiosity
having been the last major drawack in that area. The respective fixes haven't
been beta-released yet, but they are ready for roll-out of beta 33.

From my seat, Beta 33 will be outperforming 3.6 on average. Individual scenes
may experience a significant shift that may require modifications to their
quality settings to render at same speed and quality, but I consider this
acceptable considering the conceptual bugs and flaws in 3.6 radiosity (and
after all, radiosity was still officially experimental in 3.6).


> You stated that you are usually two steps ahead in the future. But I'm the opposite
kind
> of guy: I prefer to have a whole planned framework before starting something.
>
> Planning means anticipating difficulty and looking at theoretical solutions before
the
> issue is encountered.

That's exactly what I meant when I said I'm usually two steps ahead in the
future. I didn't mean that I'm actually there already, but that I'm planning
for the time when I'll be there.

I can't stand just fixing a broken thing. I want to find a way that makes sure
it doesn't break again. And, as I'm already on it, a generic way tho apply to
similar things, making sure they never break in the first place.


> The problem with "adding POV's features" without looking at the whole picture first
is one
> of the most problematic aspect of SDL: backward compatibility.

The way I deal with this issue is by wrecking my brain about POV 4 SDL. I guess
my postings in the POV 4 newsgroup should be indicative that I'm not at all
oblivious to this problem.

Or by pointing out in big red letters that a certain SDL construct is totally
preliminary, like SSLT parameters being placed in the finish statement.


> I would gladly drop ALL backward compatibility, but so far that's not how povray
deals
> with its history. (probably with rights, as it's often convenient to be able to
render old
> scenes...).

There are instances of POV-Ray dropping old syntactic constructs. It retains
obsolete stuff only as long as it doesn't actually get in the way.


> So, I hope you can understand my concern about SSLT pushing merge/union for
> now. I'm anticipating, maybe wrongly, a future issue in SDL (and I do not like
that).

Dealing with CSG is only a minor sidetrack of the whole SSLT picture. From the
algorithm's point of view, it will always be "find an intersection with this
very same object" - whether "this very same object" will be the same primitive
(as it is now), or the parent merge (as I plan to make it), or a much more
sophisticated thing, is just a matter of definition and hacking up an
appropriate function to actually implement this decision. The SSLT algorithm
itself doesn't care. It's just some more "glue code" to interface it with the
rest of the POV engine.

I'm not the one to hard-code such things monolithically into generic algorithms.
The SSLT code is perfectly safe for any futute extensions (or even
modifications) to the way scene geometry is defined - provided they allow for
*some* way to structure it into "pieces of material".

Note that in this respect, your definition "same material = same piece,
different material = different piece" is actually a stronger limitation than
"merge = same piece, union = different pieces".

Consider, for instance, a statue originally chiselled out of the very same piece
of marble, but later cut into pieces for easier transport, and re-assembled at
its destination. In such a case, to model this properly, all the pieces would
have to be considered individual pieces. Using the rule "same material = same
piece" would *not* allow this with any CSG construct you could ever imagine.
While the rule "merge = same piece, union = different piece" would allow the
user to control the result by his choice of CSG method.

Granted, this may require more cumbersome constructs for some instances of
"uncut" geometry, so it may impose some hurdles. But those are actually not
limitations: They can be jumped over, or walked around, with a bit more effort.
Your approach, on the other hand, clears the immediate surroundings of all the
hurdles - but at the cost of setting an absolute limit somewhere in the
distance.

So, short-sighted thinking on my part? I guess not.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> But I have also seen that so far SSLT works only with normal light... maybe solving
that
> for all light sources (why is there such dependency is a bit puzzling until I have a
look
> at the code... one day). The light issue is far more concerning than the CSG.

Don't bother looking at the code - you won't find anything that isn't known yet,
and probably not much that isn't due to change. Most has actually even been
mentioned in the newsgroups.

The beta release notes do mention that "SSLT is still in alpha stage". Which
means that yes, the developers know it's still lacking features, and yes,
they're working on it. Full integration with POV's classic lighting model -
including spotlights, area lights and other some such - is one such feature.


> Light first... I guess.

Exactly.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> the "same material=same piece" approach was a first though. Which proved to be bad.
> (and it was only "same SSLT=same piece", not big as same material)
> My latest idea (a post or two up) is to have an explicit ID for the SSLT part. Thus,
if

You know what? My penultimate dream for CSG is a generic thing like this (using
a fairly "fantasy" syntax here:

csg {
  component A { MyObj1 }
  component B { MyObj2 }
  component C { MyObj3 }
  ...
  interior {
    case inside A and B and C -> interior { ... }
    case inside A and B       -> interior { ... }
    case inside A and C       -> interior { ... }
    case inside A             -> interior { ... }
    case inside B and C       -> interior { ... }
    case else                 -> interior { ... }
  }
  texture {
    case A->B inside C -> texture { ... }
    case B->A inside C -> texture { ... }
    case A->B          -> texture { ... }
    case B->A          -> texture { ... }
    case A->C inside B -> texture { ... }
    case B->outside    -> texture { ... }
    case outside->B    -> hide
    ...
  }
}

This will be a hell of a monster to code for complex cases, but it'll make the
most versatile CSG you can ever dream of, encompassing all the functionality of
union, merge, difference, intersection, and even your own specialized flavors of
csg.

In that respect, SSLT would be just an additional parameter to the interior
(yes, not the finish; it'll move out of there anyway), and "the same piece of
material" would simply be "anywhere I can go without hitting a non-hidden
surface". (Or, if even more versatility should ever be required, a special
"hide_for_sslt" parameter could be added to the finish.)

Post a reply to this message