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