POV-Ray : Newsgroups : povray.binaries.images : Complex transformations: 3.6 vs. 3.7 Server Time
31 Oct 2024 19:04:22 EDT (-0400)
  Complex transformations: 3.6 vs. 3.7 (Message 1 to 7 of 7)  
From: gregjohn
Subject: Complex transformations: 3.6 vs. 3.7
Date: 22 Jan 2015 12:25:01
Message: <web.54c1322726f8b305a9b6c9220@news.povray.org>
Please find enclosed two renderings of the exact same scene file, one with
povray 3.7.0 official, the other with 3.6.  The scene file contains several
characters. Some are very complex blobs (whereby individual components undergo
multiple, compound transformatios), and have a complex texture applied to them.
The "wooden guy" (3rd in back row) is however nothing but simple spheres
(undergoing the same complex transformations).

Note that the people are all missing with 3.7!

If there were some new rule-of-thumb that would allow me to quickly fix the
scene, please let me know.  Could it be that povray is "not allowing" compound
transformations?

Here are just a few lines of the (possibly offending) code, which explain what I
mean by compound transformations:


//----------START CODE SNIPPET
>>

#declare lumbartrans= transform{rotate lumbarang translate hippvt +hiplift }

#declare ribtrans=    transform{rotate ribang    translate ribpvt-hippvt
transform{lumbartrans}}
#declare rclavtrans=  transform{rotate rclavang  translate rclaviclepvt-ribpvt
transform{ribtrans}}
#declare lclavtrans=  transform{rotate lclavang  translate lclaviclepvt-ribpvt
transform{ribtrans}}


#declare necktrans=transform{rotate neckang translate neckendpt-ribpvt
transform{ribtrans}}
#declare headtrans=transform{ scale 1.0 rotate headang translate
headpvt-neckendpt transform{necktrans}}
#declare hiptrans= transform{rotate hipang translate hippvt+hiplift}
#declare jawtrans= transform{rotate jawrot translate jawpvt-headpvt
transform{headtrans}}

// ----------END CODE SNIPPET


Post a reply to this message


Attachments:
Download 'alldance06_2015_370rc71.png' (20 KB)

Preview of image 'alldance06_2015_370rc71.png'
alldance06_2015_370rc71.png


 

From: gregjohn
Subject: Re: Complex transformations: 3.6 vs. 3.7
Date: 22 Jan 2015 12:30:01
Message: <web.54c132c7c5bc37d6a9b6c9220@news.povray.org>
And then 3.6 rendering:

I would note that changing the "version" in the code on a 3.7 box doesn't bring
my characters back to life.  :(


Post a reply to this message


Attachments:
Download 'alldance06_2015_36.png' (278 KB)

Preview of image 'alldance06_2015_36.png'
alldance06_2015_36.png


 

From: gregjohn
Subject: Re: Complex transformations: 3.6 vs. 3.7
Date: 22 Jan 2015 12:35:01
Message: <web.54c133b3c5bc37d6a9b6c9220@news.povray.org>
3.6


Post a reply to this message


Attachments:
Download 'alldance06_2015_36.png' (278 KB)

Preview of image 'alldance06_2015_36.png'
alldance06_2015_36.png


 

From: clipka
Subject: Re: Complex transformations: 3.6 vs. 3.7
Date: 22 Jan 2015 15:18:28
Message: <54c15b14$1@news.povray.org>
Am 22.01.2015 um 18:23 schrieb gregjohn:

> If there were some new rule-of-thumb that would allow me to quickly fix the
> scene, please let me know.  Could it be that povray is "not allowing" compound
> transformations?

There is no intentional change to the behaviour of compound 
transformations whatsoever, meaning that such constructs /should/ work 
exactly the same as in 3.6. Also, there have been no known issues with 
them so far, and therefore obviously no known solution to your problem 
either.

To investigate this matter, we'd need a complete scene to look at. Given 
that the "wooden guy" is just spheres and therefore excludes blobs as a 
potential source of problems, that's the one I'd like to work with.

If you are reluctant to post a complete scene in the newsgroups, please 
send it to christoph, at lipka-koeln, dot de.

Given that IIRC you posted about this before, I presume you were 
unsuccessful in trimming down the scene to something more simple, so I 
refrain from asking you to try and do just that.


Post a reply to this message

From: gregjohn
Subject: Re: Complex transformations: 3.6 vs. 3.7
Date: 22 Jan 2015 22:40:01
Message: <web.54c1c245c5bc37d6d44a22e40@news.povray.org>
I found the offending code:

#declare mouthsplines=  //
        spline {
        linear_spline

        #declare n=0;
        #while(n<numchars)

        voiceframes[n]/final_frame, moutharray[ asc(substr(voicechars,n+1,1))],
        #declare n=n+1;
        #end
}



and the weird thing is that with Kff=1  dividing something by final_frame gives
a divide by zero error (dividing by one??).


In povray 3.6, it just gave an error message, but somehow the scene rendered
correctly, maybe almost as if the final_frame were actually counted as "1".


In povray 3.7, there is no error message, but it's like povray just decided to
delete the object associated with the error.  And the association seemed to
destroy all transforms associated with the object.

I just rendered a few scenes in 3.7 with kff=1: I get people with shoes "Left
Behind".
With kff=2, I get two frames with my family intact.


Post a reply to this message

From: clipka
Subject: Re: Complex transformations: 3.6 vs. 3.7
Date: 23 Jan 2015 02:18:36
Message: <54c1f5cc@news.povray.org>
Am 23.01.2015 um 04:38 schrieb gregjohn:
> I found the offending code:
>
> #declare mouthsplines=  //
>          spline {
>          linear_spline
>
>          #declare n=0;
>          #while(n<numchars)
>
>          voiceframes[n]/final_frame, moutharray[ asc(substr(voicechars,n+1,1))],
>          #declare n=n+1;
>          #end
> }
>
> and the weird thing is that with Kff=1  dividing something by final_frame gives
> a divide by zero error (dividing by one??).

IIRC setting initial and final frame to the same value disables the 
animation feature entirely; apparently this also sets final_frame to 0.

> In povray 3.6, it just gave an error message, but somehow the scene rendered
> correctly, maybe almost as if the final_frame were actually counted as "1".

What's the error message you get with 3.6? Divide by zero?

> In povray 3.7, there is no error message, but it's like povray just decided to
> delete the object associated with the error.  And the association seemed to
> destroy all transforms associated with the object.

The object most certainly isn't deleted; it's just translated to infinity...

> I just rendered a few scenes in 3.7 with kff=1: I get people with shoes "Left
> Behind".
> With kff=2, I get two frames with my family intact.

I suggest dividing by (final_frame-initial_frame+1).


Post a reply to this message

From: Alain
Subject: Re: Complex transformations: 3.6 vs. 3.7
Date: 24 Jan 2015 22:03:41
Message: <54c45d0d$1@news.povray.org>

> Am 23.01.2015 um 04:38 schrieb gregjohn:
>> I found the offending code:
>>
>> #declare mouthsplines=  //
>>          spline {
>>          linear_spline
>>
>>          #declare n=0;
>>          #while(n<numchars)
>>
>>          voiceframes[n]/final_frame, moutharray[
>> asc(substr(voicechars,n+1,1))],
>>          #declare n=n+1;
>>          #end
>> }
>>
>> and the weird thing is that with Kff=1  dividing something by
>> final_frame gives
>> a divide by zero error (dividing by one??).
>
> IIRC setting initial and final frame to the same value disables the
> animation feature entirely; apparently this also sets final_frame to 0.
>
>> In povray 3.6, it just gave an error message, but somehow the scene
>> rendered
>> correctly, maybe almost as if the final_frame were actually counted as
>> "1".
>
> What's the error message you get with 3.6? Divide by zero?
>
>> In povray 3.7, there is no error message, but it's like povray just
>> decided to
>> delete the object associated with the error.  And the association
>> seemed to
>> destroy all transforms associated with the object.
>
> The object most certainly isn't deleted; it's just translated to
> infinity...
>
>> I just rendered a few scenes in 3.7 with kff=1: I get people with
>> shoes "Left
>> Behind".
>> With kff=2, I get two frames with my family intact.
>
> I suggest dividing by (final_frame-initial_frame+1).
>

In my experience, when the animation is disabled, all animation related 
variables are set to zero: clock, initial_frame, final_frame, 
frame_number, ...


Alain


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.