![](/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) |
[Note: Unfortunately I didn't have net access at home this morning
where the following problem occurred so I have neither code nor saved
error message handy, but I can try to reproduce the problem and post
or send those if wanted... er, well, I'd rather not post the 500 lines
of code, but I can at least post radiosity settings and anything else
deemed pertinent.]
So, I turned on radiosity on an image and it crashed while doing the
first pass. "Hmm, how odd," said I. I switched from MegaPov 0.7 to
MegaPov 0.5 just to see if maybe it was a new version problem, but the
same thing happened.
So, after spending a while playing with various pieces of my code to
see if anything in particular was causing the crash, I started playing
with radiosity settings. I finally managed to get it to at least get
past the crash point and well into the render (which was still going
when I left for work), apparently because I explicitly put in
recursion_limit 1.
I'm wondering if anyone else has had this problem; I haven't seen
another post on it, though. Should I always be using an explicit
recursion_limit? I haven't really done anything with radiosity before
so this is all new to me.
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) |
Well, I just got home and there'd been another crash, about 15% of the way
through the actual render. Here's the error:
MEGAPOV caused an invalid page fault in
module <unknown> at 0000:a325d27e.
Registers:
EAX=019aeae0 CS=016f EIP=a325d27e EFLGS=00010282
EBX=01c19eb8 SS=0177 ESP=019aeac8 EBP=01bf37c0
ECX=00000000 DS=0177 ESI=005252d8 FS=2137
EDX=bfef1750 ES=0177 EDI=019aeaf8 GS=0000
Bytes at CS:EIP:
Stack dump:
0041c4e7 01c19eb8 019aeae0 019aeb38 00520180 00520180 bf3a4e40 bfef1750
00000000 3ff80000 9c619538 3fdd69d8 00417656 a325d27e 005252d8 00505c30
The image renders fine so long as radiosity is not on. Here's my current
set of radiosity settings:
radiosity {
count 200
distance_maximum 300
error_bound 0.4
minimum_reuse 0.025
nearest_count 8
recursion_limit 1
}
I've tried it with a number of various settings, including having just
count and distance_maximum; count has been variously 100, 150, and the
above 200; distance_maximum has been as low as 50, no higher than the
above 300; error_bound has been as high as 0.8, all in various
combinations.
Other things that might be of use in deciphering the problem:
There are two light-sources in my image, both point lights; I have tried
commenting out one or the other, and it doesn't help.
I am using media in the image, but taking it out doesn't solve the
problem.
There is one fairly highly reflective surface in the image but it's far
'down' in the image and the render gets nowhere near it.
Lastly, hardware and software:
pII 400 mhz, 128M RAM, ATI Rage Pro Turbo 2X 8MB card
Win98 4.10.2222 A
WinMegaPov 0.7, recently downloaded (last few weeks)
[Has also crashed under Win MegaPov 0.5, but I've experimented less under
that version.]
If no one has any idea why this might be happening I'll probably start
taking the code apart and rendering it piece by piece to see if I can
figure out if there's something specific in my code that could cause this.
-- Tina (Who wants to guess what I do for a living, btw?)
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) |
you### [at] foad org wrote:
> [...]
> The image renders fine so long as radiosity is not on. Here's my current
> set of radiosity settings:
>
> radiosity {
> count 200
> distance_maximum 300
> error_bound 0.4
> minimum_reuse 0.025
> nearest_count 8
> recursion_limit 1
> }
>
> I've tried it with a number of various settings, including having just
> count and distance_maximum; count has been variously 100, 150, and the
> above 200; distance_maximum has been as low as 50, no higher than the
> above 300; error_bound has been as high as 0.8, all in various
> combinations.
There is nothing problematic about these settings, just two things:
- distance_maximum is no more needed in megapov and should have no effect.
- the default recursion_limit (if not specified) is 3 (referring to your
previous post).
I just tested these settings in a scene i'm working on and it rendered
without problems.
>
> Other things that might be of use in deciphering the problem:
>
> There are two light-sources in my image, both point lights; I have tried
> commenting out one or the other, and it doesn't help.
>
> I am using media in the image, but taking it out doesn't solve the
> problem.
>
> There is one fairly highly reflective surface in the image but it's far
> 'down' in the image and the render gets nowhere near it.
That's not necessarily relevant when using radiosity so i would test it
too.
> [...]
>
> If no one has any idea why this might be happening I'll probably start
> taking the code apart and rendering it piece by piece to see if I can
> figure out if there's something specific in my code that could cause this.
>
That would probably be a good idea, i have never had such problems with
radiosity although i did quite a lot of radiosity scenes, and I have no
idea what could cause this. Anyway, you should probably start with
deactivating things using new megapov features, because those are the
things more likely to cause problems than the old and well tested stuff.
Christoph
--
Christoph Hormann <chr### [at] gmx de>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
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) |
> -- Tina (Who wants to guess what I do for a living, btw?)
Politician? ;-)
Nekar
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) |
"Tina S." <you### [at] ucan foad org> wrote in message
news:k0o4ctolldb4ekjc8d7t4i3ueukl2qp5v4@4ax.com...
<stuff about radiosity, MegaPOV and reflection>
That sounds all too familiar - the first thing I'd try is the reflecting
object - just comment out the reflection line and re-render.
I've had similar crashes with MegaPOV and radiosity - I started to track
down the cause, but I don't know enough about the POV source to have got
very far with it. Any how, for those MegaPOV developers reading this, it
looked a lot like either a stack overflow or a 'pointer no longer pointing
to valid memory' problem - reflection definitely seems to be one of the main
culprits, however I also had virtually identical crashes with some
combinations of iso-surface and proximity pattern, unfortunately, though I
could, once I had scene that did, get it to crash each time, every time, the
problem appears to be very scene specific - I had some renders using
reflection, iso's & proximity that finished just fine and others bombed
every time.
I figured out a work around for what I wanted to do, so didn't look too
deeply into the problem, but a quick experiment with various combinations of
radiosity, reflection, proximity and iso's should get things crashing along
quite nicely - it was certainly far easier to find combinations that caused
a crash than one's that didn't. :-(
--
Scott Hill
Software Engineer.
NC Graphics (Cambridge) Ltd.
Web : http://www.ncgraphics.co.uk
E-mail : sco### [at] ncgraphics net
ICQ : 110661991
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) |