"melo" <mel### [at] coxnet> wrote in message 
news:web.47bd191c1f639ab3587ef5e20@news.povray.org...
> After all the feedback and pointers I had gotten, and countless hours I 
> had
> invested, I was able to get my animation looking smooth enough, no jumping 
> back
> to default pose between FRAMES, I could remember where the last pose was 
> and
> continue from there on.  Well, what was left to correct my pose files.
>
> Well, first step pose file was done, and just then as I thought I was on a 
> roll,
> POV-RAY crashed, It could not even render frame_number = 1, it displayed
> and errror window saying:
>
>    "The POV_Ray core rendering code threw an unhandled exception.
>
>     The backend thread has been shut down and you will not be able to
>     perform any further renders.
>
>    (Note that if internal structures have been damaged POV-Ray may crash
>    immediately,..
>
> Well. POV-RAY did not crash immediately, however message window did not 
> contain
> any further insights that might help me to come up with a work around 
> despite
> my countless debugging statements.
>
> I am working on a DELL dual core , under Win Vista Home Premium O/S.
>
> Is there  listserve dedicated to reporting system crashes?
>
> Thanks,
> Meltem

Doh! I hate it when that happens.

Once you've determined the precise cause of the crash it could go on 
povray.bugreport, if indeed it is an outstanding bug. In my experience, 
determining the precise cause is often tricky. There have been times when 
I've not been able to determine an exact cause, but I've suspected that it 
could be just a duff character in the scene file (effectively a corrupt 
file).

There are a number of techniques I've used in the past for 
isolating/fixing/working around this sort of a problem. The first thing I'd 
recommend is to take a back up copy of your files, because the techniques 
involve hacking chunks out of the files until the problem goes away and you 
will want to keep a record of how your files look now so that you can 
selectively paste bits back in to rebuild to the current state (but without 
the corruption).

Presumably other files render ok (e.g. the standard POV-Ray test scenes) - 
you may need to restart POV-Ray each time after you get an error like this. 
Presumably your problem is still present when you suppress the animation 
command line options and revert to a single image render.

If you have a recent backup of your work you may care to load up a copy and 
check it still renders.

Then it's down to either chopping large sections out of the scene file until 
you get something that doesn't throw the error, or starting from a blank 
file and copying large sections in until you detect the problem. Once you've 
isolated a section of SDL containing the problem you should be able to chop 
that down and repeat the process until you isolate the offending 
line/character. The ideal initial chunk size is half the file, but you need 
to pick a chunk that will render in isolation. By chopping the offending 
section in half you can usually isolate the bad line suprisingly quickly.

If you determine that it's nothing to do with the animation features you 
could post a question on povray.general to reach a wider audience. Maybe 
someone in the broader POV-Ray community has a better technique for 
isolating these problems.

If you can isolate the problem into a relatively small/understandable 
section of SDL, you could maybe post it on povray.binaries.scene-files to 
see if the problem is reproducable on other platforms. If it's not 
reproducable then the developers would stand little chance of implementing 
any future fixes.

Regards,
Chris B.

Post a reply to this message

Thanks Chris.

Well, in my previous working life, I used to teach and preach good software
engineering practices, one I strongly believed in was configuration/version
control.  Did I apply any of those into this mini skeletal animation personal
project?  Noo.  Can I recall, load an earlier version that did not crash
POV-RAY with most of my additions, enhancements?  Remains to be seen.

Well, how I wish I forced myself to come up with a file header that would
document  what I did since last working version.

Okay, enough self-bashing.  It is a miracle that I remember the additions since
the last working version with corrected POSE file 1.

I will keep  copy of the scene file that crashes POV-RAY.  When v4 comes out, I
will run it against it.

Chris, would you mind giving me a link to your PovPerson again?  The link I had
only had various facial renderings, and examples.  It mentioned that you used
BlobMan as the body for your PovPerson head+Face+Hair.  Now, one other
animation discussion took me to a site that had a full body walking animation
showing the POVPerson walking straight at towards you.

Now I am confused, does PovPerson has a full skeletal and skin and movement
animation, in addition to facial animation?  s/he moves much smoother than my
23 joint rotation driven skeletal.  Looks like once I get it working again, I
need to switch using spline interpolation, I am grateful you encouraged me to
use a macro to do the interpolation between poses, for each joint involved in
the move, for now I linearly changed its rotation vector from its previous
rotation vector to its current rotation vector.   Thanks to arrays, I looped
thru joints, then for each joint participating in the move, I called the the
interpolation macro.  Then when I have all the joint vectors determined as
such, I rendered the scene for that pose. Valla REPEAT FOR AS MANY POSES AS
THERE ARE FOR MOVE. For walking I have 13 Pose files.  For sitting? I shall
see.

Thanks again for taking the time to give me pointers.  Yes, this will be hard
problem to chase down.


"Chris B" <nom### [at] nomailcom> wrote:
> "melo" <mel### [at] coxnet> wrote in message
> news:web.47bd191c1f639ab3587ef5e20@news.povray.org...
> > After all the feedback and pointers I had gotten, and countless hours I
> > had
> > invested, I was able to get my animation looking smooth enough, no jumping
> > back
> > to default pose between FRAMES, I could remember where the last pose was
> > and
> > continue from there on.  Well, what was left to correct my pose files.
> >
> > Well, first step pose file was done, and just then as I thought I was on a
> > roll,
> > POV-RAY crashed, It could not even render frame_number = 1, it displayed
> > and errror window saying:
> >
> >    "The POV_Ray core rendering code threw an unhandled exception.
> >
> >     The backend thread has been shut down and you will not be able to
> >     perform any further renders.
> >
> >    (Note that if internal structures have been damaged POV-Ray may crash
> >    immediately,..
> >
> > Well. POV-RAY did not crash immediately, however message window did not
> > contain
> > any further insights that might help me to come up with a work around
> > despite
> > my countless debugging statements.
> >
> > I am working on a DELL dual core , under Win Vista Home Premium O/S.
> >
> > Is there  listserve dedicated to reporting system crashes?
> >
> > Thanks,
> > Meltem
>
> Doh! I hate it when that happens.
>
> Once you've determined the precise cause of the crash it could go on
> povray.bugreport, if indeed it is an outstanding bug. In my experience,
> determining the precise cause is often tricky. There have been times when
> I've not been able to determine an exact cause, but I've suspected that it
> could be just a duff character in the scene file (effectively a corrupt
> file).
>
> There are a number of techniques I've used in the past for
> isolating/fixing/working around this sort of a problem. The first thing I'd
> recommend is to take a back up copy of your files, because the techniques
> involve hacking chunks out of the files until the problem goes away and you
> will want to keep a record of how your files look now so that you can
> selectively paste bits back in to rebuild to the current state (but without
> the corruption).
>
> Presumably other files render ok (e.g. the standard POV-Ray test scenes) -
> you may need to restart POV-Ray each time after you get an error like this.
> Presumably your problem is still present when you suppress the animation
> command line options and revert to a single image render.
>
> If you have a recent backup of your work you may care to load up a copy and
> check it still renders.
>
> Then it's down to either chopping large sections out of the scene file until
> you get something that doesn't throw the error, or starting from a blank
> file and copying large sections in until you detect the problem. Once you've
> isolated a section of SDL containing the problem you should be able to chop
> that down and repeat the process until you isolate the offending
> line/character. The ideal initial chunk size is half the file, but you need
> to pick a chunk that will render in isolation. By chopping the offending
> section in half you can usually isolate the bad line suprisingly quickly.
>
> If you determine that it's nothing to do with the animation features you
> could post a question on povray.general to reach a wider audience. Maybe
> someone in the broader POV-Ray community has a better technique for
> isolating these problems.
>
> If you can isolate the problem into a relatively small/understandable
> section of SDL, you could maybe post it on povray.binaries.scene-files to
> see if the problem is reproducable on other platforms. If it's not
> reproducable then the developers would stand little chance of implementing
> any future fixes.
>
> Regards,
> Chris B.

Post a reply to this message

> I will keep  copy of the scene file that crashes POV-RAY.  When v4 comes out, I
> will run it against it.

v4? That will come in a few *years*. Remember v4 is a full rewrite from 
scratch, that is still not started.

Post a reply to this message

"melo" <mel### [at] coxnet> wrote in message 
news:web.47be01d8e2d08be6587ef5e20@news.povray.org...
> Chris, would you mind giving me a link to your PovPerson again?

Sure, the V2 Alpha is at http://www.geocities.com/povperson/

> The link I had
> only had various facial renderings, and examples.  It mentioned that you 
> used
> BlobMan as the body for your PovPerson head+Face+Hair.  Now, one other
> animation discussion took me to a site that had a full body walking 
> animation
> showing the POVPerson walking straight at towards you.
>
> Now I am confused, does PovPerson has a full skeletal and skin and 
> movement
> animation, in addition to facial animation?  s/he moves much smoother than 
> my
> 23 joint rotation driven skeletal.

POV-Person V2 has a pretty comprehensive human skeletal definition. All of 
the current models use the same skeletal definition although it's designed 
to support alternative skeletal definitions (e.g. a horse). Many of the body 
parts are shared amongst the different standard models and just scaled 
differently, the heads being the main exception with each model having it's 
own head. Substituting alternative body parts is straight forward as each 
model is defined in its own file. Clothing is generated by stretching a 
dynamically generated mesh around the body parts.

Each joint can be animated separately down to the individual joints in the 
fingers and toes.

There is only very limited facial movement. The eyes rotate in all models. 
The F2 model has the most facial flexibility with macro generated eyelids 
and lips. The eyelids can be opened and closed, but I don't recall getting 
far with animating the lips. The teeth can be animated, but you can't 
actually see them as they're inside the head and you can't yet open the 
mouth. Another perfectly useless feature is the ability to separately 
animate the ears.

In addition to what's there, I now have a new hair model that responds to 
gravity and dynamically generated fingers that I developed since publishing 
the V2 Alpha.

Regards,
Chris B.

Post a reply to this message

>> I will keep  copy of the scene file that crashes POV-RAY.  When v4 
>> comes out, I
>> will run it against it.
> 
> v4? That will come in a few *years*. Remember v4 is a full rewrite from 
> scratch, that is still not started.

ohwait you were talking of POV-Person v4? :$

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:


> >> I will keep  copy of the scene file that crashes POV-RAY.  When v4
> >> comes out, I
> >> will run it against it.
> >
> > v4? That will come in a few *years*. Remember v4 is a full rewrite from
> > scratch, that is still not started.
>
> ohwait you were talking of POV-Person v4? :$

Since I hear it could handle any vertabrate being, I'll refer to it as
POV-Being, if I may.  It can walk, it can talk.  only if one can figure out how
to drive it.  I am counting on the documentation. ;-).

I was very determined to teach myself this skeletal animation, as it could lead
the way for some useful motion research/studies.  However, tracking an
exception error feels like trying to find my way out of a Black Hole I found
myself sucked into.  I could either choose to stay in that Black Hole with the
illusions of grandeur, or break down and respectfully except the fruits of
someone else's hard work, and step out.

Some people have to rediscover the roundness of earth by paddling a small boat
around it,  just so they can feel the joy and pride of having done it
themselves.

Well, when I get discouraged, I use amateur philosophy to poke fun at myself, so
I can keep myself entertained.

This mood creeped on me, when the exception error did not disappear even after I
commented out all my newest additions that I felt might have brought this
unfortunate twist of electrones.

Thanks
Meltem

Post a reply to this message

Chris had a lot of good advice to find the crash area.
I want to add just one thing. I had a crash like yours and it turn out 
that I left off the '#' in front of an 'if' or 'declare' or 'read' 
statement. I forget witch.
  The reason Pov didn't just give and syntic error, I believe and I 
could be worng is that the error happened in an included file.

Post a reply to this message

Leroy <lrw### [at] joplincom> wrote:

Well, I started implementing Chris's idea in reverse order, that is made a copy
of the non-working scene code and proceeded to commenting out blocks that
looked suspicious until I got a working version; I had too many nested Unions,
I reduced some.  added some more debugging statements.. and valla, I discovered
what I managed to do.

I feel very embarrassed.  Well it answered one question in my mind.  I was
wondering if POV-RAY could handle recursion.  Well, a macro definitely could
call itself.  That is the good news ;).

It appeared I accidentally pasted a call to self in my ever growing
Move_Humanoid macro.  The poor thing kept calling itself over and over again
without any recursion termination criteria.  Until POV_RAY decided to catch the
poor me, and threw an exception error.  Did I manage to get POV-RAY run out of
my 2GB of RAM?  Who knows?

Thanks Leroy.  Forgetting the pound sign, and POV-RAY not catching it.  That is
really good to know.  As my fingers type they refuse to add the # sign at
times, especially to language constructs that are common to so many other
languages. It will be an easy trap for me to fall into.

Well, now that I am beyond one hurdle I am caught by another trap which leaves
me scratching my head.  Now what, what might have done to bring this on?  The
error messages unfortunately are not helping me to identify the cause of the
problems I ran into.  Each time I ran into a problem I go around circles for
days. Please tell me if the following error message rings any bells for you?

   Parse Error: Expected String expression, object found instead.

here is the section including the line POV-RAY highlights, I marked it by >>>
<<<< arrows for your reference..

  ...  snip lots of lines before

   #if ( !VZero( AVAR[PCFlag][HumanoidRoot_Ind] ) )
      Rotate_Around_Trans( AVAR[PCFlag][HumanoidRoot_Ind], JOC_L_Subtalar ) //
+Joint_Radius_Heal
      #debug concat( "Rotating about HumanoidRoot by ", vstr( 3,
AVAR[PCFlag][HumanoidRoot_Ind], ", ", 3, 0 ) )
   #end

   texture { Silver_Texture }
   };

   #declare Human_Trans =
      transform {
         scale 1.5
         translate -1.0*y
   };

>>> object{ <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
      Humanoid
      transform { Human_Trans }
   }

#end // macro move_Humanoid

  ... snip lots of lines after

I scanned the code for all my strings to make sure all had openning and clossing
quotes.  They had.  Thanks to POV-RAY editor, they get color coded anyways when
they mismatch.   SOOO, what the heck might have done this time.
The higlighted object statement is the statement that was supposed to render
Humanoid in his/her new pose.

There I go, one step forward, two steps back.


> Chris had a lot of good advice to find the crash area.
> I want to add just one thing. I had a crash like yours and it turn out
> that I left off the '#' in front of an 'if' or 'declare' or 'read'
> statement. I forget witch.
>   The reason Pov didn't just give and syntic error, I believe and I
> could be worng is that the error happened in an included file.

Post a reply to this message

"melo" <mel### [at] coxnet> wrote in message 
news:web.47c1f643e2d08be6587ef5e20@news.povray.org...
> I had too many nested Unions,
> I reduced some.  added some more debugging statements.. and valla, I 
> discovered
> what I managed to do.

Phew!. Well I'm glad you've got over that one :-)

>
> Well, now that I am beyond one hurdle I am caught by another trap which 
> leaves
> me scratching my head.   ... snip ...
>
>   Parse Error: Expected String expression, object found instead.
>
> here is the section including the line POV-RAY highlights, I marked it by 
>  >>>
> <<<< arrows for your reference..
>
>  ...  snip lots of lines before
>
>   #if ( !VZero( AVAR[PCFlag][HumanoidRoot_Ind] ) )
>      Rotate_Around_Trans( AVAR[PCFlag][HumanoidRoot_Ind], JOC_L_Subtalar ) 
> //
> +Joint_Radius_Heal
>      #debug concat( "Rotating about HumanoidRoot by ", vstr( 3,
> AVAR[PCFlag][HumanoidRoot_Ind], ", ", 3, 0 ) )
>   #end
>
>   texture { Silver_Texture }
>   };
>
>   #declare Human_Trans =
>      transform {
>         scale 1.5
>         translate -1.0*y
>   };
>
>>>> object{ <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>      Humanoid
>      transform { Human_Trans }
>   }
>
> #end // macro move_Humanoid
>
>  ... snip lots of lines after
>

The cause is not clear to me from just this snippet, but I think there's 
probably something awry with the data type you're returning from the macro. 
The line that it complains about is where you're returning an object from 
the macro. My guess is that there's something being returned before that to 
make it think that the returned data type should be a string. Alternatively 
it could be the context in which the macro is called that could make it 
expect a string to be returned.

Regards,
Chris B.

Post a reply to this message

"Chris B" <nom### [at] nomailcom> wrote:
> "melo" <mel### [at] coxnet> wrote in message
> news:web.47c1f643e2d08be6587ef5e20@news.povray.org...
> > I had too many nested Unions,
> > I reduced some.  added some more debugging statements.. and valla, I
> > discovered
> > what I managed to do.
>
> Phew!. Well I'm glad you've got over that one :-)

Thanks Chris.  I managed to get myself out of one hole I dug, just to find
myself in deeper holes, more exception errors.  Those I got to watch my fingers
as I use short cut keys for cuts and pastes.

I wonder if I am too conditioned with having worked with C and SAS for so many
years that when I make a mistake it takes me a whole lot longer to find the
cause, for one, the error message when displayed seems to have nothing to do
with the error being reported, or nothing to do with the line that had caused
the errot.

Who knows my ability to deduct causes of errors have been hurt more than I am
willing to admit due to my injuries.

Anyhow, the error I mentioned caused me to waste yet another week, and it had
something to do with some forgotten comma in one of my debug statements which
came dozens and dozens of lines before.  Sighhh!
>
> >
> > Well, now that I am beyond one hurdle I am caught by another trap which
> > leaves
> > me scratching my head.   ... snip ...
> >
> >   Parse Error: Expected String expression, object found instead.
> >
> > here is the section including the line POV-RAY highlights, I marked it by
> >  >>>
> > <<<< arrows for your reference..
> >
> >  ...  snip lots of lines before
> >
> >   #if ( !VZero( AVAR[PCFlag][HumanoidRoot_Ind] ) )
> >      Rotate_Around_Trans( AVAR[PCFlag][HumanoidRoot_Ind], JOC_L_Subtalar )
> > //
> > +Joint_Radius_Heal
> >      #debug concat( "Rotating about HumanoidRoot by ", vstr( 3,
> > AVAR[PCFlag][HumanoidRoot_Ind], ", ", 3, 0 ) )
> >   #end
> >
> >   texture { Silver_Texture }
> >   };
> >
> >   #declare Human_Trans =
> >      transform {
> >         scale 1.5
> >         translate -1.0*y
> >   };
> >
> >>>> object{ <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> >      Humanoid
> >      transform { Human_Trans }
> >   }
> >
> > #end // macro move_Humanoid
> >
> >  ... snip lots of lines after
> >
>
> The cause is not clear to me from just this snippet, but I think there's
> probably something awry with the data type you're returning from the macro.
> The line that it complains about is where you're returning an object from
> the macro. My guess is that there's something being returned before that to
> make it think that the returned data type should be a string. Alternatively
> it could be the context in which the macro is called that could make it
> expect a string to be returned.
>
> Regards,
> Chris B.

Post a reply to this message