"cbpypov" <nomail@nomail> wrote:
> Hey Bald Eagle,
>
> first, it's funny you discovered the time zone thing ... actually there is
> really
> that 1 year + difference between Germany and New Hampshire. But it is a secret,
> so I changed the date to 2017 for now ;)

When I was in Berlin in 1987, it _seemed_ like it took 7-8 hours, but I fell
asleep, so maybe I just pulled a Rip Van Winkle.


> I do not agree (maybe it's my fault, sorry): I want to use my own color map, so
> how should I do this without individual RGB?

Nope, I was hasty - I read right through the different filenames.


> > How long does it take to render this now?
> Actually I have access to, say a server with
> 64
> CPUs and 1 TB RAM for the final render.

Well, that ought to do it.  :)

> I also plan to have a short movie for my
> PhD defence talk with a camera movement into the scene and maybe pulsating
> emitters.
> Would it be nice in your opinion?

Well, defense committees can be hard to figure out.   If the movie accomplishes
something that you can't do otherwise, or explains something that's exceedingly
hard to do with regular slides, then go for it - but sometimes they get cranky
about gimmicky things.  Only you can judge.


> I was adding a Gaussian blur using Photoshop to the HDRI and the silicon is
> weakly
> reflecting. I off course (from a scientific point of view) do not want to see
> much
> of the Hotel :D That's why.

Sure - I understand the "clean" aspect of it, but on the other hand, you
represent it as "highly artistic" - and I'm not sure how much of the HDRI probe
you'd actually see clearly anyway.
I was just wondering.


> That's crazy :D Did you just guess ZIB or did you find me their? I'm actually at
> Helmholtz-Center Berlin, but have a guest status at ZIB. They are developing the
> FEM code that I use.

I was just trying to get a better idea of what your PbS quantum dot project was
about, so I could better visualize and understand what you were trying to
accomplish in your render.
I had come across Zhang & Polthier et. al.'s paper looking through some image
results and the haxagonalized dragon caught my eye.
http://web.engr.oregonstate.edu/~zhange/images/HexParam.pdf
Then I saw ZIB, and just it was a fun coincidence.

> > I live in New Hampshire, so it's a funny coincidence that you chose the Mount
> > Washington Hotel for your HDRI light probe  :)
>
> Even more crazy. I had that HDRI from the web and did not mind about what it
> shows.

> New Hampshire
> must be a gorgious place! One day my small family and me will visit the US, but
> leave out all the places everyone else goes (we don't like big cities and
> stuff).
> We saw much of New England and Vermont and really like it...

It's certainly not bad - I suppose it's like anywhere else - it has it's good
points and it's bad points, depending on what part you're in.


I'm glad you're getting this to all work out - you put all the pieces together
very _fast_!  I hope the final image is well received, and you do well during
your exit seminar and thesis defense.  The most I accomplished was to make a
useful boroxazolidone - the rest of my PhD was a nightmare, and I just gave up -
terrible "advisor".  Hopefullly you don't have any horror stories, and you have
a great post-defense celebration!  :)

Post a reply to this message

>> Nor me. Very interesting.
>> But maybe that is why I use multiple media.
> 
> See the link in my previous post: it is documented and it does make sense :)
> 
>> Not to my eye. ;)
>> If you look at them using the df3 viewer Ooswa*. They are distinctly
>> different.
> 
> Oh that's really nice of you showing the Ooswa renders (I did not install it
> because of lack of time). These files are actually different because I applied
> a color map (from Python's matplotlib [afmhot]) before I exported them. Of
> course the color map is not uniform in R, G and B (this would only be true
> for a gray scale, right?).
> 
>> Great image BTW
>>
> 
> Thank you very much :) May I post the final render and code somehow in the end?
> (Maybe with reduced resolution due to the 5MB limit? Or do you collect large
> renders somewhere?)
> 
> Another point: the artifacts at the field unit cell borders are a bit
> annoying... The staircasing of the data at the tilted border of the hexagonal
> cell may be unavoidable in the end... See the attached render for a clear
> view of the problem. Is their any trick to "glue" the df3-data at these sides,
> so that no doubled or missing values arise? (What does the `sampling` statement
> in the related media sections do? Could higher values fix this? What about the
> interpolation? It is turned off in the attached image. A value of 1 (linear)
> gives better results than 2 and 3!)
> 

There is a very small horizontal gap. Try reducing the distance in that 
direction by a tiny amount. Another way is just not to place the camera 
directly perpendicularly to the array.

In most cases, interpolate 1 is good enough.
interpolate 2 will give artefacts if the value drop abruptly to zero. 
The interpolation will generate some small negative values that wrap 
around to near maximum : -0.00001 become +0.99999.
The same can appen with interpolate 3.
Interpolate 2 and 3 work best if the values never drop to zero.

sampling_method is used to sellec how the samples are taken.
samples indicate how many samples are taken along a ray from the camera 
as it traverse the media.
If the media is simple with smooth variations in density, some small 
values are usualy good enough.
If your media is complexe, have many interest points and overlaping 
medias, then, you usualy need to use a much larger value.
In your case, the default of 10 is probably to small. Try using some 
progresively larger values untill you don't notable improvement.

As the dots that are visible are rays that slip between different parts, 
more samples can't affect what you get.
Interpolating may cause the media to slightly bleed and may succesfuly 
hide tha tproblem.
Viewing the media at a slight angle, up-down or sideway, can also hide 
those parts.

Post a reply to this message

> Hey Bald Eagle,
> 
> first, it's funny you discovered the time zone thing ... actually there is
> really
> that 1 year + difference between Germany and New Hampshire. But it is a secret,
> so I changed the date to 2017 for now ;)
> 
> The statement of Alain is actually documented here:
>      http://www.povray.org/documentation/view/3.6.1/422/
> (section 2.6.2.3.4 Multiple Density vs. Multiple Media) And he is absolutely
> right,
> the densities multiply while the media add.
> 
> So I did that ... the good thing: it works! ... the bad thing: if I add the
> glowing auras for the number of emitters I planned (50 per unit cell) I am
> getting
> the following error:
> 
>      File 'phc_and_excitation_enhancement.pov' line 372: Parse Error: Expected
>       'numeric expression', undeclared identifier 'Trans_vec' found instead
>      Fatal error in parser: Cannot parse input.
>      Render failed
> 
> I'm kind of shocked :D So there seems now way around this except for compiling
> Pov-ray myself. So I'll let it be :) The workaround: I'll use the multiple media
> technique only for the field render and stick to the individual object approach
> for the emitters. (This may cause some artifacts which I may erase using
> Photoshop).
> 
>> So, it sounds to me like what you need to do is have a media statement for each
>> of your spheres.
>> It looks like your box is 100 x 100, so perhaps you just adjust the drop-off in
>> your exponential decay formula to compensate for that 100x scaling of the media
>> unit cube.
>> The spheres just get placed in that 100 x 100 box as well instead of in a unit
>> cell.
> 
> This turned out to be unnecessary because Pov-ray seems to define the density
> in a unit cube no matter what size the container has (don't ask me why). Somehow
> it worked out with the same transformations as before!

The spherical pattern fits within an unit sphere by definition.
The boxed pattern is indeed defined in an unit cube going from 
<-1,-1,-1> to <1,1,1>.
There is the cylindrical pattern that fill an unit cylinder around the Y 
axis and the planar pattern that extend +- 1 unit fron the X-Z plane.

If you use some other patterns, you'll see that they actually completely 
fill any container used.

Post a reply to this message

Am 28.10.2017 um 22:15 schrieb Stephen:


>>
> 
> :D
> 
> Clipka used to post mails with weird time stamps too. ;)

Did I?
I don't recall anything like that.
I do remember /seeing/ posts with weird time stamps.

Post a reply to this message

On 29/10/2017 01:12, clipka wrote:
> Am 28.10.2017 um 22:15 schrieb Stephen:
> 

>>>
>>
>> :D
>>
>> Clipka used to post mails with weird time stamps too. ;)
> 
> Did I?
> I don't recall anything like that.
> I do remember /seeing/ posts with weird time stamps.
> 

If I remember correctly it was the time stamp. For a while your posts 
seemed to be posted in the wee sma' hours, UK time.

-- 

Regards
     Stephen

Post a reply to this message

Hey Alain,

thank you for the nice input :)

>
> Great improvement.
> With that many lights, you don't need radiosity.
>
> Are your lights fading?
> ...

Thanks :) Right now I am unsure whether to use the light sources at each
emitter position or not. I tried the fading you suggested and it looks much
better! However, the lights cause a tremendous computation time, and radiosity
looks fine, too. I'll see...


>
> Yes, it will take the whole volume, even if most of it will have a
> density of zero. That's why it increase the render time.
>

Have you read the problem with the single media? Oh I am sorry, I posted the
wrong error message!!! The real error is:

  Internal limit exceeded in FixedSimpleVector
  ==== [Rendering...] ========================================================
  Fatal error in renderer: A POV-Ray internal nesting limit was reached.
  Render failed

This happens if two many emitter media are present. Say I use 50 emitters per
unit cell, plus 3 rows and 3 columns: this is 450 media statements in the
mentioned volume. For 10 emitters per unit cell it works (but it's not enough
for visualization purposes, I'd rather use 125 or more :) ). How can I get
around this? For now I'm using the previous method for the emitter auras, but
it causes the overlap problems. Any ideas?


>
> First, you perform any needed scaling. The pattern always start at the
> origin, or <0,0,0>...
>

It turned out the positioning is straight forward...

Thank you moreover for the sampling and scaling/translation related
suggestions. I'll try that soon.

Post a reply to this message

(To Bald Eagle)

>
> When I was in Berlin in 1987, it _seemed_ like it took 7-8 hours, but I fell
> asleep, so maybe I just pulled a Rip Van Winkle.
>

Rip van Winkle!? :D New (especially foreign [for me in this case]) sayings are
always great. How many chances do you have in a lifetime to use this one (my
pleasure to give you one of these possibilities ;) )?

Yet the funny coincidences between you and me do not stop: I was born in 1987
(though 100km away from Berlin)! [And ... the heraldic animal of Germany is a
(rather un-bald) eagle :D ]

>
> > I do not agree (maybe it's my fault, sorry): ...
>
> Nope, I was hasty - I read right through the different filenames.
>

However, when it comes to reading the (comparatively unimportant) header info,
not a single line slips through your eyes :D

>
> Well, defense committees can be hard to figure out.   If the movie accomplishes
> something that you can't do otherwise, or explains something that's exceedingly
> hard to do with regular slides, then go for it - but sometimes they get cranky
> about gimmicky things.  Only you can judge.
>

Seconded (as Stephen used to say). I do think nanophotonics can be hard to
imagine, and, at least from what I experienced "gimmicky" motivation slides
can be advantegous -- as long as the scientific standards are reatined.

>
> I was just trying to get a better idea of what your PbS quantum dot project was
> about, so I could better visualize and understand what you were trying to
> accomplish in your render.
> I had come across Zhang & Polthier et. al.'s paper looking through some image
> results and the haxagonalized dragon caught my eye.
> http://web.engr.oregonstate.edu/~zhange/images/HexParam.pdf
> Then I saw ZIB, and just it was a fun coincidence.
>

Ah, I see: I've put the publication link in the header (which you've read
thoroughly :) ). I had not seen this paper before, thank you for the hint.

>
> I'm glad you're getting this to all work out - you put all the pieces together
> very _fast_!  I hope the final image is well received, and you do well during
> your exit seminar and thesis defense.  The most I accomplished was to make a
> useful boroxazolidone - the rest of my PhD was a nightmare, and I just gave up -
> terrible "advisor".  Hopefullly you don't have any horror stories, and you have
> a great post-defense celebration!  :)

Thanks for the compliment and the good wishes :) I hope that too. I'm sorry
for your story (and I cannot comment _too_ much on it right now). Sometimes
giving up is the right thing to do, especially if the problems you face are
(hu)man-made ... this is at least what I think. BUT, it sounds like the point
when you gave up was at the very end of you PhD phase. For me this means that
all you miss are three letters (of limited meaning), while the _real_ part --
the experience and what you have learned -- cannot be taken away from you :)

Best, Carlo

Post a reply to this message

Addendum: here is a comparison of the two implementations of the emitter
auras.

Left (Alain's version)
----------------------
The spheres that represent the emitters are individual objects, while the auras
are individual media inside a large box that spreads over the entire volume.
This version has much less artifacts, BUT (1) it causes the nesting error
[mentioned above] for the number of emitters I want to use, and (2) it causes
some artifacts at the interface to the photonic crystal.

Right (intial version)
----------------------
Each emitter is a union of two spheres: one for the emitter itself and one for
the aurra (hollow, emitting media with density). It causes massive artifacts.

Alain's version is what I would prefer. So I'd greatly appreciate any hints on
how to solve the nested loop error.

Post a reply to this message

Attachments:
Download 'emitters_multiple_vs_single_media.png' (449 KB)

Preview of image 'emitters_multiple_vs_single_media.png'

Am 29.10.2017 um 11:12 schrieb Stephen:
> On 29/10/2017 01:12, clipka wrote:
>> Am 28.10.2017 um 22:15 schrieb Stephen:
>>

>>>>
>>>
>>> :D
>>>
>>> Clipka used to post mails with weird time stamps too. ;)
>>
>> Did I?
>> I don't recall anything like that.
>> I do remember /seeing/ posts with weird time stamps.
>>
> 
> If I remember correctly it was the time stamp. For a while your posts
> seemed to be posted in the wee sma' hours, UK time.

Ah, now I get you.

Well, yes, that used to happen, for some inexplicable reason... *cough*.

Still happens occasionally on weekends.

Post a reply to this message

Am 28.10.2017 um 23:03 schrieb cbpypov:

> So I did that ... the good thing: it works! ... the bad thing: if I add the
> glowing auras for the number of emitters I planned (50 per unit cell) I am
> getting
> the following error:
> 
>     File 'phc_and_excitation_enhancement.pov' line 372: Parse Error: Expected
>      'numeric expression', undeclared identifier 'Trans_vec' found instead
>     Fatal error in parser: Cannot parse input.
>     Render failed

Smells like malformed scene code to me. Some missing `#end`, misplaced
loop statement, or something along those lines.

Post a reply to this message