 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"An access violation exception was generated at address 0x00000001400491C4"
Anybody know why this might happen? I've been getting it a lot. The size of
the render (say, 2400x1200) and number of included files (both images and POV
files) seem to increase the probability of the failure.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 24/10/2009 06:28, Kirk Andrews nous fit lire :
> "An access violation exception was generated at address 0x00000001400491C4"
>
> Anybody know why this might happen? I've been getting it a lot. The size of
> the render (say, 2400x1200) and number of included files (both images and POV
> files) seem to increase the probability of the failure.
>
>
A bit more of details, please ?
Does it happen at parse time, or render time ?
Have you any additional time ? (photons, radiosity)
So far, you're like a car driver reporting "the more kilometres/miles I
do at once, the more likely I got a problem."; you do not show the car
to the mechanics' (minimal reproducing scene), and you do not even tell
the company if it's a tire/gazolin/engine problem, or may be just a side
window which cannot be operated. "it make noise sometimes".. nobody is
officially a psychic here, it will be very difficult to get more details
if you do not provide them.
You assumed size of render can influence that: what are the
investigations you made to affirm that ? (you might be true, but so far
you have provided no proof or even the detail of a study which might
lead to that conclusion). Same for others points.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron wrote:
> Le 24/10/2009 06:28, Kirk Andrews nous fit lire :
>> "An access violation exception was generated at address 0x00000001400491C4"
>>
>> Anybody know why this might happen? I've been getting it a lot. The size of
>> the render (say, 2400x1200) and number of included files (both images and POV
>> files) seem to increase the probability of the failure.
>>
>>
> A bit more of details, please ?
> Does it happen at parse time, or render time ?
> Have you any additional time ? (photons, radiosity)
>
> So far, you're like a car driver reporting "the more kilometres/miles I
> do at once, the more likely I got a problem."; you do not show the car
> to the mechanics' (minimal reproducing scene), and you do not even tell
> the company if it's a tire/gazolin/engine problem, or may be just a side
> window which cannot be operated. "it make noise sometimes".. nobody is
> officially a psychic here, it will be very difficult to get more details
> if you do not provide them.
>
> You assumed size of render can influence that: what are the
> investigations you made to affirm that ? (you might be true, but so far
> you have provided no proof or even the detail of a study which might
> lead to that conclusion). Same for others points.
My apologies for the sparse information--it was late and I was
frustrated that my scene had failed to render once again. It seems that
as soon as I'm ready to finish a scene and crank up the settings for an
overnight render, this happens.
I had successfully rendered the scene at lower resolutions, although not
all of the quite the same for things like radiosity, media, number of
trees, or resolution of height_fields.
It parses fine; it seems to always happen about 5% of the way through
the render itself. There doesn't seem to be anything particularly
unique in the image at the point at which it stops. In fact, sometimes
it will render fine with the camera one way, but if I rotate the camera,
then the access violation will occur. Yet, it is not random--that is,
if I leave the scene the same way, it will happen 100% of the time.
The access violation code number seems to be consistent every time.
---
I'm using beta 34, 64 bit version on a 64 bit Vista system with 2 cores.
Current settings: +W2400 +H1200 +fn16 +a0.2 +WL0 -RVP +SP8 +EP8
In the scene are several high-resolution height_fields, ~160k POV-Trees,
low-grade radiosity and media, a low-quality area light, and an infinite
plane. The height_fields are created using functions made from tga
files from World Machine.
I use a averaged object pattern to generate a simple proximity function
that governs several textures on the height_fields.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Argg. There it goes again, this time at 2% of the render.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kirk Andrews schrieb:
> It seems that
> as soon as I'm ready to finish a scene and crank up the settings for an
> overnight render, this happens.
>
> I had successfully rendered the scene at lower resolutions, although not
> all of the quite the same for things like radiosity, media, number of
> trees, or resolution of height_fields.
>
> It parses fine; it seems to always happen about 5% of the way through
> the render itself. There doesn't seem to be anything particularly
> unique in the image at the point at which it stops. In fact, sometimes
> it will render fine with the camera one way, but if I rotate the camera,
> then the access violation will occur. Yet, it is not random--that is,
> if I leave the scene the same way, it will happen 100% of the time.
>
> The access violation code number seems to be consistent every time.
>
> ---
>
> I'm using beta 34, 64 bit version on a 64 bit Vista system with 2 cores.
>
> Current settings: +W2400 +H1200 +fn16 +a0.2 +WL0 -RVP +SP8 +EP8
>
> In the scene are several high-resolution height_fields, ~160k POV-Trees,
> low-grade radiosity and media, a low-quality area light, and an infinite
> plane. The height_fields are created using functions made from tga
> files from World Machine.
>
> I use a averaged object pattern to generate a simple proximity function
> that governs several textures on the height_fields.
Would you mind getting one of the 100% offending scenes to me (either in
p.b.scene-files, or to "christoph" at the server "lipka-koeln.de"),
along with image files & .ini / command line settings, so I can have a
look at it with the debugger?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Kirk Andrews schrieb:
>
> > It seems that
>> as soon as I'm ready to finish a scene and crank up the settings for
>> an overnight render, this happens.
>>
>> I had successfully rendered the scene at lower resolutions, although
>> not all of the quite the same for things like radiosity, media, number
>> of trees, or resolution of height_fields.
>>
>> It parses fine; it seems to always happen about 5% of the way through
>> the render itself. There doesn't seem to be anything particularly
>> unique in the image at the point at which it stops. In fact,
>> sometimes it will render fine with the camera one way, but if I rotate
>> the camera, then the access violation will occur. Yet, it is not
>> random--that is, if I leave the scene the same way, it will happen
>> 100% of the time.
>>
>> The access violation code number seems to be consistent every time.
>>
>> ---
>>
>> I'm using beta 34, 64 bit version on a 64 bit Vista system with 2 cores.
>>
>> Current settings: +W2400 +H1200 +fn16 +a0.2 +WL0 -RVP +SP8 +EP8
>>
>> In the scene are several high-resolution height_fields, ~160k
>> POV-Trees, low-grade radiosity and media, a low-quality area light,
>> and an infinite plane. The height_fields are created using functions
>> made from tga files from World Machine.
>>
>> I use a averaged object pattern to generate a simple proximity
>> function that governs several textures on the height_fields.
>
> Would you mind getting one of the 100% offending scenes to me (either in
> p.b.scene-files, or to "christoph" at the server "lipka-koeln.de"),
> along with image files & .ini / command line settings, so I can have a
> look at it with the debugger?
Sure, and thanks--but probably I should find a somewhat less complicated
offending scene--this one has dozens of included files.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kirk Andrews schrieb:
>> Would you mind getting one of the 100% offending scenes to me (either
>> in p.b.scene-files, or to "christoph" at the server "lipka-koeln.de"),
>> along with image files & .ini / command line settings, so I can have a
>> look at it with the debugger?
>
> Sure, and thanks--but probably I should find a somewhat less complicated
> offending scene--this one has dozens of included files.
That would be even better of course.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
