"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

Le_Forgeron <jgr### [at] freefr> wrote:
> What if SSLT, if it does not fit finish, was an additional (or two ? does SSLT have
a
> meaning to have a different "value" from outside/inside ?) piece of data ?

Again you're not following discussions in these newsgroups.

I already mentioned that I do think it is most suited to be considered an
"interior" attribute.

Its key parameters - aside from index of refraction - are the "(reduced)
scattering coefficient" and "absorption coefficient", both representing the
probability per unit of distance (in this case normalized to per-mm) that a
photon is scattered or absorbed, respectively, as it travels through the
material.

Note that these parameters are basically equivalent to absorbing / scattering
media density (except that media gives proper results only for low-scattering
substances, whereas SSLT is designed for highly-scattering materials).

Surface events are involved as well, but they play only a secondary role; the
main coefficients, at least, do not describe properties of an interface between
materials, but of one material only.


There might be reason to consider it a pigment property, as in real life the
events involved in subsurface scattering *cause* the pigment color, and the
SSLT mechanism supersedes the classic pigment&diffuse thing. But in my opinion,
this only shows that pigment is at the wrong place, at least from a theoretical
point of view.

An additional point is that pigment might still represent an additional surface
coating, which is too opaque to be worth modelling with an added layer of
SSLT-enabled material.


From your musings, I must assume you have no idea what SSLT actually does. I
recommend reading the original 2001 Siggraph paper "A Practical Model for
Subsurface Light Transport" by Jensen, Marschner, Levoy and Hanrahan.

I also wonder whether you have any idea what a "surface normal" is, that you
think SSLT could fit anywhere near.


> last note: should we keep using sslt, or a proper noun (simpler) could be used ?

I for one think "subsurface" is quite a good keyword to use. The proper
technical term is "Subsurface Light Transport" (SSLT), while some refer to it
as "Subsurface Scattering" (SSS), so "subsurface" fits both.

Also note that I'm not in the mood to discuss the whole smash with you. You may
ask me questions, and I may answer those. And you may make comments, and I may
be inspired by those. But I'm positively *NOT* going to *consult* you on how to
implement SSLT, what SDL statements to use, etc.

Honestly, there are lots of other people on these newsgroups I'd ask first.

I feel treated by you as if I had not much of an idea of what I'm doing, or
where to go from where SSLT currently is - and I know for sure that I do NOT
like to be treated that way. If that is really not the case, then I must ask
you to make more effort to convey your true attitude.

Otherwise, any further discussion about SSLT between the two of us ends right
here.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> Otherwise, any further discussion about SSLT between the two of us ends right
> here.

I'm sure we all hate to see 'points of order' getting in the way of genuine
creative discussion, and this seems to be one of those moments.

I wouldn't like to see developers' time wrapped up in answering FAQs, answering
points that have been adequately answered in the past, or be sidetracked into
peripheral arguments, and instead have them doing what they enjoy: the creative
stuff that helps future POV-Ray users to create great-looking images.

I was going to suggest that a short statement be composed about the new SSLT
implelementation, but remembered that was the first thing that clipka did:
stating that it was *a first attempt, at alpha quality, in a beta release*. We
also discussed priorities that would enable SSLT to be more useful in general
scenes. I wonder if that information could be better-placed, so that we don't
get into today's situation so easily?

So yes, I would suggest that anyone wanting to pitch in - with key ideological
statements, or converse opinions about the correctness of an agreed approach -
read up and be well-versed in the background material, including having a go at
reading the referenced SigGraph paper, understanding what's happening with light
in real life, and how SSLT approximates it, and also having a play with POV-Ray
to understand the limitations. I would consider any less understanding - at
least when throwing major curveballs - to be a little disrespectful to others
here.

Having said that, I see no harm in people pitching shorter questions that can be
quickly answred, in a way that does not take much time for all parties (who are:
the curious posters, the knowledgeable answerers, and those who plough through
the material in search of something they can contribute towards).

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> 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.
> [...]
> 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.

Does this raise some fundamental design questions about POV-Ray? We have the
original direct lighting model, the radiosity model, and photons, we have
different attributes, like surfaces/finishes (ambient, diffuse, specular),
interiors (media, SSLT, fog), and we have different modelling constructs
(primitives shapes, implicit surfaces, CSG, closed composites).

The problem is that they do not all talk to each other like we would casually
expect, An example relevant to this post would be SSLT and 'media scattering'
currently only working with direct light sources.

Is it worth asking a fundamental design question about standards and interfaces
for the very top-level of (classifications of) POV objects? (surfaces,
interiors, models), so that all compliant features, new and old, will operate
with all the others? I appreciate that new features might necessarily introduce
new elements to the interfaces, if they are radical enough.

I'm going to cross-post this to the POV v4 thread, and encourage responses
there, rather than here.

Post a reply to this message

"MessyBlob" <nomail@nomail> wrote:
> > Define "same object" in a CSG setting... tricky.
>
> Does this raise some fundamental design questions about POV-Ray? We have the
> original direct lighting model, the radiosity model, and photons, we have
> different attributes, like surfaces/finishes (ambient, diffuse, specular),
> interiors (media, SSLT, fog), and we have different modelling constructs
> (primitives shapes, implicit surfaces, CSG, closed composites).
>
> The problem is that they do not all talk to each other like we would casually
> expect, An example relevant to this post would be SSLT and 'media scattering'
> currently only working with direct light sources.

As for this particular issue, that's just due to an outright hack that's still
in the SSLT code, which circumvents the standard light source handling stuff
until I've found the time to integrate it properly.

> Is it worth asking a fundamental design question about standards and interfaces
> for the very top-level of (classifications of) POV objects? (surfaces,
> interiors, models), so that all compliant features, new and old, will operate
> with all the others? I appreciate that new features might necessarily introduce
> new elements to the interfaces, if they are radical enough.

The interfaces between the various components are still a bit more fuzzy than
I'd like them to be, but integrating SSLT is a good opportunity to address
these issues, and I'm about to do just that.

Post a reply to this message