Am 18.01.2013 03:33, schrieb Kenneth:

> I've been reading up on OpenEXR today--fascinating stuff (including the
> odd/different gamma computations that it uses internally, to ultimately display
> the image on typical 8-bit monitors. At least as a Photoshop plug-in. The
> *display* of HDRI images is one of the things that I've never clearly
> understood.)

Display of HDRI images is quite simple, too: Essentially you /can't/ 
display them. There aren't any displays out there that would provide the 
necessary dynamic range.

So what you do is simulate the effects it would have on photographic 
film or to the naked eye (they, too, don't have HDRI capability): You 
make the >100% portions of the image "bleed" into their neighborhood, by 
mixing in a low-brightness highly blurred copy of the HDR image. If 
you're going for fancy, you can also add lens flares based on the HDR image.

> For my animation here, I initially came up with a scheme to render the various
> elements separately--meteors, moon and background--using POV-Ray's
> Image_Alpha=on for the meteors and moon. Basically to see if I could save time
> in the rendering process, as well as adding AA solely to the moon (6000 frames
> for the meteors, but only 600 for the moon and background elements, as they
> didn't need blurring, IMO.) I ran into some trouble though (in 3.62) when
> averaging-together just the meteor elements as a pre-step (again using
> Image_Alpha): The resulting meteor blur, when finally overlaid onto the other
> elements, showed dark fringes. I now realize that alpha-multiplication (or non-)
> is one of the culprits (as well as 3.7 having corrected some errors in how alpha
> image_maps are applied.)

Isn't 3.7 great? :-)

The problem you ran into with 3.6 was probably that it expected a 
different alpha for input files than what it generated itself in output 
files. Apparently the authors of the old code didn't really know the 
difference.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> A 1280X720 animation, 600 frames, of the camera flying through some space
> debris.

....and...

> ...Basically to see if I could save time
> in the rendering process, as well as adding AA solely to the moon (6000 frames
> for the meteors, but only 600 for the moon and background elements...

Oops, I meant to say 300 in both cases, not 600.  Amazingly, that because
6000/20 is 300, not 600! :-[  I shall now re-read my 1st-grade arithmetic
book...

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

>
> Display of HDRI images is quite simple, too: Essentially you /can't/
> display them. There aren't any displays out there that would provide the
> necessary dynamic range.

I thought I read somewhere (or maybe not!) that a very specialized display was
available to do that. Maybe in scientific circles; can't remember where I saw
it. Perhaps just wishful thinking!

I've been wondering about the latest whiz-bang flat panel monitors, with their
supposed 10-gazillion-to-1 contrast ratios: whether or not that would suffice to
show HDR images raw. But I suppose the internal circuitry still works in the
standard 8-bit-per-channel way. Not to mention the extreme brightness levels
that would be required of the pixels as well.

>
> So what you do is simulate the effects it would have on photographic
> film or to the naked eye (they, too, don't have HDRI capability): You
> make the >100% portions of the image "bleed" into their neighborhood, by
> mixing in a low-brightness highly blurred copy of the HDR image.

Fascinating! I've never seen it explained that way. More research to do!

Post a reply to this message

Am 18.01.2013 06:10, schrieb Kenneth:

>> Display of HDRI images is quite simple, too: Essentially you /can't/
>> display them. There aren't any displays out there that would provide the
>> necessary dynamic range.
>
> I thought I read somewhere (or maybe not!) that a very specialized display was
> available to do that. Maybe in scientific circles; can't remember where I saw
> it. Perhaps just wishful thinking!

Might be. Not for mortals though.

> I've been wondering about the latest whiz-bang flat panel monitors, with their
> supposed 10-gazillion-to-1 contrast ratios: whether or not that would suffice to
> show HDR images raw. But I suppose the internal circuitry still works in the
> standard 8-bit-per-channel way. Not to mention the extreme brightness levels
> that would be required of the pixels as well.

I guess the best they do is 12 pits per channel. And that high contrast 
is usually not within a single frame, but between successive frames. 
Essentially it just tells you how much they automatically dim the 
backlight in dark scenes.

There are displays that can dim the backlight locally, giving them a 
comparatively high contrast between parts of a single scene - but even 
there it is used solely to get the "black" level down in dark parts of 
the scene.

Post a reply to this message

> A 1280X720 animation, 600 frames, of the camera flying through some space
> debris. It has motion-blur but no antialiasing. (I thought I could get away
> without AA due to the erratic and blurred camera motions, which will usually
> hide the lack of AA--but the moon still shows some jaggies every now and then.)

Very nice!

Some minor issues

- the lighting is very soft / ambient for a space scene
- there seem to be some "collisions" (rocks passing through each other)
- this better be debris from a recently destroyed moon, otherwise
   so-called astroid belts / fields usually have millions of km
   between individual asteroids ;)

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:

>
> Very nice!

Thanks!
>
> Some minor issues
>
> - the lighting is very soft / ambient for a space scene

Yes indeed. By design, actually. I wanted an 'old' 1960's era
science-fiction-film look for the scene. Like it was photographed in a studio
setting. But the one thing I adamantly refused to do was to show the strings
holding up the meteors ;-)

> - there seem to be some "collisions" (rocks passing through each other)

I was wondering if anyone would notice that. So far, I count only one, but there
are probably others. I toyed with the idea of writing some kind of code for
collision detection or whatever, but got bogged down in the details; so I opted
for an easier scheme of random meteor placement, but one that's not *quite* so
simple as <rand(...),rand(...),rand(...)>. The final construction is actually a
cylindrical 'tube' full of objects (with a central tube carved out for the
camera to move through.) There are multiple seed() values for this, to give me
at least *some* control over the situation. If I had taken enough time, I could
probably have found a set of values to *totally* eliminate the few collisions.
But real collision detection is obviously needed.

> - this better be debris from a recently destroyed moon, otherwise
>    so-called astroid belts / fields usually have millions of km
>    between individual asteroids ;)

It's just a completely fanciful scene. That's why I wasn't even sure what to
call those rocks. Not asteroids, not really meteors--more a collection of simple
space junk. But why would they all be *rotating* and at different rates? Hmm,
something strange here!  :-P

Post a reply to this message

Kenneth wrote:

> But the one thing I adamantly refused to do was to show the strings
> holding up the meteors ;-)

such a scene would likely be shot with the camera pointing vertically up
through a glass plate and then dropping a bucket of cardboard rocks ;)

> It's just a completely fanciful scene. That's why I wasn't even sure what to
> call those rocks. Not asteroids, not really meteors

certainly not meteors, but you probably meant meteroids :-P

http://www.freemars.org/jeff/meteor/

> But why would they all be *rotating* and at different rates?

That I find believable, space stuff rotates. In case of a break-up
the angular momentum of the parent body has to be preserved, but the
rotation of each individual piece is very much a result of its mass,
shape, original position, and random collision history.

Post a reply to this message

Christian Froeschlin wrote:

> certainly not meteors, but you probably meant meteroids :-P

and even more likely you meant meteOroids ;)

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:
>
> such a scene would likely be shot with the camera pointing vertically up
> through a glass plate and then dropping a bucket of cardboard rocks ;)

Hey, good idea! I need to remember that... :-P
>
> > It's just a completely fanciful scene. That's why I wasn't even sure what to
> > call those rocks. Not asteroids, not really meteors
>
> certainly not meteors, but you probably meant meteroids :-P
>

Oh. You're right.

>
> > But why would they all be *rotating* and at different rates?
>
> That I find believable, space stuff rotates. In case of a break-up
> the angular momentum of the parent body has to be preserved, but the
> rotation of each individual piece is very much a result of its mass,
> shape, original position, and random collision history.

My scene does looks like an explosion of something. But there's no 'central
explosion point'; the meteors--oops, meteoroids--are just hanging there in
space, doing their thing. Hey, I just thought of a plausible(??) reason for the
random rotations: a mutual gravitational tug-of-war! On second thought, though,
that's not likely; they would eventually join together into a lumpy asteroid.

Oh well. This scene takes place in "a galaxy far far away"-- different physics
there ;-)

Post a reply to this message

Kenneth wrote:

> Christian Froeschlin <chr### [at] chrfrde> wrote:

>> such a scene would likely be shot with the camera pointing vertically up
>> through a glass plate and then dropping a bucket of cardboard rocks ;)
> 
> Hey, good idea! I need to remember that... :-P

I recall reading that's how they did space explosions in Star Trek ;)

Post a reply to this message