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

On 30/10/2017 09:51, clipka wrote:
> 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.
> 

Good, I'm not going mad(der).

-- 

Regards
     Stephen

Post a reply to this message

I'm with clipka - I think your code must be missing a ) or a } or an #end or
something.  It's always useful to stick a few #debug statements in to see what's
going on.

(I've thought a lot about tracking the "depth" of parts of scene code, and if a
global variable were defined, then every time one opens up a deeper level (#if,
#while, #for, #macro, etc) one increments that variable, then decrements it when
exiting, perhaps that would help narrow down WHERE a particular error was
occurring, and give a clue as to HOW it was being triggered.)


"cbpypov" <nomail@nomail> wrote:
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 ;) )?

Well I was trying to remember the guy's name, and the first thing that popped
into my mind was Rumpelstiltskin - but that wasn't right.

It gets interesting when you check out Wikipedia:
"Rumpelstiltskin is a fairytale popularly associated with Germany (where he is
known as Rumpelstilzchen). The tale was one collected by the Brothers Grimm in
the 1812 edition of Children's and Household Tales. According to researchers at
Durham University and the Universidade Nova de Lisboa, the story originated
around 4,000 years ago.[1][2]"


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

Well, as Doctor Who fan, I'm especialy sensitive to these temporal anomalies. ;)



> 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.

Well, for a further coincidence, the LED light in my bedroom must be a photonic
crystal, because when I went to turn it on this morning, the globe was filled
with water (we're having a storm) - it looks like it's operating in "leaky mode"

:D


> Best, Carlo

Thanks  :)

Post a reply to this message

To all of you:

THIS IS THE WRONG ERROR CODE, PLEASE IGNORE:
> >
> >     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.

THE CORRECT ERROR CODE:

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

It occurs only if the number of emitters is too large and when their auras
are rendered as a media statements in a large contain (called Alain's version by
me, above).

Still any hints on this appreciated :)

Post a reply to this message

Am 30.10.2017 um 13:31 schrieb cbpypov:

> THE CORRECT ERROR CODE:
> 
>   Internal limit exceeded in FixedSimpleVector
>   ==== [Rendering...] ========================================================
>   Fatal error in renderer: A POV-Ray internal nesting limit was reached.
>   Render failed
> 
> It occurs only if the number of emitters is too large and when their auras
> are rendered as a media statements in a large contain (called Alain's version by
> me, above).
> 
> Still any hints on this appreciated :)

Ah, yes, that makes a lot more sense (to the trained eye, at any rate).

While nowadays (v3.7 and later) most of POV-Ray uses dynamically-sized
data structures for lists and stuff, there is a handful of data
structures that are still fixed in size, as we haven't managed yet to
get rid of them without degrading performance.

The size of those data structures was chosen quite arbitrarily, with the
corresponding constants being defined in `source/core/configcore.h`.
Search for `FixedSimpleVector Sizes`.

No way around this except re-compiling POV-Ray with tweaked constant sizes.

Post a reply to this message