Hello!

I was testing some texturing in meshes (because i'm very bad texturing 

upload the file (190k compressed)?

More data:
//Pov 3.7 beta 34
Windows XP
Pentium 4 @ 2GHz

The dialog says: A stack overflow exception was generated at address 
0x005570d7

with reflection{} less than 1.0 it renders ok

Thank you!

Post a reply to this message

Martin <don### [at] onocom> wrote:
> Hello!
>
> I was testing some texturing in meshes (because i'm very bad texturing

> upload the file (190k compressed)?
>
> More data:
> //Pov 3.7 beta 34
> Windows XP
> Pentium 4 @ 2GHz
>
> The dialog says: A stack overflow exception was generated at address
> 0x005570d7
>
> with reflection{} less than 1.0 it renders ok
>
> Thank you!


I am kind of curious about this.  I've used wings a lot and haven't come across
this (yet).  What are your max_trace_level settings?  Is the reflective texture
applied on a per vertex basis?  I would be interested if you posted it to
povray.binaries.scene-files and linked to it from here.



-Reactor

Post a reply to this message

Martin <don### [at] onocom> wrote:
> Hello!
>
> I was testing some texturing in meshes (because i'm very bad texturing
> :P) exported from Wings 3D, when pov crashed while rendering



Duplicated it on my own!  Interesting, never seen this before.  Ok, tested an
identical scene under 64-bit Windows XP SP2, 32-bit version of POV 3.6.2, and
the scene renders just fine.  The crashes occurred in the 64-bit version 3.7 b34
(also under Windows XP 64 SP2)

To trigger the crash seems to require a mesh with more than about 5000 vertices,
I was able to get the crash with a 6000 vertex mesh.  The key seems to be
something around the normals and the textures applied on a per vertex basis, as
I exported and rendered the same mesh with:
* uv_vectors and normal_vectors (crashed)
* normal_vectors only (crashed)
* uv_vectors only (completed successfully)
* neither uv or normal vectors (completed successfully)
(I ran meshes with only smoothed normals and a combination of smooth and hard
edges to get the above using a max_trace_level of 1 )
Then, with some fancy find-and-replacery, I removed the texture index after each
face, removed the texture_list{}, then re-ran a crashing mesh with the texture
applied to the entire mesh.  This allowed the render to complete successfully.

Here is where it gets weird:  While minimizing a scene for this, I found that
changing the aspect ratio very slightly can sometimes prevent a crash.  That is,
changing  right <4/3,0,0> to right <4.0001/3,0,0> allow renders that previously
crashed to complete successfully.  I tried a few others, but could not find any
sort of pattern - sometimes a given aspect ratio would crash, other times it
would complete successfully.  Same with changing the output resolution - crashes
became more random instead of certain.

A problem I ran into while trying to duplicate this is that... well, I couldn't
always.  I wanted to (partially) rule out the exporter outputting improperly
formatted meshes, so I exported some using the subdivision option and others
smoothed manually.  The manually smoothed ones did not crash, but the mesh
topography was slightly different (different number of vertexes, slightly
different shape)  from running the smooth command twice, as opposed to telling
it to subdivide for 2 steps (this isn't so strange, I suspect it is because the
subdivide command tessellates into triangles first, but the mesh had
quadrilaterals when I smoothed).

I hope this helps someone who has a better understanding of these things than I
do. ;)

-Reactor

Post a reply to this message

> Martin <don### [at] onocom> wrote:
>> Hello!
>>
>> I was testing some texturing in meshes (because i'm very bad texturing
>> :P) exported from Wings 3D, when pov crashed while rendering
> 
> 
> 
> Duplicated it on my own!  Interesting, never seen this before.  Ok, tested an
> identical scene under 64-bit Windows XP SP2, 32-bit version of POV 3.6.2, and
> the scene renders just fine.  The crashes occurred in the 64-bit version 3.7 b34
> (also under Windows XP 64 SP2)
> 
> To trigger the crash seems to require a mesh with more than about 5000 vertices,
> I was able to get the crash with a 6000 vertex mesh.  The key seems to be
> something around the normals and the textures applied on a per vertex basis, as
> I exported and rendered the same mesh with:
> * uv_vectors and normal_vectors (crashed)
> * normal_vectors only (crashed)
> * uv_vectors only (completed successfully)
> * neither uv or normal vectors (completed successfully)
> (I ran meshes with only smoothed normals and a combination of smooth and hard
> edges to get the above using a max_trace_level of 1 )
> Then, with some fancy find-and-replacery, I removed the texture index after each
> face, removed the texture_list{}, then re-ran a crashing mesh with the texture
> applied to the entire mesh.  This allowed the render to complete successfully.
> 
> Here is where it gets weird:  While minimizing a scene for this, I found that
> changing the aspect ratio very slightly can sometimes prevent a crash.  That is,
> changing  right <4/3,0,0> to right <4.0001/3,0,0> allow renders that previously
> crashed to complete successfully.  I tried a few others, but could not find any
> sort of pattern - sometimes a given aspect ratio would crash, other times it
> would complete successfully.  Same with changing the output resolution - crashes
> became more random instead of certain.
> 
> A problem I ran into while trying to duplicate this is that... well, I couldn't
> always.  I wanted to (partially) rule out the exporter outputting improperly
> formatted meshes, so I exported some using the subdivision option and others
> smoothed manually.  The manually smoothed ones did not crash, but the mesh
> topography was slightly different (different number of vertexes, slightly
> different shape)  from running the smooth command twice, as opposed to telling
> it to subdivide for 2 steps (this isn't so strange, I suspect it is because the
> subdivide command tessellates into triangles first, but the mesh had
> quadrilaterals when I smoothed).
> 
> I hope this helps someone who has a better understanding of these things than I
> do. ;)
> 
> -Reactor
> 
> 

Ah, deep testing session :). Here is the scene file 
http://news.povray.org/4b1fb5ce%40news.povray.org

I just used the default settings to export the mesh. As you'll see in 
the .pov file i don't use uv_mapping. But there are uv_vectors all of 
them <0,0,0>... (<-candidate #1 :? I guess).

At first it had no subdivisions (and I think also crashed), but as the 
reflections were wavy, i tried to make 1 subdivision to see if the 
problem was solved (answer: no). Finaly I did the mesh again (the simple 
block) and it looks better (with 1 subdivision also).

It will be interesting to know if this error occurs also in linux or mac.

Martin.

Post a reply to this message

Martin schrieb:

> I was testing some texturing in meshes (because i'm very bad texturing 

> upload the file (190k compressed)?
> 
> More data:
> //Pov 3.7 beta 34
> Windows XP
> Pentium 4 @ 2GHz

Did you check with beta 35(a) yet?

 From the problem description, this sounds like a "twin" to error report 
"FS#53 - Blob trace level" (see http://bugs.povray.org), except for 
meshes instead of blobs. In that case, the fix for FS#53 that was 
released with beta 35 should also fix your problem.

Post a reply to this message

> Martin schrieb:
> 
>> I was testing some texturing in meshes (because i'm very bad texturing 

>> upload the file (190k compressed)?
>>
>> More data:
>> //Pov 3.7 beta 34
>> Windows XP
>> Pentium 4 @ 2GHz
> 
> Did you check with beta 35(a) yet?
> 
>  From the problem description, this sounds like a "twin" to error report 
> "FS#53 - Blob trace level" (see http://bugs.povray.org), except for 
> meshes instead of blobs. In that case, the fix for FS#53 that was 
> released with beta 35 should also fix your problem.

Yes. I have left pov a bit apart, but now you say it, i just checked it 
and it works fine. Thank you, for doing POV-Ray

Post a reply to this message