POV-Ray : Newsgroups : povray.bugreports : alpha.10064268 freezes Server Time
29 Mar 2024 04:08:06 EDT (-0400)
  alpha.10064268 freezes (Message 1 to 10 of 18)  
Goto Latest 10 Messages Next 8 Messages >>>
From: jr
Subject: alpha.10064268 freezes
Date: 2 Dec 2019 12:20:00
Message: <web.5de5468fe9831fc7feeb22ff0@news.povray.org>
hi,

using alpha.10064268, dies with:

  Fatal error in renderer: Frontend halted render.

I'm trying to add a logo/decal to an Android model (version 4, POVCollection
#590224).

the code is taken from 'androidrobot_posed.pov', with minor modification, and
the error occurs when the pigment is uncommented.

when I reverse the order of the pigments, POV-Ray runs ok, but, of course, that
is no help.


regards, jr.


-----<snip>-----
#declare droid_ = union {
  object {

AndroidRobot_Posed(no,HeadRotate,LArmRotate,RArmRotate,LLegRotate,RLegRotate)
    pigment {ANDROIDROBOT_C_COLOR}
//    pigment {image_map {png "plate.png" once} scale .2}
    finish {
      reflection {.5 metallic}
      diffuse DIFFUSE * .5
      ambient C_AMBIENCE * .5
      specular 1.788 metallic
      roughness .05
      brilliance 1.857
    }
  }
  union {
    object {UserDefinedEye}
    object {UserDefinedEye scale <1,1,-1>}
    AndroidRobot_Head_x (HeadRotate)
  }
  rotate 90 * y
  translate -ANDROIDROBOT_V_BASE
};

object {droid_}


Post a reply to this message

From: jr
Subject: Re: alpha.10064268 freezes
Date: 3 Dec 2019 04:55:00
Message: <web.5de630ae48df159ffeeb22ff0@news.povray.org>
"jr" <cre### [at] gmailcom> wrote:
> using alpha.10064268, dies with:
>
>   Fatal error in renderer: Frontend halted render.
>
> I'm trying to add a logo/decal to an Android model (version 4, POVCollection
> #590224).
>
> the code is taken from 'androidrobot_posed.pov', with minor modification, and
> the error occurs when the pigment is uncommented.
> when I reverse the order of the pigments, POV-Ray runs ok, but, of course, that
> is no help.
> -----<snip>-----
> #declare droid_ = union {
>   object {
>
> AndroidRobot_Posed(no,HeadRotate,LArmRotate,RArmRotate,LLegRotate,RLegRotate)
>     pigment {ANDROIDROBOT_C_COLOR}
> //    pigment {image_map {png "plate.png" once} scale .2}
>     finish {
>       reflection {.5 metallic}
>       diffuse DIFFUSE * .5
>       ambient C_AMBIENCE * .5
>       specular 1.788 metallic
>       roughness .05
>       brilliance 1.857
>     }
>   }
>   union {
>     object {UserDefinedEye}
>     object {UserDefinedEye scale <1,1,-1>}
>     AndroidRobot_Head_x (HeadRotate)
>   }
>   rotate 90 * y
>   translate -ANDROIDROBOT_V_BASE
> };
>
> object {droid_}

some more information (fwiw).  same error in alpha.9945627.  without the 'once'
keyword the scene renders (but not useful since the decal repeats).


regards, jr.


Post a reply to this message

From: William F Pokorny
Subject: Re: alpha.10064268 freezes
Date: 3 Dec 2019 07:30:19
Message: <5de6555b$1@news.povray.org>
On 12/3/19 4:53 AM, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
...
> 
> some more information (fwiw).  same error in alpha.9945627.  without the 'once'
> keyword the scene renders (but not useful since the decal repeats).
> 

I've not much hobby time at the moment and what I have is going toward 
other stuff. As always, having a small-ish complete scene which shows 
the problem would be a help to whomever debugs.

- What happens if you leave 'once' but scale up enough to be sure the 
robot is covered by the image_map-once? Don't worry about how it would 
look.

- What happens with v3.7? The image_map alpha channel / transparency 
handling was re-worked in v3.8 IIRC.

- Have a vague recollection of another image_map alpha channel / 
transparency related issue in v3.8 too for which I don't think there was 
a resolution. I don't remember details at the moment. If so, we should 
find that thread and add a link here to it and visa versa.

Bill P.


Post a reply to this message

From: jr
Subject: Re: alpha.10064268 freezes
Date: 3 Dec 2019 08:40:00
Message: <web.5de6653248df159ffeeb22ff0@news.povray.org>
hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/3/19 4:53 AM, jr wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> ...
> > some more information (fwiw).  same error in alpha.9945627.  without the 'once'
> > keyword the scene renders (but not useful since the decal repeats).
>
> I've not much hobby time at the moment and what I have is going toward
> other stuff. As always, having a small-ish complete scene which shows
> the problem would be a help to whomever debugs.

using the scene from the collection zip verbatim, except for adding an
equivalent pigment, does illustrate the issue.

> - What happens if you leave 'once' but scale up enough to be sure the
> robot is covered by the image_map-once? Don't worry about how it would
> look.

no difference in the 3.8 versions.  3.7.1-alpha.8656843 - v interesting.  using
the pigment as shown, I get the single decal but the other texture has turned
transparent and the droid looks like a weird mix of glass and (white) emissive
media.  :-)

> - What happens with v3.7? The image_map alpha channel / transparency
> handling was re-worked in v3.8 IIRC.
>
> - Have a vague recollection of another image_map alpha channel /
> transparency related issue in v3.8 too for which I don't think there was
> a resolution. I don't remember details at the moment. If so, we should
> find that thread and add a link here to it and visa versa.

the image is 8-bit rgb, no alpha, in case it matters.


regards, jr.


Post a reply to this message

From: William F Pokorny
Subject: Re: alpha.10064268 freezes
Date: 3 Dec 2019 10:17:55
Message: <5de67ca3$1@news.povray.org>
On 12/3/19 8:37 AM, jr wrote:
> hi,
> 
...
> 
Alright... So, all you did to get the crash/freeze was add a second 
pigment { image_map {...}} after the first pigment {} leaving both 
un-commented when you run the object collection's most current android 
robot scene?

If true, this, I think, amounts to overlapped textures and it's why I 
assumed your image_map would have transparency everywhere except the 
'decal.' Maybe the lack of any transparency/alpha channel is tangled in 
the reason for the crash? That you are sometimes getting stuff to sort 
of work puzzles me too.

And apologies I wasn't clear I was interested in v3.70 (stable) over 
anything after, though whatever you see with the v3.71 release is 
interesting and perhaps useful to know too.

And my brain cells being earlier stirred have since remembered the other 
image_map issue had something to do - I think - with adding transparency 
via the 'transmit' keyword. Head also popped the question of whether the 
fix for Warren's macro issue of this past April made it into the master 
branch. I still have my local branch fix, so maybe not? I usually delete 
my local fixes once things fixed in master.

Anyway, very likely more than a month before I'd have the time to look 
at this in any depth.

Bill P.


Post a reply to this message

From: jr
Subject: Re: alpha.10064268 freezes
Date: 3 Dec 2019 12:10:00
Message: <web.5de6964548df159ffeeb22ff0@news.povray.org>
hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/3/19 8:37 AM, jr wrote:
> ...
> Alright... So, all you did to get the crash/freeze was add a second
> pigment { image_map {...}} after the first pigment {} leaving both
> un-commented when you run the object collection's most current android
> robot scene?

correct.

> If true, this, I think, amounts to overlapped textures and it's why I
> assumed your image_map would have transparency everywhere except the
> 'decal.' Maybe the lack of any transparency/alpha channel is tangled in
> the reason for the crash? That you are sometimes getting stuff to sort
> of work puzzles me too.
>
> And apologies I wasn't clear I was interested in v3.70 (stable) over
> anything after, though whatever you see with the v3.71 release is
> interesting and perhaps useful to know too.

no problem, version 3.7.0.8 too hangs (pigment as shown).

> And my brain cells being earlier stirred have since remembered the other
> image_map issue had something to do - I think - with adding transparency
> via the 'transmit' keyword. Head also popped the question of whether the
> fix for Warren's macro issue of this past April made it into the master
> branch. I still have my local branch fix, so maybe not? I usually delete
> my local fixes once things fixed in master.
>
> Anyway, very likely more than a month before I'd have the time to look
> at this in any depth.

also no problem (for me).  out of interest, what advantages does your fork have
wrt media artefacts, media in general?


regards, jr.


Post a reply to this message

From: jr
Subject: Re: alpha.10064268 freezes
Date: 4 Dec 2019 06:10:01
Message: <web.5de792ee48df159ffeeb22ff0@news.povray.org>
hi,

> William F Pokorny <ano### [at] anonymousorg> wrote:
> > On 12/3/19 8:37 AM, jr wrote:
> > ...
> > ...
> > If true, this, I think, amounts to overlapped textures and it's why I
> > assumed your image_map would have transparency everywhere except the
> > 'decal.' Maybe the lack of any transparency/alpha channel is tangled in
> > the reason for the crash?

re-rendered the name plate ("decal") with '+ua', appears to make no difference.


regards, jr.


Post a reply to this message

From: William F Pokorny
Subject: Re: alpha.10064268 freezes
Date: 4 Dec 2019 08:47:57
Message: <5de7b90d$1@news.povray.org>
On 12/3/19 12:07 PM, jr wrote:
> 
...
>>
>> Anyway, very likely more than a month before I'd have the time to look
>> at this in any depth.
> 
> also no problem (for me).  out of interest, what advantages does your fork have
> wrt media artefacts, media in general?
> 
...
> 

:-) Simple question with a non-simple answer...

I've never published a merged branch of all the branches I run as 'povr' 
- partly because what I run contains more branches / differences to 
master than those I've published to github. Also 'povr' is meant to be a 
temporal thing based on the current master branch into which continually 
re-based to master branches are merged.

That said, my published solver branch addresses many artifacts media and 
otherwise - and extends the range over which containers work for media. 
This work though is limited to shapes using the common solvers.

There is a published branch addressing the photon media deposit banding. 
I assume that was some debugging left in as I see no reason to introduce 
banding except to get some visual feedback of the sampling periodicity 
while developing code.

There is a published branch for one version of a change published for 
jitter and adaptive media 3 which helps scene-performance up to 5%, if 
your scene is media dominated and you're not using media jitter - and 
one shouldn't with media method 3 unless they want noise.

Non-published branches...

I have another version of the media 3 jitter changes which is faster 
still, but it's also more intrusive code wise and so more difficult to 
re-base. I didn't use/re-base this branch in my last create a 'povr' 
pass.

Suppose some of the recent pattern and wave modifier work touches media 
too and issues fixed more likely to show up with media given the 
containing shapes like isosurfaces, but also the sampling periodicity is 
more likely to numerically land badly. With that last though, the 
sampling, if set deep enough, probably mostly hides any wave modifier 
issues.

Aside: At one time I naively thought there was an issue or two with 
media, but a year plus back mentally carrying 8-10 media media artifact 
causes. It's a bunch of stuff - and media turns out to be a great way to 
test for underlying problems! Though, if you asked me in this moment to 
list them all, I'd be hard pressed to do it. Not worked specifically on 
media in a while. For me, newer work tends to push the old out of my 
head - given the lack of space, the near continual wind storm and 
general clutter up there... :-)

Oh, I never got to testing code, but I started a local branch supporting 
a second emission specific media absorption specification/control. In a 
scene Norbert posted a year or more back based on Gilles Tran's cloud 
technique using scattering, emission and absorption together with media 
there was color clipping due how the emission was cleverly used and this 
demonstrated that media emission needs it's own media, 
emission-absorption control(1).

Lastly, something not fixed in any code of which I'm aware - I tried and 
failed for a fix. One needs to be sure light sources are outside any 
media container, if you want all the media related controls/attenuation 
to best work(2). True even if you have to cut a small void in the media 
container around your lights to get this set up. See:

http://news.povray.org/povray.binaries.images/thread/%3C5a842989%241%40news.povray.org%3E/

Bill P.

(1) Or - maybe - should always internally absorb at a color matching the 
emission color. This, I think, would align OK with physical behavior for 
florescent media, but it would be more limiting and it would change the 
look of current scenes with emissive media.

(2) I've since stumbled across a post from back in the 2000s where 
someone else (Bruno Cabasson?) had discovered this issue too suggesting 
the same work-around. IIRC even with the workaround we are left not 
being able to turn media attenuation off in containers.


Post a reply to this message

From: jr
Subject: Re: alpha.10064268 freezes
Date: 4 Dec 2019 12:15:01
Message: <web.5de7e87a48df159ffeeb22ff0@news.povray.org>
hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/3/19 12:07 PM, jr wrote:
> >
> ...
> >>
> >> Anyway, very likely more than a month before I'd have the time to look
> >> at this in any depth.
> >
> > also no problem (for me).  out of interest, what advantages does your fork have
> > wrt media artefacts, media in general?
> >
> ...
> >
>
> :-) Simple question with a non-simple answer...
>
> I've never published a merged branch of all the branches I run as 'povr'
> - partly because what I run contains more branches / differences to
> master than those I've published to github. Also 'povr' is meant to be a
> temporal thing based on the current master branch into which continually
> re-based to master branches are merged.
>
> That said, my published solver branch addresses many artifacts media and
> otherwise - and extends the range over which containers work for media.
> This work though is limited to shapes using the common solvers.

sounds like a good starting point.  artefacts seem to appear when I use
interpolation, so interested in the difference that code will make.  what is the
build/install procedure?  (sorry to use up yr time, mostly familiar with the
usual '.tar's, not "pulling" (+ merging?))

> ...
>
http://news.povray.org/povray.binaries.images/thread/%3C5a842989%241%40news.povray.org%3E/
> ...

thank you for this link.  bookmarked.  much to take in.


regards, jr.


Post a reply to this message

From: William F Pokorny
Subject: Re: alpha.10064268 freezes
Date: 5 Dec 2019 06:40:23
Message: <5de8eca7$1@news.povray.org>
On 12/4/19 12:10 PM, jr wrote:
...
>>
>> I've never published a merged branch of all the branches I run as 'povr'
>> - partly because what I run contains more branches / differences to
>> master than those I've published to github. Also 'povr' is meant to be a
>> temporal thing based on the current master branch into which continually
>> re-based to master branches are merged.
>>
>> That said, my published solver branch addresses many artifacts media and
>> otherwise - and extends the range over which containers work for media.
>> This work though is limited to shapes using the common solvers.
> 
> sounds like a good starting point.  artefacts seem to appear when I use
> interpolation, so interested in the difference that code will make.  what is the
> build/install procedure?  (sorry to use up yr time, mostly familiar with the
> usual '.tar's, not "pulling" (+ merging?))
> 
...
> 

Interpolation with respect to media... Not completely sure what you 
mean, but, there are directions on my wiki page at:

http://wiki.povray.org/content/User:Wfpokorny

Though the branches available are out of date on it(1). You can get a 
current list of published branches on github. A graph/network view be 
seen by going to:

https://github.com/wfpokorny/povray/network

and you can also see a list using the branch switching list-pick button 
on the page:

https://github.com/wfpokorny/povray

You have to be in a position to build your own *nix versions of POV-Ray 
If you're not, well, what I have out there today isn't going to be 
useful to you.

You need to have git installed and to have a local clone of povray to 
follow the pick and chose branches to merge into your personal version 
of POV-Ray method on the wiki. If you are compiling via download and 
just want to try a single branch, you can switch to it, download the 
branch to your machine & compile normally.

Bill P.

(1) - The inability to add new links to discussion and documentation 
made the wiki much less useful - and I've more or less just been letting 
my pages sit as is for long time.


Post a reply to this message

Goto Latest 10 Messages Next 8 Messages >>>

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