|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/4/19 12:10 PM, jr wrote:
> ...
> > 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:
in a 'density {}' loaded from df3.
> 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.
right, had a quick look at your wiki page. so generally, first git clone
POV-Ray master, then the checkout/pull sequence near bottom (with name of
branch)? I found an ebook/pdf (by S Chacon), am resigned to having to read it.
...in the coming days. :-)
> ...
> (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.
I've been toying with the idea of trying to get a wiki page, for the df3-tools
mainly. but the site seems quite static, not really encouraging contribution (I
feel).
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/6/19 10:59 AM, jr wrote:
...
>> Interpolation with respect to media... Not completely sure what you
>> mean, but, there are directions on my wiki page at:
>
> in a 'density {}' loaded from df3.
>
Ah, OK. Depending on how you're using the df3 in media it might be worth
giving my wiki page:
http://wiki.povray.org/content/User:Wfpokorny/DensityFile
a read. There are issues with the df3 interpolation which can make using
it tricky.
> right, had a quick look at your wiki page. so generally, first git clone
> POV-Ray master, then the checkout/pull sequence near bottom (with name of
> branch)? I found an ebook/pdf (by S Chacon), am resigned to having to read it.
> ...in the coming days. :-)
>
Yeah, you got the idea. Intent was to set it up so folks building
POV-Ray themselves could roll their own derivatives of POV-Ray chosing
what branches they want to merge into the current master for their
version. Might be they have three branches of their own, might want to
use 2 of mine, 3 of SuperCoder12StrandedOnMarsEatingPotatoes etc.
>
>> ...
>> (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.
>
> I've been toying with the idea of trying to get a wiki page, for the df3-tools
> mainly. but the site seems quite static, not really encouraging contribution (I
> feel).
>
...
Don't have time for real hobby coding this morning before being tied up
for some days. Why not some rambling thoughts about the wiki...
---
Over the last month or more, Maurice has been substantially improving the
http://wiki.povray.org/content/HowTo:Use_POV-Ray_with_Blender
page which can be found off of the
http://wiki.povray.org/content/HowTo:Contents
page. This evidence not everything is stale on the wiki. Folks do make
updates.
But, I agree the wiki is kinda stale. Writing wikis not too bad for
simple one page an image two sorts of things. For more, I find it
cumbersome.
In addition to trouble creating links to other pages:
To write more than one page, as with the density file pattern stuff, I
found the coding and previewing via the web cumbersome. I ended up
using a linux tool called Zim to first code, review, organize and refine
the pages locally(1). The wiki encoding though was slightly different
than that of POV-Ray's wiki implementation. It was a pain to transfer
everything to the POV-Ray wiki(2). I got some of this wrong due cut and
pasting, formatting differences, etc.
(1) - Zim a neat tool. Though it's spell checker broke for time while I
was using it due a Ubuntu release...
(2) - Now that everything on the POV-Ray wiki, major revisions can no
longer easily be done locally within Zim...
I found myself revising / changing images, but there is no way to delete
old ones yourself, so you end up being overly careful using images. With
some I replaced the image with much simpler "delete me" ones hoping some
admin would see this and do it. Suppose behavior might be due a wiki
being able to back up to old versions, but if I'm creating the first
release of some documentation I don't want all the old versions to exist
but just the 'released' one.
Once personal wiki's are up. They are sitting out there not very
visible. Is there even a page which lists user wikis? Maintained pages
sit on a wiki where lots of stuff has fallen out of date and needs
revision. People see that general staleness and shy away both from
reading the wiki entries - and from updating old ones.
Normal users cannot update the stuff they don't own. A few super users
can - spam concerns again I guess. This forces normal users into a "can
I get the attention of a super user;" then into a sort of type this,
then this, kinda of loop with them; on seeing some wrong or wanting some
change. This loop too is cumbersome. It gets to there being nobody being
paid to stay on top of the wiki and documentation always. Someone always
finding and refining issues as their job. We have similar issues with
the core documentation/build and release systems too as mentioned
elsewhere.
With user wikis there is always the problem that we might not completely
understand what we are trying to document ;-). What to do when well
intention-ed, but wrong pages get posted? Wikipedia has this problem
too. What they've done with subjects like Math is gather/(pay?) experts
as arbiters for what's written - much better end result, but still you
occasionally run across mistakes and biases in what's written.
We have a single physical web site. When it goes down or my local
network connection does, I'd like to have local copy of the wiki,
library and the newsgroup postings as I do for the documentation. Or at
least have snapshots of these available on the cloud - github or
wherever.
A few expert folk maintain their own web sites for what might go on a
wiki, but that an investment. Plus, knowing where all these web sites
are today means maintaining a list of links to them yourself.
Back to the Zim tool, its github wiki page at:
https://github.com/jaap-karssenberg/zim-wiki/wiki
is an interesting model for putting a wiki on github. The wiki link on
the Zim web site links to the github wiki above.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/6/19 10:59 AM, jr wrote:
> ...
> >> Interpolation with respect to media... Not completely sure what you
> >> mean, but, there are directions on my wiki page at:
> >
> > in a 'density {}' loaded from df3.
> >
> Ah, OK. Depending on how you're using the df3 in media it might be worth
> giving my wiki page: ,,,
> a read. There are issues with the df3 interpolation which can make using
> it tricky.
slightly confused by the interpolation options, they're not "regular" POV-Ray?
which of the 'playpen' branches deals with those?
> > right, had a quick look at your wiki page. so generally, first git clone
> > POV-Ray master, then the checkout/pull sequence near bottom (with name of
> > branch)? I found an ebook/pdf (by S Chacon), am resigned to having to read it.
> > ...in the coming days. :-)
>
> Yeah, you got the idea. Intent was to set it up so folks building
> POV-Ray themselves could roll their own derivatives of POV-Ray chosing
> what branches they want to merge into the current master for their
> version. Might be they have three branches of their own, might want to
> use 2 of mine, 3 of SuperCoder12StrandedOnMarsEatingPotatoes etc.
after some thought, the 'Density File Pattern Updates' + 'Non-portable 32 bit
DF3 write capability' + perhaps 'Both image_map and pigment_map support in
density block'. would that combination "play nice"?
> >> ...
> >> (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.
> >
> > I've been toying with the idea of trying to get a wiki page, for the df3-tools
> > mainly. but the site seems quite static, not really encouraging contribution (I
> > feel).
> >
> ...
> (1) - Zim a neat tool. Though it's spell checker broke for time while I
> was using it due a Ubuntu release...
thanks. not an immediate need (for me), have O'Reilly's "MediaWiki", but have
some time ago switched to using the 'fossil' in-built wiki for most stuff.
> ...
> Once personal wiki's are up. They are sitting out there not very
> visible. Is there even a page which lists user wikis?
know what you mean. although they all have "sitemap"s, few provide table of
contents. (self-defeating, imo)
> ...
> With user wikis there is always the problem that we might not completely
> understand what we are trying to document ;-). What to do when well
> intention-ed, but wrong pages get posted?
isn't that what the "discussion" page is there for?
inadvertent errors would be corrected, I'm (fairly) sure.
> ...
> We have a single physical web site. When it goes down or my local
> network connection does, I'd like to have local copy of the wiki,
> library and the newsgroup postings as I do for the documentation. Or at
> least have snapshots of these available on the cloud - github or
> wherever.
> A few expert folk maintain their own web sites for what might go on a
> wiki, but that an investment. Plus, knowing where all these web sites
> are today means maintaining a list of links to them yourself.
it would be nice to have mirror or two. (personally, I think that if "the gods"
put the content on a DVD (or two) and offered those for sale, I'd buy. and
help maintain .. POV-Ray, I would. (and am quite certain that I'm not alone in
that))
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|