 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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 chemmcgillca> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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 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] xenoarchcom http://www.xenoarch.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] xenoarchcom http://www.xenoarch.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
My two tests consist of either using your binaries or compiling from
source with my own mangled version. Basically I'm using the whole thing
as a learning experience. Should have picked a smaller project to learn
on :P
BTW, I added the #define UNIX stuff to my unixconf.h file and I still
get that stricmp problem during linking, so I'm back to my original fix
until I figure out what's going on.
Mark Gordon wrote:
>
> Carl Bartels wrote:
> >
> > Actually, I was using my own compile at the time (under Linux). I get
<snip stuff about chess2.pov looping/crashing>
> > 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
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Carl Bartels wrote:
>
> My two tests consist of either using your binaries or compiling from
> source with my own mangled version. Basically I'm using the whole thing
> as a learning experience. Should have picked a smaller project to learn
> on :P
There's a suggested fix out there I mean to try out tonight...
> BTW, I added the #define UNIX stuff to my unixconf.h file and I still
> get that stricmp problem during linking, so I'm back to my original fix
> until I figure out what's going on.
Weird. Was this before or after you independently discovered that you
need to #include "frame.h"?
-Mark Gordon
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Gordon wrote:
>
> Carl Bartels wrote:
> >
<snip>
>
> > BTW, I added the #define UNIX stuff to my unixconf.h file and I still
> > get that stricmp problem during linking, so I'm back to my original fix
> > until I figure out what's going on.
>
> Weird. Was this before or after you independently discovered that you
> need to #include "frame.h"?
This was before. I gotta stop posting in different places. It get's
confusing.
As for the single binary idea I mentioned in the povray.unix group,
there was one point in a readme for the source where it suggested doing
make newunix ; make xwin ; make svga to get all the binaries. I don't
know if that was just with 3.02 or something more recent though. This
has be noticed before, but I guess it was pretty low priority since it's
easy to work around it.
Another reason I wanted just one binary was because all three takes up
space. But then, I only ever use x-povray so I guess it doesn't really
matter much.
--
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
|
|
| |
| |
|
|
|
|
| |
