In article <web.457b13e2315c6ef0adb4e0ea0@news.povray.org>, 
sra### [at] yahoocom says...
> Thank you for your contribution, Patrick.
> Patrick Elliott <sel### [at] rraznet> wrote:
> > The only issue this causes is
> > maybe needing to state me.<blah> or local.<blah> as a means to saying,
> > "Yes, I **really** did intend to use the local one, so don't warn me."
> >
> > But, that doesn't do anything different than I suggest and it means
> > **extra** time is taken "every" parse, to fix conflicts. Better to
> > specify a system, then provide a means to update non-compatible scenes
> > to the new standard.
> >
> 
> Did you actually read the most recent posting I made to this thread? (asi
de
> from response to Bob)  What did I have to say about any changes to user
> responsibilities?  I would prefer that questions and suggestions in this
> thread be limited to discussion about the algorithms needed to implement
> "retroactive aliasing" and the C++ code needed to make the model a realit
y.
>  Discussing whether or not such an idea is a good one in theory is not
> enough.  People need to be able to try it out - and to try out other mode
ls
> - and to decide what works the best for their needs.
> 
I am not sure what your complaint is about though. This isn't like 
deciding if we want to include some new object, because the number of 
people that might need object A instead of object B means that A won't 
work for the B people. The point is likely mute anyway, since the only 
place this is likely to show up is in MegaPOV. POV-Ray 4 will 
"probably" implement something more like I am talking about anyway, so 
any converter that does it in the background, where no one can see it, 
won't conform to the new specs anyway when that comes out. Nothing we do 
know is likely to either, unless its adopted into the new specs. Your 
idea is a stop gap, and a mostly unneeded one imho, given that it can be 
more easily handled, if someone really needs it, with a separate 
application.

While I tend to sort of agree with the principle of letting people 
figure out what works best, that's not going to happen on a project like 
you suggest. The effort of redoing the parser to do what you want would 
take more then sufficient time to accomplish to leave no time for anyone 
to consider an alternative. And ironically, the *only* major differences 
seem to be a) you thinking that "on the fly" is some magic solution that 
won't spend extra time every parse and b) doing it all internally, 
instead of exporting a copy that doesn't need "on the fly" modification 
to work. Then again, there is no practical reason why extra flags can't 
be included, like, "Export_Adjusted_Scenes = T/F", and, 
"Use_Exported_Scenes = T/F". In other words, give people the option of 
having the first pass, like in an animation, export a fixed version of 
all the files, then also have the option in the next frame to look to 
see if that file(s) exist and use "it/them" for the next parse. Any "on 
the fly" solution "must" take extra time to make those corrections. Its 
silly to do it once for every 500 frames in an animation. And the code 
needed to rework POV-Ray's internals to cache the scene and reuse it, 
with appropriate changes each frame, is going to be "more" complex than 
just exporting it once and reusing that result. At least I predict it 
would be.

Anyway, was just dropping a suggestion and trying to state a few 
problems I saw with your solution, not start a big argument over it. 
Good luck trying to figure it out.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message