 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I added one long-requested feature to the codebase, namely support for
area-light diffuse and specular lighting. This means that with a switch
you can make area lights not only affects shadows but also illumination.
The result will be the same as when using an explicit grid of point light
sources, but faster.
At least for now the full illumination will by default be off (so it
will work as currently), but it can be turned on with a new keyword inside
the light_source definition block.
Example:
This is an image rendered with a regular old area_light (rendered with
"-w800 -h600 +a0.1 +am2"):
http://warp.povusers.org/images/arealighttest1.jpg
It took 13 seconds to render in my computer.
This is the same scene, but the area light has been replaced with the
equivalent grid of point lights:
http://warp.povusers.org/images/arealighttest2.jpg
This took 1 min 51 seconds to render.
This is, again, the area_light, but with the new full area lighting
feature turned on:
http://warp.povusers.org/images/arealighttest3.jpg
This took 36 seconds to render.
As always, new features are experimental and thus will require extensive
testing.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This'll be nice - and a lot more intuitive.
Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
That's wonderful news! looks definetely realistic!
all hail Warp! :D
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp nous apporta ses lumieres en ce 2007/11/03 18:57:
> I added one long-requested feature to the codebase, namely support for
> area-light diffuse and specular lighting. This means that with a switch
> you can make area lights not only affects shadows but also illumination.
> The result will be the same as when using an explicit grid of point light
> sources, but faster.
> At least for now the full illumination will by default be off (so it
> will work as currently), but it can be turned on with a new keyword inside
> the light_source definition block.
>
> Example:
>
> This is an image rendered with a regular old area_light (rendered with
> "-w800 -h600 +a0.1 +am2"):
>
> http://warp.povusers.org/images/arealighttest1.jpg
>
> It took 13 seconds to render in my computer.
>
> This is the same scene, but the area light has been replaced with the
> equivalent grid of point lights:
>
> http://warp.povusers.org/images/arealighttest2.jpg
>
> This took 1 min 51 seconds to render.
>
> This is, again, the area_light, but with the new full area lighting
> feature turned on:
>
> http://warp.povusers.org/images/arealighttest3.jpg
>
> This took 36 seconds to render.
>
> As always, new features are experimental and thus will require extensive
> testing.
>
Looks very promising.
Waiting for the chance of testing it.
--
Alain
-------------------------------------------------
Grabel's Law: 2 is not equal to 3 -- not even for large values of 2.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
That looks very good indeed! Thanks Warp!
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wondeful! Thanks Warp!
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oooohh, new toy. Thanks!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I added one long-requested feature to the codebase, namely support for
> area-light diffuse and specular lighting.
Good work.
Especially the "reflection" on the table surface looks dramatically more
realistic with correct lighting. It's all good!
Now if you could also add feature XYZ as well... ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v7 <voi### [at] dev null> wrote:
> Now if you could also add feature XYZ as well... ;-)
If it's not something which will require me to work for a week
10 hours a day, or something which will require a rewrite of the
parser, I'mlistening.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Orchid XP v7 <voi### [at] devnull> wrote:
>> Now if you could also add feature XYZ as well... ;-)
>
> If it's not something which will require me to work for a week
> 10 hours a day, or something which will require a rewrite of the
> parser, I'mlistening.
Well... how hard would it be to make is so that if you use a normal
object with a nonzero "ambient" setting to make a "light source" in
radiosity mode, you get specular hilights?
[Wait, is radiosity working in the beta yet? *checks release notes*]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v7 <voi### [at] devnull> wrote:
> Well... how hard would it be to make is so that if you use a normal
> object with a nonzero "ambient" setting to make a "light source" in
> radiosity mode, you get specular hilights?
Add a reflection and a proper reflection exponent to the object.
To blur the reflection, use the blurred reflection trick.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> a écrit dans le message de news:
472f7e8a@news.povray.org...
> Orchid XP v7 <voi### [at] devnull> wrote:
>> Now if you could also add feature XYZ as well... ;-)
>
> If it's not something which will require me to work for a week
> 10 hours a day, or something which will require a rewrite of the
> parser, I'mlistening.
A very useful feature that goes hand in hand with full area lights is color
mapping aka tone mapping aka exposure control. There's already some code for
it in Megapov. Basically one needs 3 modes : linear, exponential and HSV
(plus gamma correction and some others).
http://www.vray.us/vray_documentation/vray_color_mapping_examples.shtml
This is for Vray but it's standard in other renderers. The examples above
are not very impressive, but HSV color mapping, particularly, is a must have
for interior scenes.
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran <gitran_nospam_@wanadoo.fr> wrote:
> A very useful feature that goes hand in hand with full area lights is color
> mapping aka tone mapping aka exposure control.
I didn't quite get the idea from those images. Some text explaining in
simple terms the idea and the algorithm could be useful.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Orchid XP v7 <voi### [at] devnull> wrote:
> > Now if you could also add feature XYZ as well... ;-)
>
> If it's not something which will require me to work for a week
> 10 hours a day, or something which will require a rewrite of the
> parser, I'mlistening.
>
> --
> - Warp
Oops, followed this up on the wrong thread...
Two things I'd be interested in:
1) System variables to return the resolution of an input image. This appears to
be already available in the source code, just not passed on to the SDL.
2) Separate ior for fresnel reflection (in finish block) to allow for better
texture mapping. I use fresnel quite often, however if I want to map something
like chrome text on a glass block, I would have to model them separately as they
both don't use the same ior.
Just suggestions, however they would be adding to the key word pool. I've been
wanting to write a patch to do this myself regardless, just don't have the time
to look into how to compile it...
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Gilles Tran <gitran_nospam_@wanadoo.fr> wrote:
> > A very useful feature that goes hand in hand with full area lights is color
> > mapping aka tone mapping aka exposure control.
>
> I didn't quite get the idea from those images. Some text explaining in
> simple terms the idea and the algorithm could be useful.
>
> --
> - Warp
It looks like tone-mapping, such as what is used with HDR images quite often.
Taking a high range image and remapping it to low range, preserving contrast
and relative colouration without the clamping of the +1 colour intensities.
Seeing as HDR is implemented, it can currently be done using external programs
if HDR output is used. However, having an internal algorithm would remove the
need for an additional program. However, the advantage of external programs is
that you have much more control on how you want the mapping to be implemented.
I don't know the particular algorithms involved, but I suspect the ones he is
referring to are quite simple, affecting the whole image uniformly (probably
much the same as gamma correction is implemented to the output image), rather
than being locally dependent.
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Trevor G Quayle <Tin### [at] hotmailcom> wrote:
> 1) System variables to return the resolution of an input image. This appears to
> be already available in the source code, just not passed on to the SDL.
This should definitely be doable, but I'll have to ask the team about
their opinion. (Cons: Minor feature, increases reserved keyword clutter...)
> 2) Separate ior for fresnel reflection (in finish block) to allow for better
> texture mapping.
It indeed seems a bit strange that given that reflection is a property of
the texture and not the interior, it would use a value from the interior.
(I don't know the details of the theory behind fresnel reflection, but
I could easily imagine a surface having a different ior on a thin reflecting
layer on its surface than in its main body, thus causing a different type of
reflection than an uniform object would have...)
Someone who knows the theory behind fresnel reclection could express his
opinion on this.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Trevor G Quayle <Tin### [at] hotmailcom> wrote:
> > 1) System variables to return the resolution of an input image. This appears to
> > be already available in the source code, just not passed on to the SDL.
>
> This should definitely be doable, but I'll have to ask the team about
> their opinion. (Cons: Minor feature, increases reserved keyword clutter...)
This I understand, and it is something that maybe a lot of users wouldn't use.
Personally I have had a couple of situations where it could be of use lately.
> > 2) Separate ior for fresnel reflection (in finish block) to allow for better
> > texture mapping.
>
> It indeed seems a bit strange that given that reflection is a property of
> the texture and not the interior, it would use a value from the interior.
> (I don't know the details of the theory behind fresnel reflection, but
> I could easily imagine a surface having a different ior on a thin reflecting
> layer on its surface than in its main body, thus causing a different type of
> reflection than an uniform object would have...)
>
> Someone who knows the theory behind fresnel reclection could express his
> opinion on this.
>
> --
> - Warp
Well there is a relationship between the refraactive ior and fresnel reflection
(it's a bit more complex than presented, literally, as a complex number
component is involved, at least from my limited understanding). It does indeed
seem a propery that is applicable to the interior workings of a material, so I
can see whay it it is outside the texture block, however, the capability for
texture mapping (with reflection being a texture property) would infer that if
ior is related to fresnel, which is related to texture, then ior should be
texture level. So the solution would be either:
1) move ior to texture. This would likely be the simplest to achieve (other
than backward compatibility considerations) And also give the side effect of
being extended to refraction for artistic effect.
2) add an additional ior for fresnel refraction only. This would add a reserved
keyword and require the splitting of the usage of ior for refraction and
reflection.
Alternatively a third option would be:
3) Leave everything as is and make me use a different technique to achieve my
results. (it is only a suggestion, so I don't fully expect it to be added at
this stage in the beta development)
All-in-all, perhaps the fresnel model needs to be examined a little closer for
better implementation in POV4.
Thanks for the consideration regardless.
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Gilles Tran <gitran_nospam_@wanadoo.fr> wrote:
>> A very useful feature that goes hand in hand with full area lights is color
>> mapping aka tone mapping aka exposure control.
>
> I didn't quite get the idea from those images. Some text explaining in
> simple terms the idea and the algorithm could be useful.
Check Graphic Gems IV pp. 391-397 (A contrast-based scale factor for
luminance display).
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> Warp wrote:
>> Gilles Tran <gitran_nospam_@wanadoo.fr> wrote:
>>> A very useful feature that goes hand in hand with full area lights is color
>>> mapping aka tone mapping aka exposure control.
>> I didn't quite get the idea from those images. Some text explaining in
>> simple terms the idea and the algorithm could be useful.
>
> Check Graphic Gems IV pp. 391-397 (A contrast-based scale factor for
> luminance display).
Online try <http://www.cg.tuwien.ac.at/research/theses/matkovic/node34.html>
and also follow the "Up" link for other methods.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
From: Christoph Hormann
Subject: Re: Full area lighting in next beta
Date: 6 Nov 2007 03:55:30
Message: <47302c02@news.povray.org>
|
|
|
| |
| |
|
|
Gilles Tran schrieb:
>
> A very useful feature that goes hand in hand with full area lights is color
> mapping aka tone mapping aka exposure control. There's already some code for
> it in Megapov. Basically one needs 3 modes : linear, exponential and HSV
> (plus gamma correction and some others).
> [...]
Just because a certain renderer offer such three predefined modes does
not make it a particularly good choice i think. MegaPOV gives you the
option of defining any tone mapping function although this currently is
limited to a 1D function identical for all color channels. It might be
interesting to make this a more general feature allowing full control
over the mapping in all three color channels or alternatively integrate
a color management system like LCMS. It is questionable however
considering the design of POV-Ray that having this as part of the
renderer would be particularly useful. Usually you want to be able to
control color mapping after the render. One practical problem about
doing this separately is that a lot of current software designed for
such purposes is developed for digital photo processing and often not
able to load other input images than raw files from digital cameras.
-- Christoph
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christoph Hormann" <chr### [at] gmxde> a écrit dans le message de news:
47302c02@news.povray.org...
> Usually you want to be able to control color mapping after the render.
Theoretically yes, but when color mapping is an integral part of the image's
aesthetics, it's often more practical to have it done at render time, rather
than having to open the image in Photoshop and change it each time with the
same settings. It's not uncommon to create scenes that depend heavily on
color mapping to look right and having to correct them at each iteration of
the creation process would considerably slow down the workflow. I guess
that's the reason why the feature is included in most (if not all) high-end
renderers.
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> a écrit dans le message de news:
472fbce7@news.povray.org...
> Gilles Tran <gitran_nospam_@wanadoo.fr> wrote:
>> A very useful feature that goes hand in hand with full area lights is
>> color
>> mapping aka tone mapping aka exposure control.
>
> I didn't quite get the idea from those images. Some text explaining in
> simple terms the idea and the algorithm could be useful.
In addition to Thorsten's links, here's an explanation about how it's done
in Mental Ray :
http://toi.bk.tudelft.nl/toi-pedia/index.php?title=Rendering_Mental_Ray:_Tone_mapping
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
> MegaPOV gives you the
> option of defining any tone mapping function although this currently is
> limited to a 1D function identical for all color channels. It might be
> interesting to make this a more general feature allowing full control
> over the mapping in all three color channels
Since POV-Ray supports user-defined vector functions, it might be possible
to do it like that.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran <gil### [at] agroparistechfr> wrote:
> In addition to Thorsten's links, here's an explanation about how it's done
> in Mental Ray :
>
http://toi.bk.tudelft.nl/toi-pedia/index.php?title=Rendering_Mental_Ray:_Tone_mapping
Am I understanding correctly that "tone mapping" is nothing else than
a function which takes one parameter, namely a brightness value (eg. of a
color channel), and returns a brigthness value (usually the input value
multiplied by some function)?
Could it also be a function taking three parameters, namely the red,
green and blue components of the color, and returning a vector?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Gilles Tran <gil### [at] agroparistechfr> wrote:
>> In addition to Thorsten's links, here's an explanation about how it's done
>> in Mental Ray :
>>
http://toi.bk.tudelft.nl/toi-pedia/index.php?title=Rendering_Mental_Ray:_Tone_mapping
>
> Am I understanding correctly that "tone mapping" is nothing else than
> a function which takes one parameter, namely a brightness value (eg. of a
> color channel), and returns a brigthness value (usually the input value
> multiplied by some function)?
>
> Could it also be a function taking three parameters, namely the red,
> green and blue components of the color, and returning a vector?
No, it can be much more complex than that. Go "Up" twice on the page whose
link I posted. It is actually from a dissertation discussing various
functions, some of which require more than a handful of parameters.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> No, it can be much more complex than that. Go "Up" twice on the page whose
> link I posted. It is actually from a dissertation discussing various
> functions, some of which require more than a handful of parameters.
Could someone write a short summary?
If it's not just a (user-defined) function which takes certain parameters
and returns a value/color, then what is it?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:47302c02@news.povray.org Christoph Hormann wrote:
> Usually you want to be able to
> control color mapping after the render.
Yes, but often you don't want to do it in a separate step/application. But
if I'm not mistaken, gamma correction is now a kind of "postprocessing
step". Isn't this the same place where tonemapping, colur managent,
colourspace conversions etc. should be done.
Such a setup would mean that tonemapping functions (or gamma-curves) won't
be specified in the scene itself but in a "postprocessing-ini-file".
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Thorsten Froehlich <tho### [at] trfde> wrote:
>> No, it can be much more complex than that. Go "Up" twice on the page whose
>> link I posted. It is actually from a dissertation discussing various
>> functions, some of which require more than a handful of parameters.
>
> Could someone write a short summary?
>
> If it's not just a (user-defined) function which takes certain parameters
> and returns a value/color, then what is it?
A algorithm with up to n**2 complexity per pixel afaict (wthout checking in
detail) from some of the existing algorithms.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp nous apporta ses lumieres en ce 2007/11/05 22:19:
> Trevor G Quayle <Tin### [at] hotmailcom> wrote:
>> 1) System variables to return the resolution of an input image. This appears to
>> be already available in the source code, just not passed on to the SDL.
>
> This should definitely be doable, but I'll have to ask the team about
> their opinion. (Cons: Minor feature, increases reserved keyword clutter...)
>
We already have image_width and image_height, why not reuse it with this
variation: when included with an image that is loaded, it returns the dimentions
of that image instead of that of the rendered image.
It could look somewhat like:
image_map{jpg "MyImage.jpg" Width = image_width, Height = image_hight, [your
other parameters]}
--
Alain
-------------------------------------------------
You know you've been raytracing too long when you can no longer tell the
difference between the top raytracing book and the "Raytracing for Dummies"
book. To you, they're both hopelessly uninformed.
-- Taps a.k.a. Tapio Vocadlo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <ele### [at] netscapenet> wrote:
> Warp nous apporta ses lumieres en ce 2007/11/05 22:19:
> > Trevor G Quayle <Tin### [at] hotmailcom> wrote:
> >> 1) System variables to return the resolution of an input image. This appears to
> >> be already available in the source code, just not passed on to the SDL.
> >
> > This should definitely be doable, but I'll have to ask the team about
> > their opinion. (Cons: Minor feature, increases reserved keyword clutter...)
> >
>
> We already have image_width and image_height, why not reuse it with this
> variation: when included with an image that is loaded, it returns the dimentions
> of that image instead of that of the rendered image.
> It could look somewhat like:
>
> image_map{jpg "MyImage.jpg" Width = image_width, Height = image_hight, [your
> other parameters]}
>
>
Unfortuneately image_map can't be declared explicitly like:
#declare A=image_map{jpg "MyImage.jpg"} so using it this way would require it to
be applied to something (mind you it could be just a dummy pigment, but this
seems un-neat to me).
I would see it working more similar to min_extent/max_extent maybe:
#declare A=resolution{jpg "MyImage.jpg"};
or perhaps min_extent/max_extent could be reused to avoid adding a new
keyword(in this case min_extent would always be <0,0> or it could be just left
out)
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> A algorithm with up to n**2 complexity per pixel afaict (wthout checking in
> detail) from some of the existing algorithms.
With n being what?
Well, anyways, this sounds all too complicated. I'm doing this just as
a hobby, not as my payjob. I'm not finding too much motivation to study
dozens of pages of complicated math for this. Unless someone can give me
a simple algorithm I can implement, I'm really sorry.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Trevor G Quayle <Tin### [at] hotmailcom> wrote:
> Unfortuneately image_map can't be declared explicitly like:
> #declare A=image_map{jpg "MyImage.jpg"} so using it this way would require it to
> be applied to something (mind you it could be just a dummy pigment, but this
> seems un-neat to me).
It's perfectly possible and in fact quite easy to do something like this:
#declare Im = pigment { image_map { jpg "MyImage" } };
#declare R = max_extent(Im);
and then R.x would be the width of the image and R.y the height.
(I actually went ahead and implemented this just to see if it would work,
and it worked like a charm.)
The only question is whether max_extent() is the suitable function for
this.
It has been suggested that image_width, when used as a function (and given
the image map pigment identifier as parameter) would return the width of the
image, and likewise image_height the height, but I'm not completely sure how
trivial this is to implement in the parser because these keywords are already
used as float identifiers. It would mean that when parsing these keywords the
parser would have to look for an optional opening parenthesis after it, and
if it appears, behave differently. I haven't yet looked, but my past
experience in trying this "check for an optional syntax element" with the
current parser has been daunting. (More precisely, I tried to implement
concatenation of strings using the + operator. I hit a wall.)
(max_extent() doesn't have this problem because it's already a vector
function, and thus it's simply a question of checking the type of the
parameter. This is very trivial to implement in the parser.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Trevor G Quayle <Tin### [at] hotmailcom> wrote:
> > Unfortuneately image_map can't be declared explicitly like:
> > #declare A=image_map{jpg "MyImage.jpg"} so using it this way would require it to
> > be applied to something (mind you it could be just a dummy pigment, but this
> > seems un-neat to me).
>
> It's perfectly possible and in fact quite easy to do something like this:
>
> #declare Im = pigment { image_map { jpg "MyImage" } };
> #declare R = max_extent(Im);
>
> and then R.x would be the width of the image and R.y the height.
>
> (I actually went ahead and implemented this just to see if it would work,
> and it worked like a charm.)
>
> The only question is whether max_extent() is the suitable function for
> this.
>
> It has been suggested that image_width, when used as a function (and given
> the image map pigment identifier as parameter) would return the width of the
> image, and likewise image_height the height, but I'm not completely sure how
> trivial this is to implement in the parser because these keywords are already
> used a float identifiers. It would mean that when parsing these keywords the
> parser would have to look for an optional opening parenthesis after it, and
> if it appears, behave differently. I haven't yet looked, but my past
> experience in trying this "check for an optional syntax element" with the
> current parser has been daunting. (More precisely, I tried to implement
> concatenation of strings using the + operator. I hit a wall.)
>
> (max_extent() doesn't have this problem because it's already a float
> function, and thus it's simply a question of checking the type of the
> parameter. This is very trivial to implement in the parser.)
>
> --
> - Warp
I like the way you've shown it. Would it not be cleaner to do it direectly with
out the dummy pigment?
#declare R = max_extent(jpg "MyImage");
I think this would be more inuitive. Or is this more difficult to implement?
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Trevor G Quayle <Tin### [at] hotmailcom> wrote:
> I like the way you've shown it. Would it not be cleaner to do it direectly with
> out the dummy pigment?
> #declare R = max_extent(jpg "MyImage");
> I think this would be more inuitive. Or is this more difficult to implement?
I would have to implement a "read only the header of a given image file,
but not the image itself", which would be rather laborious. Reading the
entire image file (and then just dropping it) would be a waste. Could as
well just do that into a pigment identifier.
Besides, I don't think your suggestion is more intuitive. In fact, quite
counter-intuitive because it makes a function act nothing like other similar
functions.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Thorsten Froehlich <tho### [at] trfde> wrote:
>> A algorithm with up to n**2 complexity per pixel afaict (wthout checking in
>> detail) from some of the existing algorithms.
>
> With n being what?
>
> Well, anyways, this sounds all too complicated. I'm doing this just as
> a hobby, not as my payjob. I'm not finding too much motivation to study
> dozens of pages of complicated math for this. Unless someone can give me
> a simple algorithm I can implement, I'm really sorry.
FYI, when I was looking into this years ago, I pushed it back as too much
work for too little gain ;-)
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> a écrit dans le message de news:
4730da10@news.povray.org...
> Well, anyways, this sounds all too complicated. I'm doing this just as
> a hobby, not as my payjob. I'm not finding too much motivation to study
> dozens of pages of complicated math for this. Unless someone can give me
> a simple algorithm I can implement, I'm really sorry.
Perhaps I'm wrong, but the typical color mapping that is found in most
renderers seems to be a much more simple thing and to belong to the "global
operators" class described in the Wikipedia article. It's even implemented
in free renderers like Indigo and Kerkythea, so I tend to assume that the
basics are well known to CG programmers. In any case, the exposure control
from Megapov would be a good start already.
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran <gitran_nospam_@wanadoo.fr> wrote:
> Perhaps I'm wrong, but the typical color mapping that is found in most
> renderers seems to be a much more simple thing and to belong to the "global
> operators" class described in the Wikipedia article. It's even implemented
> in free renderers like Indigo and Kerkythea, so I tend to assume that the
> basics are well known to CG programmers. In any case, the exposure control
> from Megapov would be a good start already.
I'm wondering that you mentioned tone mapping in relation to area lights,
yet from what I see it's not related to area lights at all, but it's simply
a post-processing step, in practice a function from unclamped pixel values
(of the final rendered image) to clamped ones.
Post-processing in POV-Ray is such a beast that I really don't want to
get my hands dirty on it. It's something for pov4.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran schrieb:
>
>>Usually you want to be able to control color mapping after the render.
>
>
> Theoretically yes, but when color mapping is an integral part of the image's
> aesthetics, it's often more practical to have it done at render time, rather
> than having to open the image in Photoshop and change it each time with the
> same settings. [...]
I am not sure if photoshop offers the features necessary for that but my
point is you will want to be able to *change* the tone mapping after the
render even if you already set some mapping function before the render.
Having a tone mapping feature in the render display would certainly be
nice, especially with a separate post processing program being able to
apply the same adjustments to the render output (this could be a simple
filter like the netpbm tools). But being only able to do the tone
mapping during the render or not at all would be the wrong way i think.
-- Christoph
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp nous apporta ses lumieres en ce 2007/11/06 16:32:
> Trevor G Quayle <Tin### [at] hotmailcom> wrote:
>> Unfortuneately image_map can't be declared explicitly like:
>> #declare A=image_map{jpg "MyImage.jpg"} so using it this way would require it to
>> be applied to something (mind you it could be just a dummy pigment, but this
>> seems un-neat to me).
>
> It's perfectly possible and in fact quite easy to do something like this:
>
> #declare Im = pigment { image_map { jpg "MyImage" } };
> #declare R = max_extent(Im);
>
> and then R.x would be the width of the image and R.y the height.
>
> (I actually went ahead and implemented this just to see if it would work,
> and it worked like a charm.)
>
> The only question is whether max_extent() is the suitable function for
> this.
>
> It has been suggested that image_width, when used as a function (and given
> the image map pigment identifier as parameter) would return the width of the
> image, and likewise image_height the height, but I'm not completely sure how
> trivial this is to implement in the parser because these keywords are already
> used as float identifiers. It would mean that when parsing these keywords the
> parser would have to look for an optional opening parenthesis after it, and
> if it appears, behave differently. I haven't yet looked, but my past
> experience in trying this "check for an optional syntax element" with the
> current parser has been daunting. (More precisely, I tried to implement
> concatenation of strings using the + operator. I hit a wall.)
>
> (max_extent() doesn't have this problem because it's already a vector
> function, and thus it's simply a question of checking the type of the
> parameter. This is very trivial to implement in the parser.)
>
It looks like using max_extent() would be a beter option than the one I
proposed. Easier to implement and use, at least, it look like it's so.
--
Alain
-------------------------------------------------
Did you know that SATAN is an anagram for SANTA?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> At least for now the full illumination will by default be off (so it
> will work as currently), but it can be turned on with a new keyword inside
> the light_source definition block.
Warp,
Coming in late to this thread I'm afraid, but I thought I'd add my thanks for
implementing this feature. Should add a lot to realism.
Is this option available in beta 23, or will we need to wait for beta 24 to test
this? I've lost track of when b23 came out.
On a related area light point, do you know if the area light axes transform bug
(as noted in
http://news.povray.org/web.4694c449b02d2b905e1e98150%40news.povray.org ) will
be fixed in b24? It's still there in b23.
Mike.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Andrews <nomail@nomail> wrote:
> Is this option available in beta 23, or will we need to wait for beta 24 to test
> this? I've lost track of when b23 came out.
It should be in the next beta that comes out.
> On a related area light point, do you know if the area light axes transform bug
> (as noted in
> http://news.povray.org/web.4694c449b02d2b905e1e98150%40news.povray.org ) will
> be fixed in b24? It's still there in b23.
Probably not. I might look into this.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Mike Andrews <nomail@nomail> wrote:
> > Is this option available in beta 23, or will we need to wait for beta 24 to test
> > this? I've lost track of when b23 came out.
>
> It should be in the next beta that comes out.
Thanks, I look forward to testing this.
>
> > On a related area light point, do you know if the area light axes transform bug
> > (as noted in
> > http://news.povray.org/web.4694c449b02d2b905e1e98150%40news.povray.org ) will
> > be fixed in b24? It's still there in b23.
>
> Probably not. I might look into this.
It's not a big problem - it has been present since at least 3.6, probably
earlier, without anyone else commenting on it that I could see - but it appears
to have a very simple fix.
>
> --
> - Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
