"cbpypov" <nomail@nomail> wrote:

Alain wrote:
> > You should use a single container. When you have multiple medias within
> > a single container, they add up.
> > Multiple densities within the same media will multiply instead.

The latter is not what I expected at all!

> THE FINAL PROBLEM:
> How do I specify these media inside the interior with the proper alignment? Say
> I have a singe field and set it as the density (as before). It will then take
> the complete object's vomume, right? How can I get the scaling and the
> positioning of these separate media right?
>
> Any help greatly appreciated and thank you so much for guiding me this far. Im
> sure it will be beautiful in the end :)

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.

I see you are using Stephen's df3 code - but since all of your media statements
and densities are identical except for color, I don't think you need to use 3
statements - just one, with a full rgb value.
Stephen was rendering df3 objects that had uneven color variation - so he needed
to split up the colors so that the R, the G, and the B would be mapped with
different densities, and so add up to a full color range.
That ought to save you some render time.
How long does it take to render this now?
You must be using one of your computers set up for FEM...

A few random comments:
Either you need to seriously adjust your clock for daylight savings time, or the
Time Zone difference between here and Germany is greater than I expected - OR
you started writing this scene a year ago.
It's 2017 over here  ;)

Before you started this thread, I was checking out an interesting paper on
hexagonal mapping of surfaces by Konrad Polthier - I guess he used to be at the
ZIB.  This big world is a small place :D

I live in New Hampshire, so it's a funny coincidence that you chose the Mount
Washington Hotel for your HDRI light probe  :)

Along those lines - I would have expected "more" of the HDRI to be visible on
your surface.  Maybe you want that, maybe you don't.
I also see some yellowish stuff in the holes on the sides near the camera - is
that supposed to be there?  Is it some unintended artifact?

Post a reply to this message

On 28/10/2017 20:25, Bald Eagle wrote:
> "cbpypov" <nomail@nomail> wrote:
> 
> Alain wrote:
>>> You should use a single container. When you have multiple medias within
>>> a single container, they add up.
>>> Multiple densities within the same media will multiply instead.
> 
> The latter is not what I expected at all!
> 

Nor me. Very interesting.
But maybe that is why I use multiple media.

> 
> I see you are using Stephen's df3 code - but since all of your media statements
> and densities are identical except for color, I don't think you need to use 3
> statements - just one, with a full rgb value.

Not to my eye. ;)
If you look at them using the df3 viewer Ooswa*. They are distinctly 
different.






> It's 2017 over here  ;)
> 

:D

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

Great image BTW

* It is a seriously useful tool for working with df3s. And the author 
has fixed the problem with exporting a mesh of a df3. Which might be a 
way of working out how to place the df3s in the common media container

http://qcganime.web.fc2.com/OOSAWA/oosawaE.html


-- 

Regards
     Stephen

Post a reply to this message

Attachments:
Download 'efield_energy_in_superspace_b.png' (114 KB) Download 'efield_energy_in_superspace_g.png' (117 KB) Download 'efield_energy_in_superspace_r.png' (112 KB)

Preview of image 'efield_energy_in_superspace_b.png'

Preview of image 'efield_energy_in_superspace_g.png'

Preview of image 'efield_energy_in_superspace_r.png'

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!

> I see you are using Stephen's df3 code - but since all of your media statements
> and densities are identical except for color, I don't think you need to use 3
> statements - just one, with a full rgb value.
> Stephen was rendering df3 objects that had uneven color variation - so he needed
> to split up the colors so that the R, the G, and the B would be mapped with
> different densities, and so add up to a full color range.
> That ought to save you some render time.

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? Instead I could move the color
mapping to be done in Pov-ray (did not try because it works now). But with this
solution I don't see how to use transmittance...

> How long does it take to render this now?
> You must be using one of your computers set up for FEM...

No it was rendered on a workstation at home :) (we had ours for 10 years and it
was
replaced shortly). Its an AMD Ryzen 7 3.4GHz Eight-Core (plus Hyperthreading).
It
was rendered in 20 Minutes or so :) Actually I have access to, say a server with
64
CPUs and 1 TB RAM for the final render. 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?
(Update, the attached scene took 6 minutes without the emitter light, which
don't
seem to contribute very much)

> Along those lines - I would have expected "more" of the HDRI to be visible on
> your surface.  Maybe you want that, maybe you don't.
> I also see some yellowish stuff in the holes on the sides near the camera - is
> that supposed to be there?  Is it some unintended artifact?

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.

So in the attachment is a small render of the result so far. I like it. There
are
some artifacts in the field which I hope will solve when I plug in a more finely
meshed field data soon. I'm so grateful to all of you for guiding me into the
right direction!

Now the "off topic stuff"...

> Before you started this thread, I was checking out an interesting paper on
> hexagonal mapping of surfaces by Konrad Polthier - I guess he used to be at the
> ZIB.  This big world is a small place :D

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 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.
I just tested many HDRIs and this one gave me results I liked :) 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...

Post a reply to this message

Attachments:
Download '20171028_field_multi_no_qd_lights.png' (1072 KB)

Preview of image '20171028_field_multi_no_qd_lights.png'

> 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!)

Post a reply to this message

Attachments:
Download 'phc_and_excitation_enhancement.png' (282 KB)

Preview of image 'phc_and_excitation_enhancement.png'

> Thank you very much Alain for pointing these things out! I set the radiosity
> option (media on) as you said and it seems to work. I think the route is now
> pretty much clear to me, except for _one_ thing, and I'd be glad to have your
> help one more time...
> 
> What I did so far is the following:
>    - I changed to modeling the photonic crystal as a single membrane with hole,
>      just as Bald Eagle suggested (thanks for this hint and the link to
>      Lohmuellers hole with edge radius :) ).
>    - I randomly generated a list of emitter coordinates with intensities
>      proportional to the field strength at their location.
>    - I changed the light drastically. It now uses 3 spot lights, an area light
>      along x-direction, an HDRI light environment, ... and ... each emitter
>      now features an additional light source proportional to its intensity at
>      its location (so these are many light sources :) ).
>    - I tweaked the material parameters to look more realistic.
> 
> The result is in the attachment, and I am really satisfied with the improvements
> (do you like it?).

Great improvement.
With that many lights, you don't need radiosity.

Are your lights fading?
To get fading lights, you need to add :
fade_distance with a value of about the extent of the visual size of the 
associated object.
fade_power 2
You probably also need to make the lights much brighter, possibly up to 
1000 times, or even more, brighter depending on the fade_distance and 
the the distance between the light and where you want it to have it's 
nominal illumination.

> 
> So the mentioned final step should be:
>    - Model the superspace in which the fields are defined as a single object
>      (I already did, this is just the difference of a large box and the
>       photonic crystal geometry)
>    - Define the (1) emitter's glowing spheres and (2) the field renders as
>      separate media statements inside the interior of this object.
> (Their intensities will add up and the overlapping issues will be gone, am I
> right Alain?)
> 
> THE FINAL PROBLEM:
> How do I specify these media inside the interior with the proper alignment? Say
> I have a singe field and set it as the density (as before). It will then take
> the complete object's vomume, right? How can I get the scaling and the
> positioning of these separate media right?

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.

> 
> Any help greatly appreciated and thank you so much for guiding me this far. Im
> sure it will be beautiful in the end :)
> 

First, you perform any needed scaling. The pattern always start at the 
origin, or <0,0,0>.
Last, you use translate on the individual patterns to place them in the 
desired location.
density spherical scale Your_Scale translate Location

If you translate then scale, the scaling will make the whole thing move.
In fact, scale and rotate sould be placed before any translate.

Post a reply to this message

> "cbpypov" <nomail@nomail> wrote:
> 
> Alain wrote:
>>> You should use a single container. When you have multiple medias within
>>> a single container, they add up.
>>> Multiple densities within the same media will multiply instead.
> 
> The latter is not what I expected at all!

Straight from the documentation.
There is at least one sample scene that demonstrate this.

Post a reply to this message

"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