![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Using the trace() function with either mesh or mesh2 causes my copy of
WinMegaPov 0.4 to exit with an illegal operation. Same happens with the
SuperPatch 3.1e (Windows version). Must an old problem, but somehow I've missed
it until now.
Neither individual triangles nor unions of triangles are affected.
Margus
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Yes, the mesh queue was not initialized before the parse. This same problem
happened with blobs, too. It will be fixed in the next version.
-Nathan
Margus Ramst <mar### [at] peak edu ee> wrote...
> Using the trace() function with either mesh or mesh2 causes my copy of
> WinMegaPov 0.4 to exit with an illegal operation. Same happens with the
> SuperPatch 3.1e (Windows version). Must an old problem, but somehow I've
missed
> it until now.
> Neither individual triangles nor unions of triangles are affected.
>
> Margus
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Sun, 6 Feb 2000 20:54:13 -0500, Nathan Kopp wrote:
>Yes, the mesh queue was not initialized before the parse. This same problem
>happened with blobs, too. It will be fixed in the next version.
I know I fixed that once. Did it somehow not make it into the version
I put online?
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In your posted version the blob queue was fixed, but the mesh queue was not.
BTW, is it a good idea to leave initialize the queue before parsing and
leave it that way after the trace() function is called? Might it be a good
idea to reset it between parsing and rendering and even between successive
calls to trace()?
Instead of calling Initialize_xxx_Code before parse, it would probably be
better to call Initialize_xxx_Code before calling Intersection within
Parse_Trace and then calling Deinitialize_xxx_Code after that call to
Intersection and finally calling Initialize_xxx_Code between parsing and
rendering.
-Nathan
Ron Parker <ron### [at] povray org> wrote in message
news:slr### [at] parkerr fwi com...
> On Sun, 6 Feb 2000 20:54:13 -0500, Nathan Kopp wrote:
> >Yes, the mesh queue was not initialized before the parse. This same
problem
> >happened with blobs, too. It will be fixed in the next version.
>
> I know I fixed that once. Did it somehow not make it into the version
> I put online?
>
> --
> These are my opinions. I do NOT speak for the POV-Team.
> The superpatch: http://www2.fwi.com/~parkerr/superpatch/
> My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Sun, 6 Feb 2000 22:57:23 -0500, Nathan Kopp wrote:
>In your posted version the blob queue was fixed, but the mesh queue was not.
Oddly enough, my local version is that way too. It must have been one of
the changes I lost when my HD died.
>BTW, is it a good idea to leave initialize the queue before parsing and
>leave it that way after the trace() function is called? Might it be a good
>idea to reset it between parsing and rendering and even between successive
>calls to trace()?
Does it do that when you render a real scene? If so, then yes. If not,
there's probably no harm in initializing it early. Personally, I can't find
anywhere that it gets initialized other than that first call, so I'd guess
it's fine the way it is.
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Ron Parker <ron### [at] povray org> wrote...
> On Sun, 6 Feb 2000 22:57:23 -0500, Nathan Kopp wrote:
>
> >BTW, is it a good idea to leave initialize the queue before parsing and
> >leave it that way after the trace() function is called? Might it be a
good
> >idea to reset it between parsing and rendering and even between
successive
> >calls to trace()?
>
> Does it do that when you render a real scene? If so, then yes. If not,
> there's probably no harm in initializing it early. Personally, I can't
find
> anywhere that it gets initialized other than that first call, so I'd guess
> it's fine the way it is.
I took a closer look at the queue and it doesn't cache any data between
successive calls to Intersect, so it is OK the way it is and the
reinitialization is not necessary.
-Nathan
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |