![](/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) |
Hi all,
There are a lot more things that work now, but when I run through
Nathan's set of demos, the "splash.pov" demo get's stuck on creating
bounding slabs. It worked with the 0.1 version, but now it's been
"creating bounding slabs" for about half an hour!
--
Carl Bartels, Department of Chemsitry, Mcgill University, to reply to
me,
just kill a and 5 from the email name, Montreal, QC, cAnAdA
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) |
Carl Bartels wrote:
>
> Hi all,
>
> There are a lot more things that work now, but when I run through
> Nathan's set of demos, the "splash.pov" demo get's stuck on creating
> bounding slabs. It worked with the 0.1 version, but now it's been
> "creating bounding slabs" for about half an hour!
I've had no better luck with splash.pov. It's on my list of things to
look at.
BTW, I have three days of vacation this week (Wed-Fri), so I should be
able to get quite a bit done in the next week.
-Mark Gordon
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 article <385460E5.8AE996D0@mailbag.com>, mtg### [at] povray org wrote:
> I've had no better luck with splash.pov. It's on my list of things to
> look at.
The MegaPatch splash screen? I have had no trouble rendering it with
MacMegaPOV, I haven't tried compiling the latest version yet.
--
Chris Huff
e-mail: chr### [at] yahoo com
Web page: http://chrishuff.dhs.org/
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) |
Strange. I just rendered it with no problems. How widespread is this
problem? I'll upload the EXE again (the EXE that I just used to
successfully render the scene).
-Nathan
Carl Bartels <cab### [at] bravo435 chem mcgill ca> wrote...
> Hi all,
>
> There are a lot more things that work now, but when I run through
> Nathan's set of demos, the "splash.pov" demo get's stuck on creating
> bounding slabs. It worked with the 0.1 version, but now it's been
> "creating bounding slabs" for about half an hour!
> --
> Carl Bartels, Department of Chemsitry, Mcgill University, to reply to
> me,
> just kill a and 5 from the email name, Montreal, QC, cAnAdA
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) |
Nathan Kopp wrote:
>
> Strange. I just rendered it with no problems. How widespread is this
> problem? I'll upload the EXE again (the EXE that I just used to
> successfully render the scene).
Carl is using a Linux version. I'm not sure if he's using the one he
made himself or mine. Mine is dumping core for me in this file. I
suspect some of the existing code has previously undiagnosed platform
dependencies that I haven't chased down yet. I'll see what I can find
out.
-Mark Gordon
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) |
Actually, I was using my own compile at the time (under Linux). I get
similar results with Marks version, I just hadn't had a chance to play
with it yet at that point last night. The difference between the
behavior of my compile and Marks is that his kindly dumps core while
mine just sits there all locked up with the image half rendered (kill -9
is the only way to stop it.) I've found a few more test images that
it'll do this for, including the chess2 image that comes with the
official distribution (I figured I'd check to see if the traditional
images still worked.)
Mark Gordon wrote:
>
> Nathan Kopp wrote:
> >
> > Strange. I just rendered it with no problems. How widespread is this
> > problem? I'll upload the EXE again (the EXE that I just used to
> > successfully render the scene).
>
> Carl is using a Linux version. I'm not sure if he's using the one he
> made himself or mine. Mine is dumping core for me in this file. I
> suspect some of the existing code has previously undiagnosed platform
> dependencies that I haven't chased down yet. I'll see what I can find
> out.
>
> -Mark Gordon
--
Carl Bartels, Department of Chemsitry, Mcgill University, to reply to
me,
just kill a and 5 from the email name, Montreal, QC, cAnAdA
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) |
Carl Bartels wrote:
>
> Actually, I was using my own compile at the time (under Linux). I get
> similar results with Marks version, I just hadn't had a chance to play
> with it yet at that point last night. The difference between the
> behavior of my compile and Marks is that his kindly dumps core while
> mine just sits there all locked up with the image half rendered (kill -9
> is the only way to stop it.) I've found a few more test images that
> it'll do this for, including the chess2 image that comes with the
> official distribution (I figured I'd check to see if the traditional
> images still worked.)
My version also hangs on chess2.pov, just to clarify. I've had this
same experience. Carl, are you using my binaries or compiling from
source?
-Mark Gordon
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) |
I think i know the problem. (i'm
bad i never brought it up before
whip me beat me make me write bad
cheques. =} )
It has to do with the reflection blur.
but it crash dumps if you don't use fastmath
and loops if you do (dunno why just what
happened with me and i never tested the fix
with fast math)
what hapens is in the following snippet of code of reflect:
z = (FRAND() * 2) - 1;
t = FRAND() * M_PI * 2;
r = sqrt(1 - z*z);
x = r * cos(t);
y = r * sin(t);
Make_Vector(Jitter_Offset, x, y, z);
if FRAND ****EVER**** returns something larger then
1 (lets say its really bad and it return 1.01)
z = 1.01 * 2 - 1 = 1.02
r = sqrt( 1 - z*z) = sqrt( 1 - 1.004)
= sqrt (- 0.004) = NAN
so your vector becomes corrupt and either
a test down the line fails and it trys to
acess a pointer that should be null
or a depth intersection test loops.
the fix is in texture.h
is to change
#define RNDMULTIPLIER ((DBL)0.000030518509476)
cause perl -e 'print 0.000030518509476*(2**15-1);'
1.00000000000009
so i change it to around:
#define RNDMULTIPLIER ((DBL)0.0000305185094759972)
(or round DOWN)
#define RNDMULTIPLIER ((DBL)0.000030518509475)
perl -e 'print 0.0000305185094759972*(2**15-1);'
1
perl -e 'print 0.000030518509475*(2**15-1);'
0.9999999999673251
Carl Bartels wrote:
>
> Actually, I was using my own compile at the time (under Linux). I get
> similar results with Marks version, I just hadn't had a chance to play
> with it yet at that point last night. The difference between the
> behavior of my compile and Marks is that his kindly dumps core while
> mine just sits there all locked up with the image half rendered (kill -9
> is the only way to stop it.) I've found a few more test images that
> it'll do this for, including the chess2 image that comes with the
> official distribution (I figured I'd check to see if the traditional
> images still worked.)
>
> Mark Gordon wrote:
> >
> > Nathan Kopp wrote:
> > >
> > > Strange. I just rendered it with no problems. How widespread is this
> > > problem? I'll upload the EXE again (the EXE that I just used to
> > > successfully render the scene).
> >
> > Carl is using a Linux version. I'm not sure if he's using the one he
> > made himself or mine. Mine is dumping core for me in this file. I
> > suspect some of the existing code has previously undiagnosed platform
> > dependencies that I haven't chased down yet. I'll see what I can find
> > out.
> >
> > -Mark Gordon
>
> --
> Carl Bartels, Department of Chemsitry, Mcgill University, to reply to
> me,
> just kill a and 5 from the email name, Montreal, QC, cAnAdA
--
Matthew Corey Brown XenoArch
mcb### [at] xenoarch com http://www.xenoarch.com
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) |
Matthew Corey Brown - XenoArch wrote:
>
> I think i know the problem. (i'm
> bad i never brought it up before
> whip me beat me make me write bad
> cheques. =} )
Tsk, tsk, tsk. Thanks for bringing it up now, though!
-Mark Gordon
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) |
Mark Gordon wrote:
>
> Matthew Corey Brown - XenoArch wrote:
> >
> > I think i know the problem. (i'm
> > bad i never brought it up before
> > whip me beat me make me write bad
> > cheques. =} )
>
> Tsk, tsk, tsk. Thanks for bringing it up now, though!
>
> -Mark Gordon
took me a week to track down that bug in superpatch
did get me to learn gdb though. And has got
me to always use the -g flag, too bad its not
smart enough to know the symbols when you use
-finline-functions
--
Matthew Corey Brown XenoArch
mcb### [at] xenoarch com http://www.xenoarch.com
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |